web-dev-qa-db-ja.com

ゾーンの頂点にあるNSレコードはどのような状況で照会されますか？

ゾーンの頂点で定義されたNSレコードは、通常の操作中にどの時点で照会されますか？

私が調査したものから、これらのレコードは以下によって使用されます：

  • DNS NOTIFY。マスターがスレーブサーバーにSOAをプルし、マスターが変更されたときにゾーンファイルを更新するように通知する。

  • DNSゾーン定義の正確さを検証するためのいくつかのツール

  • 反復DNSリゾルバー。ゾーンの信頼できるNSレコードをキャッシュしている場合、ルート/ TLD /親サーバーに移動する代わりに、それらを使用してそのゾーンのクエリに応答します。

  • サーバー自体、そのゾーンに対して権威があると宣言します（これが事実であるとは確信していませんが、各DNS実装と親DNSサーバーの紹介NSレコードによって外部で設定されていると思いますゾーンファイルにない、またはSOAレコードを介して）

私が理解していないのは、反復DNSリゾルバーがゾーンのNSレコードをキャッシュする状況で、彼がNSそのゾーンのレコード

詳しく説明しましょう。空のキャッシュを持つ反復リゾルバにリソースのクエリ（たとえば、IN A www.example.com.）が与えられたときの理解から、次のようになります。

  1. ルートDNSサーバーにIN A www.example.com.を照会します

    1.1。空の回答セクションを受け取ります

    1.2。 .com.ゾーンのNSレコードを持つ権限セクション（これらは権限がありません）。

    1.3。権限のないこれらのNSレコードをキャッシュします（子中心の非スティッキまたは親中心の場合）。 RFC 2181はこれを行うべきではないと述べていますが。

  2. TDL .com. DNSサーバーにIN A www.example.com.を照会します

    2.1。上記と同じ取引ですが、権限のないNSレコードはexample.com.用です

  3. example.com.のIN A www.example.com.のNSサーバーにクエリを実行します

    3.1 www.example.com.の信頼できる回答を受け取る

    3.2受信したAレコードをキャッシュします。

    3.3クライアントに回答を返します

上記の交換中に、反復リゾルバーはクエリIN NS example.com.またはIN NS .com.またはauthoritativeに対する他のクエリを発行しませんでした。 NSすべてのゾーンのレコード。したがって、私が収集したものから、反復DNSリゾルバーのクライアント/ユーザーが正確なクエリIN NS example.com.を誤って発行しない限り、反復リゾルバーはnever信頼できるNSをキャッシュします_ IN NS example.com.のレコード

上記はそうですか？または、反復DNSリゾルバー実装は、信頼できるNSレコードをキャッシュし、同じドメインに対する将来のクエリを高速化する目的で、ゾーンに対してNSクエリを起動しますか？または、クライアントがゾーンのNSレコードをランダムにクエリした場合にのみ、信頼できるNSレコードをキャッシュしますか？ DNSリゾルバー実装全体に共通または最も人気のあるパターンさえありますか？

参照：

domain-name-systemdns-zone
1
German

私は、あなたが述べた期待から逸脱する1つの主なケースとあまり一般的ではない追加のケースがあり、どちらも実装固有のものだと思います。

  • example.comの権限のあるサーバーは、NSレコードをwww.example.com. IN Aの応答に追加します。必須ではありませんが、可能です。従来、これは非常に一般的な動作でした。

    • 例：minimal-responsesオプションが有効になっていない限り、BINDはこれを行います。

  • リゾルバーサーバーは、参照の追跡の一部としてexample.com. IN NSを検索します。従来は一般的な動作ではありませんでした。

    • 例：harden-referral-pathオプションが有効になっている場合、Unboundはこれを実行します。
1
Håkan Lindqvist

https://tools.ietf.org/html/rfc7816#appendix-A で、NSレコードとその使用方法。

ゾーンカットについて見つけるには、NSレコードのクエリが必要です。これは、適切なDNSSEC検証とQNAMEの最小化に必要です。

QNAME最小化に関するRFC 7816は、セクション2でこれを述べています。

完全なQNAMEと元のQTYPEアップストリームを送信する代わりに、QNAME最小化を実装し、キャッシュにまだ回答がないリゾルバーは、元のQNAMEの最も近い既知の祖先に対して権限のあるネームサーバーにリクエストを送信します。
リクエストは次のように行われます：

o QTYPE NS

o元のQNAMEであるQNAME。サーバーが権限を持つゾーンよりも1つだけ多くラベルが削除されます。

NSレコードをこのように使用すると、クライアント（再帰的なネームサーバー）は、照会している信頼できるネームサーバーへの現在の飛行要求に関するデータを共有しなくなります。

セクション3で、壊れたネームサーバーを回避するために、あなた（再帰的クライアント）がAレコードではなくNSレコードを試してみたいと説明していることは事実です。ただし、それでも他の壊れたDNSサーバーに対する回避策です。

また、一般的に共有されるビューでは、DNSは「子中心」であり、NS関連するセットは、親ではなく子からのセットです。 DNSSECで署名されている（紹介がANSWERセクションにない）。ただし、リゾルバーがそれだけを実行し、子でのみ再チェックする場合、ドメインが消えたり、ネームサーバーを変更したりすることはありません。 NS用。

現在作業中のこのドラフトを参照してください： https://datatracker.ietf.org/doc/draft-huque-dnsop-ns-revalidation/?include_text=1

次の関連段落があります。

正式には、子ゾーンの頂点NS RRsetは信頼できるため、親の委任よりもキャッシュの信頼性が高くなりますNS RRset、つまり権限のない接着剤（[ RFC2181]、セクション5.4.1。ランキングデータ）したがって、NS RRset "below the zone cut"は、親の委任をすぐに置き換える必要がありますNS RRset in cache反復キャッシングDNSリゾルバーがゾーンの境界を超えた場合。ただし、これは、（1）リゾルバーが子ゾーンからの応答のAuthorityセクションで権限のあるNS RRsetを受信した場合にのみ発生します。は必須ではありません、または（2）リゾルバが反復解決アルゴリズムの一部として子ゾーンにNS RRsetクエリを明示的に発行する場合。これがない場合、反復リゾルバーのダウンストリームクライアントが明示的にそのようなNSクエリを発行しない限り、ゾーンの信頼できるNS RRsetを学習しないようにリゾルバーをキャッシュする通常のエンドユーザーaアプリケーションはそうするので、規則的に発生することを信頼することはできません。

次に、セクション3で、再帰的なネームサーバーがデータを適切に再検証するためにNSレコードタイプリクエストを発行するタイミングと理由について、以下のすべての詳細に注意してください。

このドキュメントは現在、DNSに関するIETFワーキンググループによる採択を求められていることに注意してください。そうなると、後で完全な標準（RFC）になる可能性があります。

1
Patrick Mevzek