web-dev-qa-db-ja.com

DNSドメインの頂点にあるNSレコードの役割は何ですか？

$Origin example.com. ; not necessary, using this to self-document

$TTL 3600
@        IN     SOA   ns1.example.com. admin.example.com. (
                      1970010100 7200 1800 1209600 300)

@        IN     NS   ns1.example.com.
@        IN     NS   ns2.example.com.

@        IN     A    198.51.100.1
ns1      IN     A    198.51.100.2
ns2      IN     A    198.51.100.3

sub1     IN     NS   ns1.example.edu.

sub2     IN     NS   ns1.sub2
ns1.sub2 IN     A    203.0.113.1 ; inline glue record

NSレコードbeneathの役割はよく理解されており、権限を委任するために存在します上記の例には、NS sub1およびsub2。これらにより、ネームサーバーは、それ自体が権限を持っているとは見なさないドメインの部分の紹介を渡すことができます。

NSレコードの目的は、ドメインの頂点、ns1およびns2この場合、インターネット全体ではあまり理解されていないようです。私の理解（全体的ではないかもしれません）は次のとおりです。

  1. これらは、ドメインの権限のあるサーバーを特定するためにDNSサーバーをキャッシュする際には使用されません。これは、レジストラレベルで定義されている nameserver glue によって処理されます。レジストラneverはこの情報を使用してグルーレコードを生成します。
  2. それら は、ドメイン全体の権限を他のネームサーバーに委任するために使用されません 。 ISC BINDなどのソフトウェアを使用してそうしようとしても、ネームサーバーはゾーンに対して信頼できると見なし続けるため、「期待される」紹介動作はまったく発生しません。
  3. ネームサーバーは、信頼できる応答（AAフラグセット）を返すかどうかを決定するためにこれらを使用しません。この動作は、ソフトウェアがゾーンのマスターまたはスレーブになるように指示されているかどうかによって定義されます。ほとんどのネームサーバーソフトウェアは、apex NSレコードを提供し、上流のグルーレコードに含まれる情報と一致しないため、有名なDNS検証Webサイトがドメインに対して警告を生成します。

この場合、何が残っているのでしょうか。インターネット上のDNSサーバー全体をキャッシュすることによってこの情報が消費されないように見えるのに、なぜこの情報を定義するのですか？

domain-name-systemns-recordglue-record
21
Andrew B

下位の識別

ApexレベルNSレコードは、マスターサーバーがその下位を識別するために使用されます。権威あるネームサーバーのデータが変更されると、DNS NOTIFYメッセージ（ RFC 1996 ）をリストのすべてのピアに送信します。これらのサーバーはSOAレコード（シリアル番号を含む）のリクエストを使用してコールバックし、プルダウンするかどうかを決定しますそのゾーンの最新のコピー。

  • これらのメッセージをNSセクションにリストされていないサーバーに送信することは可能ですが、これにはサーバー固有の構成ディレクティブ（ISC BINDのalso-notifyディレクティブなど）が必要です。頂点NSレコードは、デフォルトの構成で通知するサーバーの基本リストを構成します。
  • セカンダリサーバーもこれらのNSレコードに基づいて相互にNOTIFYメッセージを送信し、通常は拒否されたログに記録されることに注意する価値があります。これを無効にするには、サーバーがマスターであるゾーンの通知のみを送信するように指示するか（BIND：notify master;）、または構成で明示的に定義された通知を優先してNSベースの通知を完全にスキップします。 （バインド：notify explicit;）

権威ある定義

上記の質問には誤りが含まれていました：

これらは、ドメインの権限のあるサーバーを特定するためにDNSサーバーをキャッシュする際には使用されません。これは、レジストラレベルで定義されているネームサーバーグルーによって処理されます。レジストラは、この情報を使用してグルーレコードを生成することはありません。

これは簡単に結論付けられますが、正確ではありません。 NSレコードおよびグルーレコードデータ（レジストラーアカウント内で定義されたデータなど）は信頼できません。権限が委任されているサーバー上にあるデータよりも「信頼できる」と見なすことができないのは当然のことです。これは、紹介にaa（権威ある回答）フラグが設定されていないという事実によって強調されます。

説明する：

$ Dig @a.gtld-servers.net +norecurse +nocmd example.com. NS
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 14021
;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 5

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;example.com.                   IN      NS

;; AUTHORITY SECTION:
example.com.            172800  IN      NS      a.iana-servers.net.
example.com.            172800  IN      NS      b.iana-servers.net.

;; ADDITIONAL SECTION:
a.iana-servers.net.     172800  IN      A       199.43.135.53
a.iana-servers.net.     172800  IN      AAAA    2001:500:8f::53
b.iana-servers.net.     172800  IN      A       199.43.133.53
b.iana-servers.net.     172800  IN      AAAA    2001:500:8d::53

上記の返信のフラグにaaがないことに注意してください。紹介自体に権限はありません。一方、参照されているサーバー上のデータは信頼できるものです。

$ Dig @a.iana-servers.net +norecurse +nocmd example.com. NS
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 2349
;; flags: qr aa; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;example.com.                   IN      NS

;; ANSWER SECTION:
example.com.            86400   IN      NS      a.iana-servers.net.
example.com.            86400   IN      NS      b.iana-servers.net.

