澄清为什么 DNS 区域文件需要 NS 记录

Question

这个问题最初是在这里问的： 为什么 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 记录区域文件，那么它将无法知道在哪里查看。）

谢谢

Answer 1

让我们稍微分解一下。

TLD 区域中的 NS 记录（例如，example.com NS ...in com）是委托记录。

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

区域本身（即example.com NS ...in example.com）中的 NS 记录是规范记录。

区域本身 ( ns1.example.com A ...in example.com) 中的 A 和 AAAA 记录是地址记录，简单明了。

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

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

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

只有权威答案才应被视为正确的查询响应；其他一切要么是委托，要么是某种错误。对非权威服务器的委托称为“跛脚”委托，这意味着解析器必须回溯一步并尝试其他命名的 DNS 服务器。如果委托中不存在权威的可访问名称服务器，则名称解析会失败（否则，它只会比正常情况慢）。

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

在许多边缘情况下，这实际上会产生严重的差异，主要集中在单个区域内的多个主机名标签（可能相当常见，例如反向 DNS 区域，特别是对于大型动态 IP 范围），或者当名称服务器列表之间存在差异时父区域和有问题的区域（这很可能是一个错误，但也可以故意这样做）。

您可以使用dig它的+norec（不请求递归）和@服务器说明符功能更详细地了解它是如何工作的。下面是实际解析 DNS 服务器如何工作的说明。查询unix.stackexchange.com从例如开始的 A 记录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来自其他来源的权威服务器的答案，而不是已经被父区域命名为 deleged-to 的来源com。细节取决于服务器，但目的是尽可能多地缓存，同时不打开谷仓门，允许 Internet 上的任何随机名称服务器覆盖任何未正式受其“管辖”的委托记录。