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

澄清 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 记录,区域文件没有告诉注册表,那么它就无法知道在哪里查找。)

谢谢

答案1

让我们稍微分析一下。

TLD 区域中的 NS 记录(例如example.com NS ...com代表团记录。

TLD 区域中的 A 和 AAAA 记录(例如ns1.example.com A ...com胶水记录。

区域本身(即)example.com NS ...中的 NS 记录example.com权威记录。

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

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

需要注意的是,解析器(通常,希望如此)不会尝试分解正在解析的主机名并逐个询问,而只会将其完整地发送到它所知道的“最佳”服务器。由于互联网上的平均权威名称服务器对于绝大多数有效 DNS 名称都是非权威的,因此响应将是指向其他 DNS 服务器的非权威委派响应。

现在,服务器不必在任何地方的授权或授权记录中命名即可成为区域的权威服务器。例如,考虑私有主服务器的情况;在这种情况下,存在一个权威 DNS 服务器,只有该区域的从属 DNS 服务器的管理员知道它。如果 DNS 服务器通过某种机制认为自己对某个区域具有完整而准确的了解,则该 DNS 服务器对该区域具有权威性。例如,如果在 SOA 记录中定义的到期时间期限内无法到达配置的主服务器,则通常具有权威性的 DNS 服务器可能会变为非权威性。

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

这一切都很重要,因为非权威数据不能被缓存。既然非权威服务器无法掌握全部情况,那怎么可能呢?因此,权威服务器必须能够自行回答“谁应该具有权威性,以及为什么具有权威性?”这个问题。这是区域内 NS 记录提供的信息。

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


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已被父区域指定为 的授权服务器的来源之外的来源的答案com。细节取决于服务器,但目的是尽可能多地缓存,同时不打开任何随机名称服务器的大门,允许互联网上的任何随机名称服务器覆盖不在其“管辖范围”内的任何东西的授权记录。

答案2

.com 注册是“粘合记录”,其中以 IP 地址的形式记录了您的名称服务器的位置。解析器无法知道您的 DNS 服务器的“身份”,因此它使用 NS 记录来确保数字匹配。

DNS 请求 -> .com 注册中心(ip 为 xxxx) -> DNS(NS xxxx)匹配,解析。

如果它们不匹配或者不存在,那么对于该域来说这是一个非权威的答案。

相关内容