構成済みのネームサーバーにキャッシュされた結果がない場合は、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アドレスは有効で到達可能です。解決が始まると、ルートゾーンの完全なデータセットが含まれます。
maps.google.com. IN A198.41.0.4へのDNSクエリをオフにします。それは「いや、やるつもりはないが、ここに誰かが知っているかもしれない」と返答する。それは紹介です。これにはNS、問題のサーバーが認識している最も近いゾーンのレコードと、サーバーがたまたま使用できるグルーレコードがあります。接着剤データが利用できない場合は、最初に、選択したNSレコードで指定されたホストを解決する必要があるため、IPアドレスを取得するために別の名前解決を生成します。接着剤データが利用可能な場合は、回答に少なくとも「近い」ネームサーバーのIPアドレスがわかります。この場合、それがcom.ゾーンのサーバーのセットとなり、接着剤データも提供されます。
com.ネームサーバーの1つに同じ質問をして、プロセスを繰り返します。彼らはどちらも知りませんが、Googleの信頼できるネームサーバーを紹介します。この時点で、一般的なケースでは、接着剤データが提供されているかどうかにかかわらず、ヒットまたはミスされます。たとえば、comドメインのみがネームサーバーを持つことを妨げるものは何もありません。nlその場合、gTLDサーバーからグルーデータを利用することはできません。提供された接着剤データも不完全な場合があります。または、本当に運が悪い場合は、正しくない場合もあります。上で述べた別の名前解決を生成する準備を常に整えておく必要があります。
基本的には、aa（信頼できる回答）フラグが設定された回答が得られるまで続けます。その答えは、あなたが何を求めているのか、またはあなたが要求したRRが存在しない（NXDOMAINまたはNOERROR、応答データレコードが0である）ことを教えてくれます。次のような応答を探し続けますSERVFAIL（そして、1つのステップから戻って、もし取得したら別のサーバーを試してください。すべての名前付きサーバーがに戻ったらSERVFAIL、名前解決プロセスに失敗SERVFAILし、クライアントに戻ります）。
各サーバーから完全なRRnameを要求する代わりに（これは悪い習慣と考えられるかもしれません）、以前に決定したラベルの分割リストを使用して、ルートIN NSおよびIN A/ IN AAAARRに向かってサーバーから与えられたネームサーバーに尋ねますそのラベルに使用し、それらを使用して名前解決プロセスを進めます。これは実際にはわずかに異なるだけであり、同じプロセスが引き続き適用されます。
ユーティリティの+traceオプションを使用して、このプロセス全体をシミュレートできdigます。これは、BINDの一部として、またはset debugに付属していnslookupます。
（特にこれは、いくつかのRRtypesことも覚えておく価値だNS、MX;また、およびいくつかの他の人がA6合理的にしばらくの間、よく使用されたが、廃止された）ことができ、参照他のRRを行います。その場合、クライアントに完全で有用な応答を返すために、さらに別の名前解決プロセスを生成する必要がある場合があります。
dig +traceていましたが、レベルの意味がわかりません。これは、サーバー障害の問題である可能性があります。