私は今Linuxシステム管理者のオンラインコースを受講していますが、誰かが私が通常理解していない質問をしました。私はネームサーバーを検索する方法を知っています。私が正しい場合は、少なくともdigコマンドを使用して追加の部分コマンドでアドレスを見つけます。しかし、次の質問を受けると少しパニックになります。
設定したネームサーバーに使用されるキャッシュされた結果がないと仮定すると、あなたのネームサーバーはmap.google.comを確認するためにいくつかのネームサーバーを照会する必要がありますか？これらのネームサーバーをすべて検索するには、どのコマンドを使用しますか？各レベルのいずれかをリストし、そのレベルが必要な理由を説明します。
私は答えが欲しくないので、私が何をするように求められているのかを知りたいだけです。
答え1
設定したネームサーバーに使用されるキャッシュされた結果がないと仮定すると、あなたのネームサーバーはmap.google.comを確認するためにいくつかのネームサーバーを照会する必要がありますか？これらのネームサーバーをすべて検索するには、どのコマンドを使用しますか？各レベルのいずれかをリストし、そのレベルが必要な理由を説明します。
さて、これを分析してみましょう。
「設定したネームサーバーにキャッシュされた結果がないとします。」- まず、あればいいえデータがまったくキャッシュされない場合、問題は解決されません。リゾルバーのキャッシュを入力するには、.（AKAルート）ゾーンのNSおよびアドレス（A、AAAA）レコードが必要です。これはゾーン内のルートネームサーバーですroot-servers.net.。このゾーンやDNSサーバーには魔法のようなものはありません。ただし、このデータは通常DNSリゾルバに「帯域外」として提供され、リゾルバのキャッシュを正確に入力します。このデータは特権ネームサーバーには必要ありませんが、ネームサーバーを解決するためには必要です。
そして「決断」とは何ですか？この名前のRRtypeはありますか？ RR A？それとも別のものですか？どのクラス( CH/Chaosnet, IN/Internet,...)?正確なプロセスはさまざまですが、一般的なアイデアは同じです。
私たちがルートネームサーバーを見つける方法を知っていますが、それ以上ではないと仮定することができ、「解決」とは、その名前に関連するすべてのRRの内容を取得することを意味すると仮定することができればIN Aより実用的です。
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つに要求して、名前と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応答データの記録がない）ことを示します。同様の応答を探してくださいSERVFAIL。応答を受け取ったら、一歩下げて別のサーバーを試してください。すべてのネームサーバーがを返すと、SERVFAIL名前解決プロセスは失敗し、SERVFAILクライアントにそれ自体が返されます。
各サーバーから完全なRRnameを要求する代わりに（悪い習慣と見なされる可能性がある）、以前に識別されたラベルを使用してリストを分割し、サーバーによって提供されたネームサーバーとそのラベルのIN NS/ IN ARRのルートを使用して追加クエリすることです。IN AAAA、それを使用して名前解決プロセスに進みます。これは実際にはわずかに異なるだけで、同じプロセスがまだ適用されます。
+tracedigBINDの一部またはset debugで利用可能なユーティリティオプションを使用して、プロセス全体をシミュレートできますnslookup。
また、いくつかのタイプのRR（特に他のいくつかのタイプ、しばらくは合理的にうまく機能しましたが廃止されました）が他のRRを参照して参照できることを覚えておくNS価値があります。この場合、生成する必要があります。MXA6終わったらもっとあります。お客様に完全かつ有用な回答を提供するための名前解決プロセスです。
答え2
dnstracer名前解決を追跡するコマンド（少なくともDebianにインストールする必要があり、パッケージ名でもあります）があります。 （コベラスがコメントで指摘したように）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はすべてのパスを追跡するため、出力は続行されます（一部のネームサーバーに古いゾーンがあることを確認できます）。
したがって、ルートネームサーバーへのクエリ、gtld-servers（.comゾーンのサーバー）へのクエリ、最後にGoogleネームサーバーへのクエリが必要であることがわかります。
を使用すると、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もちろん、たとえば、オンラインで実際のクエリを表示することもできます。