DNS 解析器与 NS 记录 TTL

Question

当 DNS 解析器查找权威名称服务器的域/区域时，它是否会接收所有 6 条记录并循环浏览它们？

是的，适当的递归名称服务器会考虑所有名称服务器，并且每次都会尝试查询最快的名称服务器。

粗略的算法是这样的：

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

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

到此为止。记录是以集合的形式出现的，而不是以列表的形式出现的。也就是说，DNS 中没有固有的顺序。当然，线路或显示表示中存在顺序，但它不是来自协议。

记录集是包：您可以获得无序的记录。事实上，您可以看到，对于完全相同的查询，如果答复中有多个记录，许多名称服务器会在您每次查询时对记录进行不同的排序，这正是为了对抗只考虑第一个项目而忽略其他项目的客户端系统。

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

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

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

也许吧，但大多数情况下都无关紧要。为什么？因为您的NS记录发布在您域的父区域中，以确保 DNS 委派。它们当然是在那里发布的，带有 TTL，因为所有记录都附加有 TTL，但它们发布在您无法控制的区域中，因此您无法选择它们的 TTL 值！

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

TTL 总是需要权衡的。一旦知道，有些人会立即得出结论，使用非常低的 TTL 效果会更好……在某些情况下确实如此，但在其他情况下则不然。缓存是好的，如果没有缓存（即没有使用足够大的 TTL），您将无法抵御任何小问题，这会使一切都消失，因为缓存中的名称已经过期。

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

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

关于解析器 DNS 如何与无响应 NS 及其 TTL 一起工作，有什么建议吗？

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

您可以在这里找到更多详细信息：

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

除了服务器的名称和地址之外，SLIST 数据结构还可以进行排序，以便首先使用最佳服务器，并确保以循环方式使用所有服务器的所有地址。排序可以是一个简单的功能，即优先使用本地网络上的地址，也可以涉及过去事件的统计数据，例如以前的响应时间和击球率。

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

RFC 1035 §7.2 有以下说明：

为了完成 SLIST 的初始化，解析器会将其拥有的所有历史信息附加到 SLIST 中的每个地址。这通常包括地址响应时间和地址命中率（即地址对请求的响应频率）的某种加权平均值。请注意，此信息应按地址保存，而不是按名称服务器保存，因为特定服务器的响应时间和命中率可能因地址而异。还请注意，此信息实际上特定于解析器地址/服务器地址对，因此具有多个地址的解析器可能希望为每个地址保留单独的历史记录。此步骤的一部分必须处理没有此类历史记录的地址；在这种情况下，预计往返时间为 5-10 秒应该是最坏情况，对于同一本地网络，估计时间会更低，等等。

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

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

最后再更具体地说一下：

正如 imperva 的这篇文章中所述

您引用的这篇文章讨论了使用 Dyn 名称服务器的人在发生中断时遇到的问题。那么，是的，如果您只使用 Dyn 名称服务器，您就会遇到问题。因为即使您将区域更改为使用其他区域，NS记录 TTL 也意味着您的更改不会立即生效。但实际上，这并没有说明很多有关 TTL 的内容，而只是说明了有关 DNS 管理的内容：如果您想要具有弹性，对于重要区域，请不要使用单个 DNS 提供商，而是使用多个（这当然要求它们之间进行一些协调，您不能只是任意混合和匹配提供商 X 和 Y，如果您通过 DNSSEC 进行混合，则会更加复杂，但这是可能的）。这样，正是由于上面快速起草的算法，即使 5 个名称服务器中有 2 个由于这个特定提供商出现问题而无法完全回复，另一个也会承担负载并使您的域正常工作。访问者的每个新查询可能会有额外的延迟（因为所有递归名称服务器无法立即理解它们必须切换到特定的名称服务器，因为 5 个名称服务器中有 2 个已关闭），并且还会有更多的延迟，因为其他 3 个名称服务器被比平时更多的查询所淹没（DNS 默认是负载平衡的，因此理论上每个名称服务器都会获得大致相同数量的查询），但仍然会给出答复。

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

Answer 1