domain-name-system – 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记录在域顶点下的作用已被充分理解;它们的存在是为了将子域的权限委托给另一个域名服务器.上面的例子包括sub1和sub2的NS记录.这些允许名称服务器分发它不认为自己具有权威性的域的部分引用.

在这种情况下,NS记录在域顶点ns1和ns2的目的似乎不太为互联网所理解.我的理解(可能不是整体的)如下：

>缓存DNS服务器不会使用它们来确定域的权威服务器.这由nameserver glue处理,其在注册商级别定义.注册商从不使用此信息来生成粘合记录.
>他们are not用于将整个域的权限委托给其他域名服务器.尝试使用诸如ISC BIND之类的软件这样做根本不会产生“预期的”引用行为,因为名称服务器将继续认为自己对该区域具有权威性.
>名称服务器不使用它们来确定是否应该返回权威响应(AA标志设置);该行为是由软件是否被告知为区域的主服务器或从服务器来定义的.大多数名称服务器软件都会非常乐意为顶级的胶合记录提供不同意的顶级NS记录,这反过来会导致众所周知的DNS验证网站为该域生成警告.

在这种情况下,我们还剩下什么？如果通过在互联网上缓存DNS服务器似乎没有消费这些信息,我们为什么要这样定义？

解决方法

下属识别

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

>可以将这些消息发送到NS部分中未列出的服务器,但这需要服务器特定的配置指令(例如ISC BIND的also-notify指令). apex NS记录包含要在默认配置下通知的基本服务器列表.
>值得注意的是,辅助服务器还将根据这些NS记录向对方发送NOTIFY消息,通常会导致拒绝记录.可以通过指示服务器仅发送其主控区域的通知(BIND：notify master;),或者跳过基于NS的完全通知,以支持在配置中明确定义的通知来禁用此功能. (BIND：notify explicit;)

权威定义

上面的问题包含一个谬误：

They are not used by caching DNS servers in order to determine the authoritative servers for the domain. This is handled by nameserver glue,which is defined at the registrar level. The registrar never uses this information to generate the glue records.

这是一个容易得出的结论,但不准确. 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,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记录被完全忽略.这是因为标准没有很好地定义行为,并且实现在不同的递归服务器实现之间变化.换句话说,只有在域名的名称服务器定义在引荐的父方和子方之间保持一致时,才能预期整个互联网上的一致行为.

如果在引用的父方定义的记录与这些记录的权威版本不一致,那么整个互联网中的递归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.