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

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

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

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

既然如此，我们还剩下什么？如果 Internet 上的缓存 DNS 服务器似乎不会使用这些信息，为什么要定义这些信息？

Answer 1

下属身份

主服务器使用顶级 NS 记录来识别其下属。当权威名称服务器上的数据发生更改时，它将通过DNS NOTIFY消息 ( RFC 1996 ) 向该列表中的所有对等方通告这一点。这些服务器将依次回电请求SOA记录（其中包含序列号），并决定是否提取该区域的更新副本。

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

总而言之，如果在引用的父端定义的记录与这些记录的权威版本不一致，则整个 Internet 中的递归 DNS 服务器将在目标之间反弹。最初，推荐中出现的数据将是首选，只会被权威定义所取代。由于缓存不断在 Internet 上从头开始重建，因此 Internet 不可能使用这种配置解决单一版本的现实。如果权威记录按照标准做了一些非法的事情，例如将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.