web-dev-qa-db-ja.com

権威ネームサーバーをDNSで送信する理由

好奇心から、Wireshark DNSパケットをチェックしています。ホストからのDNSクエリがあり、DNSサーバーからのDNS応答があることがわかります。すべてが期待どおりです。

ただし、クエリをさらにチェックインすると、サーバーがNS（権威ネームサーバー）も送信していることがわかります。私の質問は、なぜですか？

ホストとして、私はIPのみを気にします。これがDNSの主なポイントから名前をIPアドレスに解決するです。

ホストとして、NS info？が必要な理由

domain-name-systemdns-zonewiresharkdns-hostingdns-server
11
AhmedWas

従来、ネームサーバーはクエリに対して短い応答を送信しませんが、RFC 1034 - 1035 に準拠した完全な応答です。これには、信頼できるものを指すリソースレコードを含む機関セクションが含まれますネームサーバー。

その理由はおそらく、DNSの分散型および委任型の性質により、「真実のソース」を応答に含めることは、当時は良い考えのように思われたためです。

編集：ちなみに、権限セクションの送信はRFCに準拠していますが、すべてのクエリ応答に必須ではありません。

BINDでは、この動作は minimal-responses yes | no; ディレクティブ。デフォルトはnoであり、クエリ応答のAuthorityセクションとAdditionalセクションは常に完全に入力されます。
他のネームサーバーCloudFlare、AWS Route 53、Infoblocksおよびおそらく他のネームサーバーは、デフォルトで常にそのような最小限の応答を常に送信します。 Googleのパブリックリゾルバーは、利用可能な場合、Authorityセクションを返します、Cloudflare。

Ithink伝統の起源である機関セクションと実際のクエリ応答の両方を含めると、現在は廃止された RFC882 15-16ページ

If the name server is not authoritative, the code copies 
the RRs for a closer name server into the response.  

The last section of the code copies all relevant RRs into the response.
15
HBruijn

サーバーは、リクエストがエンドクライアントからのものか、別のネームサーバーからの再帰的なリクエストかを認識していません。それが別のネームサーバーである場合は、権限セクションをキャッシュし、将来これらのネームサーバーに直接クエリを送信できます。

これがプロトコルの本来の正当化であると私は思いますが、それはセキュリティに影響を与えます。応答には、偽のネームサーバーをリストする権限セクションを含めることができ、これはキャッシュポイズニング攻撃で使用されています。したがって、ネームサーバーは通常、クエリを実行しているドメインのサブドメインの委任レコードでない限り、NSレコードをキャッシュしません。

5
Barmar