阐明为什么DNS区域文件需要NS记录

最初在此处提出此问题： 为什么DNS区域文件需要NS记录？

总结一下：“当我去我的注册商并购买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区域（例如example.com NS ...中的com）中的NS记录是委托记录。

TLD区域（例如ns1.example.com A ...中的com）中的A和AAAA记录是粘合记录。

区域本身（即example.com NS ...中的example.com）中的NS记录是授权记录。

区域本身（ns1.example.com A ...中的example.com）中的A和AAAA记录是简单明了的地址记录。

当（递归）解析程序开始时，没有区域数据的缓存，而只有根区域缓存（用于引导名称解析过程）时，它将首先进入.，然后进入com.。该com服务器将与回应的权威部分响应基本上说：“我不知道，但看看这里的人谁是否知道”，相同服务器.大约做com。该查询响应不是权威性的，并且不包括填充的答案部分。它也可能包括所谓的附加这部分提供了特定服务器知道的任何主机名的地址映射（从粘合记录，或者在递归解析器的情况下，从先前缓存的数据）。解析程序将获取此委派响应，并在必要时解析NS记录的主机名，然后继续查询已委派了授权的DNS服务器。如果您具有较深的委派层次结构，则此过程可能会重复多次，但最终会导致查询响应设置了“权威答案”标志。

重要的是要注意，解析器（通常希望是）不会尝试分解要解析的主机名以逐段地询问它，而只是将其完整地发送到它所知道的“最佳”服务器。由于Internet上的一般权威名称服务器对绝大多数有效DNS名称都不具有权威性，因此该响应将是指向其他某些DNS服务器的非权威性委派响应。

现在，不必在任何要授权区域的授权或授权记录中命名服务器。考虑例如专用主服务器的情况；在这种情况下，存在一个权威的DNS服务器，只有该区域的从属DNS服务器的管理员才知道。如果DNS服务器通过某种机制认为对所讨论的区域具有完整而准确的知识，则它是该区域的权威。如果在SOA记录中定义为到期时间的时间限制内无法访问已配置的主服务器，则通常具有权威性的DNS服务器可能会变为非权威性。

仅应将权威性答案视为正确的查询响应；其他一切都是委派或某种错误。到非权威服务器的委派称为“ lam行”委派，这意味着解析器必须回溯一个步骤并尝试其他命名的DNS服务器。如果委托中不存在可访问的权威名称服务器，则名称解析将失败（否则，它将比正常速度慢）。

这很重要，因为不能缓存非授权数据。由于非权威服务器没有全貌，怎么可能？因此，权威服务器必须能够自行回答“谁应该是权威的，为什么是谁？”的问题。这就是区域内NS记录提供的信息。

在许多极端情况下，这实际上可能会产生重大影响，主要集中在单个区域内的多个主机名标签上（可能相当普遍，例如，对于反向DNS区域，尤其是大型动态IP范围），或者当名称服务器列表在父区域和相关区域（最有可能是错误，但也可以有意地进行）。

您可以使用dig及其+norec（不请求递归）和@服务器说明符功能来了解更多细节。以下是实际解析DNS服务器如何工作的说明。查询A记录unix.stackexchange.com，例如a.root-servers.net：

$ dig unix.stackexchange.com. A @a.root-servers.net. +norec

仔细查看flags每节计数。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地址。顺便说一句，值得注意的是，至少在我撰写本文时，“委托人”和“列出单位”的名称服务器列表有所不同，这表明两者不必相同。上面我举例说明的基本上是任何解析器所做的工作，除了任何实际的解析器也会沿途缓存响应，因此不必每次都击中根服务器。

从上面的示例中可以看到，委托和粘合记录的目的与区域本身中的权限和地址记录不同。

缓存的解析名称服务器通常也会对返回的数据进行一些完整性检查，以防止缓存中毒。例如，它可能会拒绝com从源（而不是已经由父区域命名为委派给的源）中缓存命名权威服务器的答案com。详细信息取决于服务器，但其目的是在不打开允许Internet上任何随机名称服务器覆盖其正式管辖权范围之外的任何内容的委托记录的情况下，尽可能多地缓存。

.com注册表是“胶水记录”，具有您的域名服务器的位置作为IP地址。解析器无法知道您的DNS服务器的“身份”，因此它使用NS记录来确保数字匹配。

DNS请求-> .com注册表（ip为xxxx）-> DNS（NS xxxx）匹配，解析。

如果它们不匹配或不存在，那么这是该域的非权威性答案。