部下の識別
ApexレベルのNSレコードは、その下位を識別するためにマスターサーバーによって使用されます。権威あるネームサーバー上のデータが変更されると、DNS NOTIFYメッセージ（RFC 1996）を介して、そのリスト上のすべてのピアにこれを通知します。これらのサーバーは、SOAレコード（シリアル番号を含む）の要求でコールバックし、そのゾーンの最新のコピーをプルダウンするかどうかを決定します。
NSセクションにリストされていないサーバーにこれらのメッセージを送信することは可能ですが、これにはサーバー固有の構成ディレクティブ（ISC BINDのalso-notifyディレクティブなど）が必要です。Apex NSレコードは、デフォルト構成で通知するサーバーの基本リストを構成します。- セカンダリサーバーも、これらの
NSレコードに基づいてNOTIFYメッセージを相互に送信し、通常は拒否のログが記録されることに注意してください。これを無効にするには、サーバーがマスターであるゾーンにのみ通知を送信するように指示するnotify master;か（BIND：）、またはNS構成で明示的に定義された通知を完全に優先してベースの通知をスキップします。（BIND： notify explicit;）
信頼できる定義
上記の質問には誤りが含まれていました。
ドメインの権限のあるサーバーを決定するために、DNSサーバーをキャッシュすることで使用されません。これは、レジストラレベルで定義されているネームサーバーグルーによって処理されます。レジストラは、この情報を使用してグルーレコードを生成することはありません。
これは簡単な結論ですが、正確ではありません。NS（たとえば、レジストラのアカウント内で定義されるような）レコードとグルーレコードのデータは権威ではありません。権限が委任されているサーバーに存在するデータよりも「より信頼できる」と見なすことができないのは理にかなっています。これは、紹介にはaa（Authoritative Answer）フラグが設定されていないという事実によって強調されています。
説明する：
$ 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が期限切れになるか、誰かがそれらのレコードの回答を明示的に要求すると発生します。
AAAAAゾーン外のデータ（つまり、ゾーンcom外のデータの接着剤を定義するネームサーバーなど）のレコードは、ネームサーバーをそのような情報の信頼できるソースと見なすべきではないというよく知られた概念であるため、間違いなく更新されます。（RFC 2181）comexample.netNSレフェラルの親側と子側でレコードの値が異なる場合（レジストラコントロールパネルに入力されたネームサーバーが、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.