現在、Linux システム管理者向けのオンライン コースを受講しているのですが、まったく理解できない質問を受けました。ネーム サーバーの検索方法は知っています。少なくとも、dig コマンドを使用して、追加のセクション コマンドで指定されたアドレスを検索する方法は正しいのですが、次の質問を受けたときに少し困惑してしまいました。
設定されたネームサーバーにキャッシュされた結果がない場合、maps.google.com を解決するためにネームサーバーはいくつのネームサーバーを照会する必要がありますか? これらすべてのネームサーバーを検索するには、どのようなコマンドを使用しますか? 各レベルから 1 つずつリストし、そのレベルが必要な理由を説明してください。
答えは知りたくありません。ただ、具体的に何をするように求められているのかを知りたいだけです。
答え1
設定されたネームサーバーにキャッシュされた結果がない場合、maps.google.com を解決するためにネームサーバーはいくつのネームサーバーを照会する必要がありますか? これらすべてのネームサーバーを検索するには、どのようなコマンドを使用しますか? 各レベルから 1 つずつリストし、そのレベルが必要な理由を説明してください。
さて、これを分解してみましょう。
「設定されたネームサーバーにキャッシュされた結果がないと仮定します」まず、もしいいえキャッシュされたデータがまったくない場合は、何も解決できません。リゾルバのキャッシュを準備するには、.(別名ルート) ゾーンの NS レコードとアドレス (A、AAAA) レコードが必要です。これは、ゾーン内にあるルート ネーム サーバーですroot-servers.net.。そのゾーンや DNS サーバーに魔法のようなものはありません。ただし、このデータは、リゾルバのキャッシュを準備するために、DNS リゾルバに「帯域外」で提供されることがよくあります。権限のみのネーム サーバーにはこのデータは必要ありませんが、解決ネーム サーバーには必要です。
また、何に「解決」するのでしょうか? その名前の RRtype ですか? ARR ですか? それとも何か他のものですか? どのクラス ( CH/Chaosnet、IN/Internet、...) ですか? 正確なプロセスは異なりますが、基本的な考え方は同じです。
ルート ネーム サーバーの検索方法以外については何も知らないと仮定し、「解決」とはIN A名前に関連付けられた RR の内容を取得することを意味すると仮定すると、はるかに実用的になります。
DNS 名を解決するには、基本的に名前をラベルに分割し、右から左に向かって作業を進めます。.最後に を忘れないでください。実際にはmaps.google.com.ではなくを解決することになりますmaps.google.com。つまり、 を解決する必要があります (これはわかっていますが、DNS リゾルバの実装ではおそらくわかりません)。
.com.google.com.maps.google.com.
まず、 のコンテンツをどこで問い合わせるかを考えます.。これは簡単です。その情報はすでにあります。ルートネームサーバーです。名前とIPアドレスルート ネーム サーバーができました。a.root-servers.net名前解決を続行するために 198.41.0.4 ( 、2001:503:ba3e::2:30 とも呼ばれる) を使用することに決めたとします。実際には、リゾルバーが最初に行うことの 1 つは、提供されたルート サーバー データを使用して、ルート ゾーン サーバーの 1 つにルート ゾーンのネーム サーバーの正確なリストを要求することです。これにより、名前と IP アドレスのいずれかが有効で到達可能であれば、解決の開始時にルート ゾーンの完全なデータ セットが確保されます。
198.41.0.4に DNS クエリを送信しますmaps.google.com. IN A。応答として「いいえ、実行しませんが、知っている人がいます」と表示されます。これが参照です。参照には、NS問題のサーバーが知っている最も近いゾーンのレコードと、サーバーが使用できるグルー レコードが含まれます。グルー データが使用できない場合は、最初に選択した NS レコードで指定されたホストを解決する必要があります。そのため、IP アドレスを取得するために別の名前解決を生成します。グルー データが使用できる場合は、少なくとも回答に「近い」ネーム サーバーの IP アドレスが得られます。この場合、それはゾーンのサーバーのセットになりcom.、グルー データも提供されます。
このプロセスを繰り返し、com.ネームサーバーの 1 つに同じ質問をします。彼らも知りませんが、Google の権威あるネームサーバーにあなたを誘導します。この時点では、一般的にはグルーデータが提供されるかどうかは運次第です。たとえば、comドメインが にのみネームサーバーを持つことを妨げるものは何もnlありません。その場合、グルーデータは gTLD サーバーから入手できない可能性があります。提供されるグルーデータは不完全である可能性があり、運が悪ければ間違っている可能性もあります。いつも上で述べた別の名前解決を実行する準備をしてください。
基本的に、(権威ある回答) フラグが設定された回答が得られるまで続けますaa。その回答は、要求内容、または要求した RR が存在しない ( NXDOMAIN、またはNOERROR応答データ レコードが 0 のいずれか) ことを伝えます。 のような応答を探し続けますSERVFAIL(そして、1 つステップを戻して、1 つのサーバーを取得した場合は別のサーバーを試します。すべての名前付きサーバーが を返す場合はSERVFAIL、名前解決プロセスが失敗し、SERVFAILクライアントに戻ります)。
各サーバーに完全な RRname を要求する方法 (これは悪い方法と見なされる場合があります) の代わりの方法は、前に決定したラベルの分割リストを使用し、サーバーによってルートに向かってさらに指定されたネーム サーバーにそのラベルの RRIN NSとIN A/ IN AAAARR を要求し、それらを使用して名前解決プロセスを進めることです。これは実際にはわずかに異なるだけで、同じプロセスが適用されます。
このプロセス全体は、BIND の一部として、またはで提供されるユーティリティ+traceのオプションを使用してシミュレートできます。digset debugnslookup
また、いくつかのRRtype（特にNS、MXおよび他のいくつかのRR、また、A6しばらくの間かなりよく使われていましたが、廃止されました）は他のRRを参照できることを覚えておく価値があります。その場合、さらにもう一つ名前解決プロセスにより、クライアントに完全かつ有用な応答が提供されます。
答え2
名前解決をトレースするコマンドがありますdnstracer(少なくとも Debian では、パッケージ名でもあるので、インストールする必要があるかもしれません)。また、(Koveras がコメントで指摘しているように) を使用することもできますdig。
ここでは dnstracer を使用しています。-s .はルートから開始することを意味します。-4IPv4 を使用することを意味します (v6 はここでは機能しません...)。-o解決された IP アドレスを最後に実際に表示することを意味します (出力のその部分は省略しました。多数あります)。
anthony@Zia:~$ dnstracer -s . -4 -o maps.google.com
Tracing to maps.google.com[a] via A.ROOT-SERVERS.NET, maximum of 3 retries
A.ROOT-SERVERS.NET [.] (198.41.0.4)
|\___ m.gtld-servers.net [com] (192.55.83.30)
| |\___ ns4.google.com [google.com] (216.239.38.10) Got authoritative answer
| |\___ ns3.google.com [google.com] (216.239.36.10) Got authoritative answer
| |\___ ns1.google.com [google.com] (216.239.32.10) Got authoritative answer
| \___ ns2.google.com [google.com] (216.239.34.10) Got authoritative answer
⋮
dnstracer がすべてのパスをトレースするため、その出力は継続されます (そのため、たとえば、一部のネームサーバーに古いゾーンがあるかどうかを確認できます)。
したがって、ルート ネーム サーバーに 1 つのクエリが実行され、次に gtld サーバー (.com ゾーンのサーバー) に 1 つのクエリが実行され、最後に Google ネーム サーバーに 1 つのクエリが実行されることがわかります。
を使用するとdig、出力ははるかに冗長になります (そのため、多くの部分を削除する必要があります)。
dig -4 maps.google.com. +norecurse +trace
; <<>> DiG 9.8.4-rpz2+rl005.12-P1 <<>> maps.google.com. +norecurse +trace
;; global options: +cmd
. 425379 IN NS b.root-servers.net.
⋮
com. 172800 IN NS f.gtld-servers.net.
⋮
google.com. 172800 IN NS ns2.google.com.
⋮
maps.google.com. 300 IN A 74.125.228.70
⋮
digさらに、現在のルート ネーム サーバーのリストを取得するためにクエリを実行したことも示しています。これは、DNS サーバーが通常、非常にまれにしか実行しないことです。そのため、これをコールド キャッシュのケースに含めるかどうかはわかりません。
もちろん、たとえば を使用して、ネットワーク上の実際のクエリを監視することもできますwireshark。