DNSで信頼できるネームサーバーを送信する理由

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

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

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

ホストとしてNS情報が必要なのはなぜですか？

伝統的に、サーバがクエリに短い応答が、RFC送信しない名前1034 - 1035リソースレコードが含まれている権限部を備え準拠した完全な応答をその権威ネームサーバ（群）に向けてのポイント。

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

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

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

私が考えるその伝統の起源はで権威セクションの両方を含むだけでなく、実際のクエリ応答は廃止から（擬似）コードでそのルートを見つけ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.

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

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