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

Question

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

域名顶端的 NS 记录的用途，ns1在ns2这种情况下，似乎不太为互联网所理解。我的理解（可能不全面）如下：

1. 缓存 DNS 服务器不会使用它们来确定域的权威服务器。这由名称服务器胶水，这是在注册商级别定义的。注册商绝不使用此信息来生成胶水记录。
2. 他们不是用于将整个域的权限委托给其他名称服务器。尝试使用 ISC BIND 等软件执行此操作根本不会导致“预期的”引用行为，因为名称服务器将继续认为自己对该区域具有权威性。
3. 名称服务器不会使用它们来确定是否应返回权威响应（AA设置标志）；该行为由软件是否被告知是区域的主服务器还是从服务器来定义。大多数名称服务器软件都会很乐意为与上游胶水记录所含信息不一致的顶点 NS 记录提供服务，这反过来会导致知名 DNS 验证网站针对该域生成警告。

在这种情况下，我们还剩下什么呢？如果这些信息似乎没有被整个互联网上的缓存 DNS 服务器所使用，我们为什么要定义这些信息呢？

Answer 1

下属识别

顶级 NS 记录由主服务器用来识别其下属服务器。当权威名称服务器上的数据发生变化时，它将通过DNS NOTIFY消息 (RFC 1996) 发送给该列表上的所有对等服务器。这些服务器将依次回调并请求记录SOA（其中包含序列号），并决定是否下载该区域的较新副本。

• 可以将这些消息发送到本NS节中未列出的服务器，但这需要服务器特定的配置指令（例如 ISC BIND 的also-notify指令）。顶级 NS 记录包括在默认配置下要通知的服务器的基本列表。
• 值得注意的是，辅助服务器也会根据这些记录相互发送 NOTIFY 消息NS，通常会导致记录拒绝。可以通过指示服务器仅发送它们所主控的区域的通知 (BIND: notify master;) 来禁用此功能，或者完全跳过NS基于的通知，转而使用配置中明确定义的通知。(BIND: 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 到期时，或者当有人明确请求这些记录的答案时。
• AAAAA区域外数据的记录（即定义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.

Answer 2

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

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

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

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

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

在拆分 DNS（内部/外部）的情况下，可能需要使用不同的 DNS 服务器集。在这种情况下，NS 列表（以及其他数据）将有所不同，区域文件中的 NS 记录将列出相应的名称服务器列表。