つまり、紹介の親側で権限のないNSレコードが定義されていないと、これらのNSレコードの権限のあるバージョンについて知ることができないため、この関係は非常に混乱する可能性があります。彼らが同意しない場合はどうなりますか？

  • 短い答えは「一貫性のない行動」です。
  • 長い答えは、ネームサーバーは最初にすべての紹介（および接着剤）を空のキャッシュにスタブ化しますが、それらのNS、A、およびAAAAレコードは最終的に更新されたときに置き換えられます。これらの一時レコードのTTLが期限切れになるか、誰かがそれらのレコードの回答を明示的に要求すると、更新が発生します。
    • ゾーン外データのAおよびAAAAレコード（つまり、comゾーン外のデータのグルーを定義するcomネームサーバー、example.netなど）ネームサーバーはそのような情報の信頼できる情報源と見なされるべきではないことはよく理解されている概念であるため、間違いなく更新されることになります。 （RFC 2181）
    • NSレコードの値が参照の親側と子側で異なる場合（レジストラーコントロールパネルに入力されたネームサーバーが、同じサーバー上に存在するNSレコードとは異なるなど）、発生する動作には一貫性がなく、子NSレコードまで完全に無視されます。これは、動作が標準によって明確に定義されておらず、実装が再帰的なサーバーの実装によって異なるためです。つまり、インターネット全体で一貫した動作は、ドメインのネームサーバー定義が参照の親側と子側で一貫している場合にのみ期待できます。

長いことと短いことは、紹介の親側で定義されたレコードがそれらのレコードの信頼できるバージョンと一致しない場合、インターネット全体の再帰DNSサーバーが宛先間で跳ね返ることです。最初は、紹介に存在するデータが優先され、信頼できる定義によってのみ置き換えられます。キャッシュは常にインターネット全体でゼロから再構築されているため、この構成では、インターネットが単一バージョンの現実に落ち着くことは不可能です。 NSによって定義されたエイリアスでCNAMEレコードをポイントするなど、信頼できるレコードが標準に従って違法な行動をしている場合、トラブルシューティングはさらに困難になります。ドメインは、違反を拒否するソフトウェアの動作と切断を交互に行います。 （つまり、ISC BIND /名前付き）

RFC 2181§5.4.1 は、このデータの信頼性に関するランキングテーブルを提供し、参照とグルーに関連付けられたキャッシュデータを、それらのレコードに対する明示的な要求に対する回答として返せないことを明示的にします参照する。

5.4.1. Ranking data

   When considering whether to accept an RRSet in a reply, or retain an
   RRSet already in its cache instead, a server should consider the
   relative likely trustworthiness of the various data.  An
   authoritative answer from a reply should replace cached data that had
   been obtained from additional information in an earlier reply.
   However additional information from a reply will be ignored if the
   cache contains data from an authoritative answer or a zone file.

   The accuracy of data available is assumed from its source.
   Trustworthiness shall be, in order from most to least:

     + Data from a primary zone file, other than glue data,
     + Data from a zone transfer, other than glue,
     + The authoritative data included in the answer section of an
       authoritative reply.
     + Data from the authority section of an authoritative answer,
     + Glue from a primary zone, or glue from a zone transfer,
     + Data from the answer section of a non-authoritative answer, and
       non-authoritative data from the answer section of authoritative
       answers,
     + Additional information from an authoritative answer,
       Data from the authority section of a non-authoritative answer,
       Additional information from non-authoritative answers.

   <snip>

   Unauthenticated RRs received and cached from the least trustworthy of
   those groupings, that is data from the additional data section, and
   data from the authority section of a non-authoritative answer, should
   not be cached in such a way that they would ever be returned as
   answers to a received query.  They may be returned as additional
   information where appropriate.  Ignoring this would allow the
   trustworthiness of relatively untrustworthy data to be increased
   without cause or excuse.
21
Andrew B

NSは委任されたゾーンを記録し、ドメイン定義の完全性を提供します。NSサーバー自体はゾーンファイルに依存します。ルートサーバーから再帰クエリを実行することで、ゾーンファイル内のNSレコードは、他の多くの機能を提供します。

キャッシュサーバーは、キャッシュからネームサーバーにクエリを実行することにより、ネームサーバーリストを更新できます。キャッシュサーバーがネームサーバーのアドレスを知っている限り、適切なNSレコードを再帰的に検索するのではなく、それを使用します。

ネームサーバーを移動するときは、古いネームサーバーと新しいネームサーバーを更新することが重要です。これにより、2つのゾーン定義が同期しなくなったときに発生する停止や不整合が防止されます。更新されたレコードは、NSレコードをキャッシュしたサーバーによって最終的に更新されます。これにより、キャッシュされたネームサーバーのリストが置き換えられます。

NSレコードは、DNS構成の正確性の確認にも役立ちます。検証ソフトウェアは、委任ゾーンのネームサーバー定義がゾーンによって提供されたものと一致することを確認します。このチェックは、すべてのネームサーバーで実行できます。不一致がある場合は、構成に誤りがある可能性があります。

NSレコードを使用すると、切断された（ローカル）ゾーンが許可されます。これらは、登録済みドメインのサブドメイン、または完全に新しいドメイン（TLDの変更のため推奨されません）の可能性があります。ネームサーバーとしてのネームサーバーは、ルートサーバーから再帰して到達できないゾーンを見つけることができます。他のネームサーバーは、ローカルゾーンのネームサーバーを検索するように構成できます。

分割DNS（内部/外部）の場合、別のDNSサーバーのセットが必要になる場合があります。この場合、NSリスト（およびおそらく他のデータ）は異なり、ゾーンファイルのNSレコードは適切なネームサーバーリストをリストします。

3
BillThor