NS记录在DNS域的顶端起什么作用？

$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记录在域顶点之下的作用是众所周知的。它们的存在是为了将子域的权限委派给另一个名称服务器。上面的例子应包括的NS记录sub1和sub2。这些允许名称服务器为自己认为不具有权威性的部分域提供引用。

在NS的目的，记录在一个域的顶点，ns1而ns2在这种情况下，似乎较少地受到互联网的大了解。我的理解（可能并不全面）如下：

1. 缓存DNS服务器不会使用它们来确定域的权威服务器。这是由在注册商级别定义的名称服务器胶来处理的。注册商从不使用此信息来生成粘合记录。
2. 它们不用于将整个域的权限委派给其他名称服务器。尝试使用ISC BIND之类的软件这样做完全不会导致“预期”的引用行为，因为名称服务器将继续认为自己对该区域具有权威性。
3. 名称服务器不使用它们来确定是否应返回权威响应（AA标志集）；该行为是由该软件被告知是该区域的主机还是从机来定义的。大多数名称服务器软件都会很高兴地为不符合上游粘合记录所包含信息的顶点NS记录提供服务，这反过来又会导致著名的DNS验证网站为该域生成警告。

在这种情况下，我们还剩下什么？如果似乎没有在整个Internet上缓存DNS服务器来使用它，我们为什么要定义此信息？

下属识别

主服务器使用Apex级别的NS记录来标识其下属。当权威名称服务器上的数据发生更改时，它将通过DNS NOTIFY消息（RFC 1996）将该消息发布给该列表上的所有对等方。这些服务器将依次回叫请求SOA记录（包含序列号），并决定是否拉近该区域的最新副本。

• 可以将这些消息发送到本NS节未列出的服务器，但这需要服务器特定的配置指令（例如ISC BIND的also-notify指令）。apex NS记录包含要在默认配置下进行通知的服务器的基本列表。
• 值得注意的是，辅助服务器也将基于这些NS记录相互发送NOTIFY消息，通常会导致记录拒绝。可以通过指示服务器仅发送其作为主服务器的区域的通知（BIND ：）来禁用此通知notify master;，或者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过期时，或者当有人明确请求这些记录的答案时，就会进行刷新。
  • A以及AAAA区域外数据的记录（即为区域外数据com定义粘合的名称服务器com，如example.net）肯定会被刷新，因为这是一个很好理解的概念，不应将名称服务器视为此类信息的权威来源。（RFC 2181）
  • 如果NS记录的值在引荐的父方和子方之间有所不同（例如，输入到注册服务商控制面板中的名称服务器NS与相同服务器上的记录不同），则所经历的行为将是不一致的，直至并包括子级NS记录被完全忽略。这是因为行为没有由标准很好地定义，并且实现在不同的递归服务器实现之间有所不同。换句话说，仅当域名的域名服务器定义在引用的父代和子代之间一致时，才可以预期整个Internet上的行为一致。

总而言之，如果引用的父方定义的记录与这些记录的权威版本不一致，则整个Internet上的递归DNS服务器将在目标之间反弹。最初，推荐中存在的数据将是首选，仅由权威性定义代替。由于缓存是通过Internet不断从头开始重建的，因此使用此配置，Internet不可能以单一现实版本为基础。如果权威记录按照标准进行了非法操作，例如将NS记录指向由a定义的别名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.

NS记录委派区域提供域定义的完整性。NS服务器本身将依赖于区域文件。他们不应尝试通过从根服务器进行递归查询来找到自己。区域文件中的NS记录提供了许多其他功能。

缓存服务器可以通过从其缓存中查询名称服务器来刷新名称服务器列表。只要缓存服务器知道名称服务器的地址，它将使用该地址，而不是递归地查找适当的NS记录。

移动名称服务器时，更新旧名称服务器和新名称服务器很重要。这将防止当两个区域定义不同步时导致的中断或不一致。更新的记录最终将由已缓存NS记录的任何服务器刷新。这将替换名称服务器的缓存列表。

NS记录还有助于确认DNS配置的正确性。验证软件通常会验证委派区域的名称服务器定义是否与该区域提供的名称匹配。可以在所有名称服务器上执行此检查。任何不匹配可能表示配置错误。

使用NS记录可以允许断开连接的（本地）区域。这些可能是注册域的子域，也可能是全新的域（由于TLD更改而不建议使用）。使用名称服务器作为其名称服务器的主机将能够通过从根服务器递归来找到无法访问的区域。可以将其他名称服务器配置为查找本地区域的名称服务器。

在分离DNS（内部/外部）的情况下，可能希望具有一组不同的DNS服务器。在这种情况下，NS列表（以及可能的其他数据）将有所不同，并且区域文件中的NS记录将列出相应的名称服务器列表。