Why do DNS zone files require NS records?
总结一下：
“当我去我的注册商并购买example.com时,我会告诉我的注册商我的名称服务器是ns1.example.org和ns2.example.org”.
但请有人澄清以下内容：
注册后,.com注册表现在将有一条记录,告诉解析器需要访问ns1.example.org或ns2.example.org才能找到example.com的IP地址. IP地址位于ns1.example.org上的区域文件中的A记录中,并且在ns2.example.org上具有相同的副本.
但是,在此文件中,还必须有2条NS记录,它们将ns1.example.org和ns2.example.org列为名称服务器.但由于我们已经在其中一台服务器上,这似乎是重复的信息.
最初给出问题的答案是区域文件中列出的名称服务器是“权威的”.如果名称服务器不匹配,则权威的名称服务器优先.这一切都非常好,但解析器使用.com注册表中列出的名称服务器到达名称服务器,如果名称服务器不匹配,那么解析器将在错误的名称服务器上查找区域文件并且不会能够找到它.
或者是.com注册表从区域文件ns记录中提取名称服务器信息的情况？ (但是我想如果你在没有告诉注册表的情况下更改ns记录区域文件,那么就无法知道在哪里查看.)
谢谢
解决方法
TLD区域中的NS记录(例如,example.com NS … in com)是委派记录.
TLD区域中的A和AAAA记录(例如,ns中的ns1.example.com A …)是粘合记录.
区域中的NS记录(即example.com中的example.com NS …)是权限记录.
区域中的A和AAAA记录(在example.com中为ns1.example.com A …)是地址记录,简单明了.
当(递归)解析器开始时没有区域数据的缓存而只有根区域缓存(用于引导名称解析过程),它将首先转到.,然后com .. com服务器将响应一个权威部门的回复基本上说“我不知道,但在这里找一个知道的人”,与服务器相同.关于com.此查询响应不具有权威性,并且不包括已填充的答案部分.它还可以包括所谓的附加部分,其给出特定服务器知道的任何主机名的地址映射(来自粘合记录,或者在递归解析器的情况下,来自先前高速缓存的数据).解析器将接受此委派响应,必要时解析NS记录的主机名,然后继续查询已委派权限的DNS服务器.如果您具有深层委托层次结构,则此过程可能会重复多次,但最终会导致设置了“权威答案”标记的查询响应.
重要的是要注意解析器(通常,希望)不会尝试分解被解析的主机名,逐个询问它,而只是将其完整地发送到它知道的“最佳”服务器.由于Internet上的普通权威名称服务器对绝大多数有效DNS名称都不具有权威性,因此响应将是指向其他DNS服务器的非权威委派响应.
现在,不必在任何地方的委托或权限记录中命名服务器以对区域具有权威性.例如考虑私有主服务器的情况;在这种情况下,存在权威的DNS服务器,只有该区域的从DNS服务器的管理员知道. DNS服务器对于区域具有权威性,如果通过某种机制,它认为它具有对所涉及区域的完整和准确的知识.例如,如果在定义为SOA记录中的到期时间的时间限制内无法访问配置的主服务器,则通常权威的DNS服务器可能变为非权威的.
只有权威的答案才应被视为正确的查询回复;其他一切都是代表团,或某种错误.对非权威服务器的委派称为“跛脚”委托,并且意味着解析器必须回溯一步并尝试其他命名的DNS服务器.如果委派中不存在权威可访问的名称服务器,则名称解析失败(否则,它将比正常情况慢).
这一点非常重要,因为不能缓存非权威数据.怎么可能,因为非权威的服务器没有完整的图片？因此,权威服务器必须能够自己回答“谁应该是权威的,为什么？”的问题.这是区内NS记录提供的信息.
有许多边缘情况,这实际上可以产生严重的差异,主要集中在单个区域内的多个主机名标签(可能相当常见,例如反向DNS区域,特别是对于大型动态IP范围)或名称服务器列表之间的差异父区域和相关区域(最有可能是错误,但也可以有意识地完成).
您可以使用dig及其norec(不请求递归)和@ server说明符功能,更详细地了解其工作原理.以下是实际解析DNS服务器如何工作的说明.从例如开始查询unix.stackexchange.com的A记录. a.root-servers.net：
$dig unix.stackexchange.com. A @a.root-servers.net. +norec
仔细查看标志以及每个部分的计数. qr是查询响应,aa是权威答案.请注意,您只能委派给com服务器.手动遵循该委托(在现实生活中,递归解析器将使用附加部分中的IP地址(如果提供),或者如果委派响应中未提供IP,则启动其中一个命名名称服务器的单独名称解析,但我们将跳过该部分,然后回到操作系统的正常解析器以简化示例)：
$dig unix.stackexchange.com. A @a.gtld-servers.net. +norec
现在您看到stackexchange.com被委托给(以及其他)ns1.serverfault.com,您仍然没有得到权威的答案.再次跟随代表团：
$dig unix.stackexchange.com. A @ns1.serverfault.com. +norec ... ;; ->>HEADER<<- opcode: QUERY,status: NOERROR,id: 35713 ;; flags: qr aa; QUERY: 1,ANSWER: 1,AUTHORITY: 3,ADDITIONAL: 3 ;; QUESTION SECTION: ;unix.stackexchange.com. IN A ;; ANSWER SECTION: unix.stackexchange.com. 300 IN A 198.252.206.16
答对了！我们得到了一个答案,因为aa标志已设置,它恰好包含一个我们希望找到的IP地址. As an aside,it’s worth noting that at least at the time of my writing this post,the delegated-to and the listed-authority name servers lists differ,showing that the two do not need to be identical.我上面举例说明的基本上是任何解析器所做的工作,除了任何实用的解析器也会缓存响应,因此它不必每次都击中根服务器.
从上面的示例中可以看出,委托和粘合记录的用途与区域本身的权限和地址记录不同.
缓存,解析名称服务器通常也会对返回的数据进行一些健全性检查,以防止缓存中毒.例如,它可能拒绝缓存一个答案,该答案将来自除已被父区域命名的源之外的源命名为com的权威服务器作为com的已删除.细节是依赖于服务器的,但目的是尽可能地缓存,同时不打开谷仓门,允许互联网上的任何随机名称服务器覆盖任何非正式在其“管辖范围”下的任何事件的委托记录.
