DNS 解析器与 NS 记录 TTL

当 DNS 解析器为权威名称服务器查找域/区域时，它是否会获取所有 6 条记录并循环遍历它们？

是的，一个适当的递归名称服务器会考虑所有的名称服务器，并会在以后每次尝试查询最快的一个。

粗略的算法是这样的：

• 从冷启动（无缓存）开始，随机尝试所有这些，记录它们的回复速度（您可能需要将 UDP 案例与 TCP 案例分开）
• 一段时间后，根据之前的回复开始更频繁地使用最快的
• 但请注意，您需要确保不要无限期地坚持使用任何给定的名称服务器，您也必须“不时地”尝试其他名称服务器。为什么？因为网络拓扑可以改变，名称服务器本身也是如此。ns3对于您的特定有利位置，今天可能是更快的，但也许明天它会ns5代替；所以你必须使用最快的，但并非总是如此，只是为了确保能够自动发现任何其他的，比你认为现在最快的更快。

如果解析器使用第一个 NS 服务器

停在这里。记录是以一组的形式出现的，而不是一个列表。也就是说，DNS 中没有固有的顺序。当然，线路或显示表示中有一个命令，但它不是来自协议。

记录集是袋子：你得到记录，没有订单。事实上，您可以看到许多名称服务器，对于完全相同的查询，如果回复中有多条记录，每次查询时都会对记录进行不同的排序，这正是为了对抗只考虑第一项和无视其他人。

当该权威名称服务器没有响应时

请参阅上面的算法：如果NS集合中的一个名称服务器没有响应，您可以认为它与“从任何其他名称服务器响应最慢”相同。客户端 DNS 有超时，因此它不会无限等待，而是标记此特定名称服务器太慢，并将切换到其他名称服务器。因此，第一次您会受到惩罚，因为系统必须尝试联系该名称服务器，稍等（几秒钟），重试并在某个时候停止使用该名称服务器。在那个斜坡之后，它将使用其他名称服务器，事情会很快。但是，当您第一次必须通过真正尝试联系它来发现给定名称服务器很慢/没有响应时，如果不尝试就无法推断出问题。

这是否意味着我需要为 NS 记录设置短 TTL？

也许吧，但这几乎是无关紧要的。为什么？因为您的NS记录发布在您域的父区域中，以确保 DNS 委派。当然，它们是带有 TTL 的，因为所有记录都附加了一个 TTL，但是它们是在您无法控制的区域中发布的，因此您不能选择它们的 TTL 值！

（这里有一个关于这些记录的复杂/未完全完成的讨论，例如NS存在于两部分：父母和孩子，问题是“哪个是真正权威的”？如果父母在NS记录上的 TTL 为 1 周并且您在您的区域中相同的NS记录的 TTL 为 1 秒，递归名称服务器应该做什么？人们可能会得出这样的结论：通常委托的子部分是权威的，所以 1 秒在这里获胜；实际上是多个 DNS 实现是“以父母为中心”的，也就是说他们使用父母一方的数据，所以在那里赢了 1 周）

TTL 始终是一种权衡。一旦知道，有些人会立即得出结论，在非常低的 TTL 下事情会更好地工作……这在某些情况下是正确的，而在其他情况下则不然。缓存很好，如果它们不存在（又名：没有使用足够大的 TTL），您将无法应对任何小问题，这将使一切都消失，因为缓存已经使名称过期。

此外，在沿所有名称服务器循环、尝试超时并收敛于最快的名称服务器时，TTL 值对上述算法没有（或几乎没有）影响。

因此，如果您查看 TLD 名称服务器（托管NS该 TLD 下所有域的记录）或各种建议中发生的情况，您通常会看到NSTTL 为 1 或 2 天的记录。

关于解析器 DNS 如何与无响应的 NS 及其 TTL 一起工作的任何建议？

每个解析器都有自己的 :-) 这实际上并没有由协议指定，它是一个实现细节。您可以研究可以安装的源代码，但可能无法从大型公共递归 DNS 提供商那里收集有关该源代码的详细信息。

您可以在此处找到更多详细信息：

• https://securityintelligence.com/subverting-binds-srtt-algorithm-derandomizing-ns-selection/
• https://www.nanog.org/meetings/nanog54/presentations/Tuesday/Yu.pdf

RFC 1034 §5.3.3 也确实提供了一些信息（另请注意，它考虑了您忘记的一种情况：给定的名称服务器可能有多个 IP 地址 - 今天甚至应该总是如此，一个 IPv4 和一个 IPv6 - 和不能保证每次都能在相同的时间内获得结果）：

除了服务器的名称和地址之外，SLIST 数据结构还可以进行排序以优先使用最好的服务器，并确保所有服务器的所有地址都以循环方式使用。排序可以是优先选择本地网络上的地址而不是其他地址的简单功能，或者可能涉及来自过去事件的统计数据，例如以前的响应时间和击球平均值。

步骤 3 发出查询，直到收到响应。该策略是循环遍历所有服务器的所有地址，每次传输之间有一个超时。在实践中，使用多宿主主机的所有地址非常重要，并且当多个解析器竞争同一个名称服务器甚至偶尔使用单个解析器时，过于激进的重传策略实际上会减慢响应速度。SLIST 通常包含用于控制超时和跟踪先前传输的数据值。

RFC 1035 §7.2 有这样的说法：

为了完成 SLIST 的初始化，解析器将它拥有的任何历史信息附加到 SLIST 中的每个地址。这通常包括地址响应时间的某种加权平均值，以及地址的成功率（即地址对请求做出响应的频率）。请注意，此信息应按地址保存，而不是按名称服务器保存，因为特定服务器的响应时间和平均成功率可能因地址而异。另请注意，此信息实际上特定于解析器地址/服务器地址对，因此具有多个地址的解析器可能希望为其每个地址保留单独的历史记录。此步骤的一部分必须处理没有此类历史记录的地址；

请注意，无论何时遵循委托，解析器算法都会重新初始化 SLIST。

该信息建立了可用名称服务器地址的部分排名。每次选择一个地址时，应更改状态以防止再次选择它，直到尝试了所有其他地址。每次传输的超时时间应比平均预测值大 50-100%，以允许响应变化。

还要完成，更具体地说：

正如 imperva 的这篇文章所示

您引用的这篇文章讨论了使用 Dyn 名称服务器的人在出现中断时发生的问题。那么，是的，如果您只使用 Dyn 名称服务器，您就会遇到问题。即使您将您的区域更改为使用其他区域，NS记录 TTL 意味着您的更改不会立即被看到。但实际上这并没有对 TTL 有太多说明，而只是对 DNS 管理有很多说明：如果您想要有弹性，对于重要区域，不要使用单个 DNS 提供程序，而是使用多个（这当然需要在你不能随意混合和匹配提供商 X 和 Y，如果你通过 DNSSEC 进入混合，那就更复杂了，但这是可能的）。这样，正是由于上面快速起草的算法，即使 5 个中有 2 个让我们说名称服务器由于该特定提供商有问题而无法完全回复，另一个将承担负载并使您的域正常工作。

PS：没有要求，但有时不清楚，给定记录集中的所有记录都必须具有相同的 TTL。TTL 是每条记录的，但在给定的记录集中需要相同，这意味着对于（名称，记录类型）的给定元组 [和类，但除了IN作为类之外没有人使用任何东西]