【入門編】 digコマンドにおける再帰的問い合わせと非再帰的問い合わせの制御 – トラブルシューティング&ネットワーク運用監視実践ガイド

「名前を知りたいだけなのに、なぜ遠回りするの?」DNSの裏側を覗く究極のトラブルシューティング術

ネットワークエンジニアの皆さん、こんにちは。現場で叩き上げられてきたNOCのシニアエンジニアとして、今日は「DNSの解像トラブル」という、ネットワーク運用の現場で最も胃が痛くなるテーマについてお話しします。

皆さんがブラウザでWebサイトにアクセスするとき、裏側では「名前解決」というリレーが行われています。でも、たまに「Webサイトが表示されない」「設定を変えたはずなのに古い情報が返ってくる」という怪奇現象に遭遇しませんか?

そんな時、教科書通りの nslookup や dig だけを使っていると、「キャッシュサーバー(ISPや社内のDNS)が余計なお世話をしてくれている」という事実に気づけません。今日は、現場のエンジニアが隠し持っている「権威サーバーに直談判する」ためのテクニックを伝授します。

—

郵便配達で例える「DNSの再帰と非再帰」

まずは、小難しいDNSの仕組みを「郵便配達」に例えてみましょう。

1. 通常の問い合わせ(再帰的問い合わせ:Recursion)

あなたが手紙を出すとき、郵便局の窓口(キャッシュサーバー)に「この住所に送って!」と頼みますよね。すると郵便局員が他の郵便局を駆け回り、最終的に宛先に届けてくれます。これが一般的なDNSの動きです。楽ですが、途中で「別の郵便局が古い住所を教えてくれた」場合、真実がどこにあるのか分かりません。

2. 直談判の問い合わせ(非再帰的問い合わせ:Non-Recursive)

トラブルの時、私たちは「余計な仲介はいらないから、この住所の持ち主である本人(権威DNSサーバー)に直接聞きたい!」と思うはずです。これが今回紹介する「非再帰的問い合わせ」です。郵便局を通さず、直接相手の家のドアを叩きに行くイメージですね。

—

digコマンドで「直談判」を実現する

普段皆さんが使う dig example.com は、暗黙のうちに「再帰的問い合わせ(RDフラグ:Recursion Desired)」を有効にしています。これをあえてオフにすることで、DNSの世界の「真実」を見ることができます。

実践:+norecurse オプションを使う

実際にコマンドを打ってみましょう。特定のドメインの権威サーバーに対して、余計なキャッシュを介さずに直接聞くコマンドです。

# @で権威DNSサーバーを指定し、+norecurseで「再帰不要」を伝える
dig @ns1.example.com example.com +norecurse

このコマンドを打ったとき、結果に flags: qr aa; という表示があれば成功です!

  • aa (Authoritative Answer) : 「私はこのドメインの正当な権威サーバーですよ」という証明。
  • もしここで aa が出てこない場合、そのサーバーは正しい権威を持っていないか、何か設定が間違っていることが一発で分かります。

—

なぜこのテクニックが必要なのか?

現場でこの技を使うのは、主に「DNSの伝播遅延」や「キャッシュ汚染」を疑うときです。

  • 「設定を変えたのに反映されない!」という叫び

社内サーバーが古い情報をキャッシュしているのか、それとも権威サーバー側の設定がそもそも間違っているのか。この切り分けは、再帰問い合わせをオフにして権威サーバーに直接聞けば、0.1秒で答えが出ます。

  • 「特定の場所からだけアクセスできない」という謎

中間にあるDNSサーバーが異常な応答を返している場合、権威サーバーには正常なレコードが載っていることを証明することで、問題の切り分けを一気に進められます。

—

現場のシニアからのアドバイス

初学者の皆さんは、「なぜそんな面倒なことを?」と思うかもしれません。しかし、大規模な障害対応の現場では、「途中の機器を信じない」ことが生存率を高める最大のスキルです。

キャッシュサーバー(郵便局)は親切心から「前にも聞いたことあるから、これ使えばいいよ」と古い情報を渡してくることがあります。しかし、インフラエンジニアである私たちは、常に「今、この瞬間の真実」を知る必要があります。

まとめ:ステップアップのために

1. まずは dig コマンドの +norecurse オプションを試してみてください。
2. +trace オプションも併用して、ルートサーバーから順に誰が回答しているのかを追いかける癖をつけましょう。
3. DNSの仕組みを「郵便配達」や「伝言ゲーム」のメタファーで捉え直すと、パケットの動きが立体的に見えてくるはずです。

ネットワークのトラブルシューティングは、パケットという「見えないもの」との対話です。最初は難しく感じるかもしれませんが、CLIから直接サーバーに語りかけるこの感覚を掴めば、皆さんもきっと現場で頼られるエンジニアになれるはずです。

さて、次はどのパケットを追いかけましょうか?また現場でお会いしましょう。

コメント

タイトルとURLをコピーしました