$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 NSlogging在域的顶点下的作用是很好理解的; 他们存在委托一个子域的权限到另一个域名服务器。 上面的例子将包括sub1和sub2的NSlogging。 这些允许域名服务器提供不认为自己具有权威性的部分域名的引用。
在这种情况下，NSlogging在域的顶点ns1和ns2的目的似乎不太被互联网所理解。 我的理解（可能不是整体的）如下：
AA标志设置）; 该行为由软件被告知是该区域的主人还是从属人来定义。 大多数域名服务器软件都会非常高兴地为apex NSlogging提供服务，这些logging不同意上游粘贴logging所包含的信息，从而导致知名的DNSvalidation网站为域名生成警告。 在这种情况下，我们剩下的是什么？ 为什么我们要定义这个信息，如果这个信息似乎并没有被互联网上的DNS服务器所caching？
主服务器使用顶点级NSlogging来标识其下属。 当权威名称服务器上的数据发生变化时，它将通过DNS NOTIFY消息（ RFC 1996 ）将其通告给该列表中的所有对等方。 这些服务器将依次回应SOAlogging（包含序列号）的请求，并决定是否下拉该区域的更新副本。
NS部分列出的服务器，但是这需要服务器特定的configuration指令（如ISC BIND的also-notify指令）。 apex NSlogging包含在默认configuration下通知的基本服务器列表。 NSlogging向对方发送NOTIFY消息，通常会导致login拒绝。 这可以通过指示服务器只发送通知给他们主控的区域（BIND： notify master; ）来实现，或者跳过基于NS的通知来完全通知configuration中明确定义的通知。 （BIND： notify explicit; ） 上面的问题包含了一个谬误：
它们不被高速cachingDNS服务器用来确定域的权威服务器。 这由名称服务器胶水处理，在注册商一级定义。 注册商从不使用这些信息来生成胶水logging。
这是一个容易得出的结论，但不准确。 NSlogging和胶水logging数据（如在您的注册商帐户中定义的数据）不是权威性的。 理所当然的是，它们不能被认为比权限被授权的服务器上的数据更“权威”。 这是强调推介没有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
请注意，上述回覆中没有旗帜。 转介本身不具有权威性。 另一方面，被引用的服务器上的数据是权威的。
$ 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.
也就是说，这种关系可能会变得非常混乱，因为无法了解这些NSlogging的权威版本，而没有在引用的父级侧定义的非权威NSlogging。 如果他们不同意会发生什么？
NS ， A和AAAAlogging在刷新时最终可能会被replace。 当这些临时logging上的TTL过期时，或者当某人明确请求这些logging的答案时，刷新就会发生。
A和AAAAlogging超出区域数据（即com域名服务器定义com区域以外的数据的胶水，如example.net ）肯定会被刷新，因为它是一个很好理解的概念，名称服务器不应该是被认为是这种信息的权威来源。 （RFC 2181） NSlogging的值在引用的父方和孩方之间不同（例如，input到注册服务商控制面板中的名称服务器与在同一服务器上的NSlogging不同时），所经历的行为将是不一致的包括孩子NSlogging被完全忽略。 这是因为标准没有很好地定义行为，而不同的recursion服务器实现之间的实现是不同的。 换句话说， 如果一个域名的域名服务器定义在一个引用的父方和子方之间是一致的，那么互联网上的一致行为就只能是预期的 。 如果在引用的父节点上定义的logging不符合这些logging的授权版本，整个互联网上的recursionDNS服务器将在目的地之间反弹。 最初提交的数据将是首选，只能由权威定义取代。 由于caching不断地通过互联网从头开始重build，因此互联网不可能通过这种configuration来解决单一版本的现实问题。 如果权威logging按照标准做了非法的事情，例如将NSlogging指向由CNAME定义的别名，则这更难以排除故障; 该域将在工作和中断之间交替进行拒绝违规的软件。 （即ISC BIND /命名）
RFC 2181§5.4.1为这个数据的可信性提供了一个排名表，并且明确指出，与引荐和粘连相关联的caching数据不能作为对它们引用的logging的显式请求的回答而被返回。
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.
NSlogging委托区域提供域定义的完整性。 NS服务器本身将依靠区域文件。 他们不希望通过从根服务器执行recursion查询来发现自己。 区域文件中的NSlogging提供了许多其他function。
高速caching服务器可以通过从其高速caching中查询名称服务器来刷新名称服务器列表。 只要caching服务器知道名称服务器的地址，它就会使用它而不是recursion查找适当的NSlogging。
移动名称服务器时，更新旧名称服务器以及新名称服务器非常重要。 这将防止当两个区域定义不同步时将导致停机或不一致。 任何已cachingNSlogging的服务器最终都会刷新更新的logging。 这将取代名称服务器的caching列表。
NSlogging还有助于确认DNSconfiguration的正确性。 validation软件通常会validation委派区域的名称服务器定义是否与区域提供的相匹配。 该检查可以在所有名称服务器上执行。 任何不匹配都可能表示configuration错误。
拥有NSlogging允许断开（本地）区域。 这些可能是注册域名的子域名，也可能是全新的域名（由于TLD更改，不推荐）。 使用名称服务器作为名称服务器的主机将能够通过从根服务器recursion来查找无法访问的区域。 其他名称服务器可能被configuration为查找本地区域的名称服务器。
在分离DNS（内部/外部）的情况下，可能希望有一组不同的DNS服务器。 在这种情况下，NS列表（以及可能的其他数据）将会不同，区域文件中的NSlogging将列出适当的名称服务器列表。