假设我有一个以下example.com区域：
$TTL 120
@ IN SOA ns1 hostmaster (2018041509
300
150
600
60)
IN NS ns1
IN NS ns2
ns1 IN A 192.168.0.159
ns2 IN A 192.168.0.160
blah IN A 192.168.0.141
如上所示，ns1.example.com和ns2.example.com是该区域的两个权威名称服务器。其他名称服务器何时会查询它们？据我测试，只有当我使用 DNS 查找实用程序请求NS记录时才会查询这两个记录，即。192.168.0.159dig @192.168.0.159 -t NS example.com
答案1
对于普通用户来说，这真的不重要。如果你追求的是一致的交付和正常运行时间对于您的域名，规则非常简单：
- 您的名称服务器上的记录
NS应该仅指向A和AAAA记录。（不是CNAME记录等） - 确保包含 IPv4 地址（
A记录），否则运行单栈 IPv4 的 DNS 服务器将无法获取有关您的域的信息。 - 这些名称服务器的名称和 IP 地址应该与您的域名在注册商的控制面板中的配置方式相匹配。
就是这样。实现的方式和原因并不重要。如果您偏离此建议，结果将导致大量不一致和不可预测的行为。“未定义的行为”和“特定于实现的行为”等可怕的短语都适用于此。
照这样说，楼主问的这个问题完全合理。排除客户的明确请求和排除其他答案的权威部分内的间接引用，NS递归名称服务器何时明确请求这些记录？
您无意中进入了递归 DNS 服务器如何运作的一个比较模糊的领域。据我所知，我们仍然没有对管理互联网标准的修正案来阐明这“应该”如何运作。
关于递归 DNS 服务器如何了解你的域名的高层概述如下：
- 递归服务器收到 的请求
www.example.com. IN A。 - 如果该 DNS 记录在缓存中，则从缓存中应答。
- 如果 DNS 记录不在缓存中，它需要找到可以提供答案的名称服务器。它首先检查内存，看看是否已经识别了与域相关的名称服务器。它将咨询名称服务器以获取最具体它所知道的区域（又称域）。如果遇到更具体区域的引用，则将遵循这些引用，直到服务器将自己标识为 的权威服务器为止
www.example.com. IN A（或直到出现错误阻止它进一步遵循路径） 在“冷缓存”场景中（想象一个刚刚重启的 DNS 服务器），它必须从头开始最不具体并努力达到最具体以我们的例子来说
www.example.com. IN A，它将遵循以下一组引荐：.：又名“根”名称服务器。com.：的顶级域名名称服务器com.，从名称服务器获悉.。example.com.example.com.：注册表中列出的名称服务器com.，从com.名称服务器中学习到。www.example.com： 有时候是这样的仅有的如果example.com名称服务器为 提供了另一组名称服务器的引荐www。在本例中，我们假设情况并非如此。我们的记录答案A将直接来自 的名称服务器example.com。
沿着这条路径的每一步，递归服务器都会询问这些服务器是否负责www.example.com并收到对更具体的 DNS 服务器集的引用。在这条路径中，我们不需要请求 NS 记录。我们通过引用了解了更具体的服务器，直到一组服务器最终给出了权威答案www.example.com.（在这种情况下，example.com.名称服务器有我们的答案）
这就是事情变得奇怪的地方。
NS此时我们内存中的记录是通过引用获得的。对于名称服务器而言，这已经“足够好了”，但现在我们面临两个问题：
当与引荐中的 NS 记录关联的 TTL 过期时会发生什么？
当有人向我们询问这些 NS 记录的价值时会发生什么？
我们将对每一个问题进行探讨。
通过引荐获知的 NS 记录的 TTL 已过期。现在该怎么办？
这是名称服务器行为差异很大的地方。虽然它有些年头了（2011 年 3 月），但我强烈建议阅读Ólafur Guðmundsson 的演讲涵盖了该主题。幻灯片 11 - 13 向我们介绍了几种名称服务器行为模式。我将借用 Ólafur 的演示文稿中的相同术语：
Child Centric non sticky:
PPPCCCPPPCCCPPPCCCPP
Child Centric sticky
PPPCCCCCCCCCCCCCCCCC
Parent Centric
PPPPPPPPPPPPPPPPPPPP
在这种情况下，“父级”指的是我们通过引荐了解到的 NS 记录。“子级”指的是我们通过查询第一组 NS 记录的值时收到的权威答案了解到的 NS 记录example.com. IN NS。（即，当我们要求这些名称服务器返回他们自己的NS记录时……理论上）
所有这些模式的共同点是，内存中的 NS 数据首先从父级学习。这是既定事实，因为它是该过程工作方式的基础。实现的不同之处在于它们随后会做什么：
儿童中心不粘最初会优先选择父级，然后切换到子级。一旦子级过期，NS 记录将被“遗忘”并从头开始重新学习，以便为合并父级名称服务器的更改提供机会。如果没有这个，与过期域名相关的名称服务器更改将不会被捕获——包括过期和续订。缺点是这些 NS 记录定义偶尔不一致，导致递归服务器
www.example.com. IN A根据当前正在访问的服务器对特定 DNS 记录（即）返回不同的响应。儿童中心粘贴是一种非常有问题的实现，其中名称服务器“卡”在定义的子端，而父端直到清除缓存或重新启动服务器才会重新评估。由于与之相关的问题非常明显，它通常被认为是这些实现中最糟糕的。（一个例子是此问答有人在观察该行为）
以家长为中心是一个有趣的实现，它完全避开了子/权威 NS 记录的值。其背后的一般思想是，在父级和子级的值之间交替会造成比它本身更大的麻烦和混乱。通过完全忽略 NS 记录的“权威”版本并始终优先选择引用（没有它就不可能了解权威记录），您可以完全避免以子级为中心的非粘性的“翻转”问题。主要缺点是一些边缘情况，其中来自子级的 NS 记录可以帮助加快从旧名称服务器迁移事先的注册表中所做的更改。当您与某些愚蠢的注册商打交道时，这可能会很有用，这些注册商也提供 DNS 服务，但当您将域的服务器更改为指向其他位置时，会立即删除您的所有 DNS 数据。
正如您所见，这是一个复杂的主题，如果不进行广泛的测试，就很难记录下来。之所以这样，是因为到目前为止，该领域的标准仍然很宽松，至少据我所知是这样。
当客户端向递归器询问 NS 记录的值时会发生什么？
再次强调，这取决于情况。
RFC 2181强烈反对名称服务器返回从答案部分的引荐中了解到的缓存的名称服务器数据，但并没有完全禁止它：（“不应该”）
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.
[...] Note that throughout this document, "authoritative" means a
reply with the AA bit set.
尽管有这个警告，我们能返回从我们的答案中的引用中观察到的 NS 记录，因为它没有被明确禁止。我怀疑这更有可能发生在以父母为中心的实现中，但目前我面前没有任何好的数据。当我找到时间并更新此答案时，我会自己做一些测试。
如果服务器缓存了来自引荐来源的名称服务器，会发生什么情况？做遵守 RFC 2181？在 ISC BIND 的情况下（至少在我最熟悉的 9.10 和 9.11 实现中），NS来自客户端的记录的明确请求会触发对子名称服务器的立即刷新。最容易观察到的是客户端名称服务器指向 BIND 认为已损坏的内容，例如指向 CNAME 记录的 NS 记录。BIND 最初将能够使用从初始引用（包括胶水）收到的信息来回答域的问题，但一旦收到记录请求NS并且名称服务器尝试重新学习它需要与之通信的名称服务器信息，域将立即停止工作。
结束免责声明：这是递归服务器操作中一个极其模糊和令人困惑的领域。自从我上次深入探讨这个主题以来，有些事情可能已经发生了变化。我很乐意修改此处提供的任何信息，但请提供具体数据引用在可能的情况。