たとえば、google.com の DNS ルックアップをトレースすると、dig はルート サーバーへの要求のみを表示し、トップ レベル ドメインをスキップして、第 2 レベル ドメイン サーバーに直接進みます。つまり、a.root-servers.net から ns1.google.com に進みます。 この写真からもわかるように 中間にあるはずの [ah].gtld-servers.net TLD サーバーはどうでしょうか? 結果に表示されないのはなぜでしょうか? 他のホスト名でも同じことが起こります。たとえば、gaia.cs.umass.edu などです。 写真 ルート サーバーから ns[1-3].umass.edu までです。a.edu-servers.net のような .edu TLD サーバーはどこにあるのでしょうか?
答え1
これらの結果から、何か奇妙なことが起こっているのではないかと疑うよりも、ネットワーク内で何か奇妙なことが起こっているのではないかと疑うようになりましたdig。
何らかの形の透過的な「プロキシ」が行われていますか? つまり、(例の 1 つに示されているように、ルート サーバーの 1 つへの) クエリは199.7.91.13実際にそのアドレスに送信されていますか、それともどこか別の場所 (おそらくローカル リカーサ) にリダイレクトされていますか?
1 つの仮説は、すべての DNS トラフィックがリカーサーに送信され、それが完全な出力に表示されるというものです (信頼できる応答は得られません...つまり、aaフラグはありません)。
トレースのアイデアを続行するには、例えば次のように実行します。
dig +trace +all example.com
これには、各ステップの完全な出力が含まれます。応答の詳細を確認し、ルート サーバーからの応答 (SERVER: ...各応答の下部にある) が実際に信頼できる応答であるかどうかを確認します。
次のようなクエリは、何か異常なことが起きているかどうかを明らかにするのにも役立ちます。正常なインターネット接続から観測された実際の `199.7.91.13` の応答と比較してみましょう (単一のサーバーではないため、応答は必ずしも一貫しているわけではありませんが、何を期待するかは大体わかります)。
dig @199.7.91.13 version.bind CH TXT +norec
(ソフトウェア + バージョン文字列で応答する場合があります)
dig @199.7.91.13 hostname.bind CH TXT +norec
(ホスト名で応答する場合があります)
dig @199.7.91.13 id.server CH TXT +norec
(サーバー識別子で応答する場合があります)