☰

BIND-DNSフォワーダーを構成できる場所

tag-icon • tag-icon dns bind forwarding
BIND-DNSフォワーダーを構成できる場所

BINDの構成を調査していますが、特権サーバーではなく一部のドメインを要求するために、次のネームサーバーをどのように知っているかわかりません。

たとえば、既定のドメインは「workgroup.lan」ルックアップ
です。dig www.google.com

回答

;;質問セクション：
;www.google.com。中

;;答え部分:

[...]

;;信頼できる部分:
google.com。 NS ns1.google.comの87465。

[...]

;;クエリ時間：4ミリ秒
;;サーバー：127.0.0.1＃53（127.0.0.1）
;;時間：2012年8月28日火曜日15:56:08
;;MSGサイズrcvd：220

しかし、誰が/何が彼に別のネームサーバーに尋ねるように言いましたか？それともこれがデフォルトの動作ですか？

ルートネームサーバーIPを含む「.」（root）ゾーンを担当する「root.hint」ファイルに関連している可能性がありますか？

ベストアンサー1

DNS サーバーの構成を調べる必要がありますが、フォワーダーの設定や同様のものがないと仮定すると、実際には正確です。ルートヒントファイルです。

DNSはツリーで構成されています（冗長性のためにノードが複製されます。たとえば、複数のルートノードがあります）。ルートヒントファイルは、ルートネームサーバーの1つを見つけることができる場所をサーバーに知らせます（見つかったら、実際に見つかったルートネームサーバーからルートネームサーバーの現在のリストを取得します）。

次に、ルートネームサーバーの1つで、comゾーンに特権を持つネームサーバーのリストを検索します。そのうちの1つで、google.comゾーンの特権ネームサーバーのリストを見つけます。最後に、そのいずれかからwww.google.comの住所（A）レコードを取得します。 [実際には www.google.com は CNAME ですが、同じ地域にあり、Google ネーム サーバーは間違いなく両方のレコードを返します。]

このプロセスは明らかに時間がかかるため、多くのキャッシュを使用します。おそらくwww.google.comのアドレスを既に知っていて、キャッシュからそのアドレスを返す可能性があります。そうでない場合は、おそらくns1.google.comに連絡する方法が既にわかっているか、失敗した場合はcomのサブドメインに連絡する場所をほとんど知っています。

このdnstracerプログラムを使用して、次のことを見ることができます。

anthony@Zia:~$ dnstracer -4 -o -s . www.google.com
Tracing to www.google.com[a] via A.ROOT-SERVERS.NET, maximum of 3 retries
A.ROOT-SERVERS.NET [.] (198.41.0.4) 
 |\___ e.gtld-servers.net [com] (192.12.94.30) 
 |     |\___ ns4.google.com [google.com] (216.239.38.10) Got authoritative answer [received type is cname] 
 |     |\___ ns3.google.com [google.com] (216.239.36.10) Got authoritative answer [received type is cname] 
 |     |\___ ns1.google.com [google.com] (216.239.32.10) Got authoritative answer [received type is cname] 
 |      \___ ns2.google.com [google.com] (216.239.34.10) Got authoritative answer [received type is cname] 
⋮

DNSについて、特にBINDの使い方をもっと知りたい場合は、DNSとバインディング、現在5版が出てきたこの本は良い本です。 O'Reillyから直接電子書籍を入手することもできます。

おすすめ記事