DNS A 记录延迟的原因

Question

我有一些主机在 EC2 中按需出现，当它们执行启动它们的服务时，它们会在现有区域下的 Route53 中创建 A 记录。

A 记录的格式为：randomid.example.com。因此，这不是对现有名称/IP 对的更新或更改，而是全新的条目。不应该有任何传播延迟。

我看到的是，在添加了条目并可以在任何 Amazon 服务器上使用 DNS 进行查找后，我自己的客户端 PC 似乎在 5-10 分钟内无法解析名称。你 ping 它，我希望看到它的 IP。但我只是得到“没有这样的主人”。

如果我将我的 /etc/resolv.conf 名称服务器条目从我的本地名称服务器更改为 8.8.8.8 (google dns)，它会解析。我切换回来，它没有解决。鉴于谷歌的答案，这似乎与 Route53 没有任何关系。

什么会导致这种情况？我的本地解析器不应该查询相关的名称服务器并最终查询 example.com 的名称服务器，它应该得到 randomid.example.com 的答案吗？

Answer 1

不应该有任何传播延迟。

是的，应该有。

所有 DNS 配置都有“传播延迟”。¹

在新记录的情况下，在记录从权威名称服务器实际可用之前查找主机名会导致负缓存：当解析器查找不存在的记录时，NXDOMAIN解析器将响应缓存一段时间时间，并且此响应为后续请求返回，直到默认 TTL 过去并且响应从解析器的缓存中逐出。

否定缓存很有用，因为它减少了否定答案的响应时间。它还减少了必须在解析器和名称服务器之间发送的消息数量，从而减少整体网络流量。

https://tools.ietf.org/html/rfc2308

当您dig用来查询新记录时，您会看到 TTL 倒计时到 0。一旦发生这种情况，您就会开始看到预期的答案。在 Linux 上，该watch实用程序对此很方便，如watch -n 1 'dig example.com'.

计时器应从最小 TTL 设置，该最小 TTL 可在您的托管区域的SOA记录中找到：

最短生存时间 (TTL)。此值有助于定义 NXDOMAIN 结果（指示域不存在）应由 DNS 解析器缓存的时间长度。缓存此否定结果称为否定缓存。负缓存的持续时间是 SOA 记录的 TTL 或最小 TTL 字段的值中的较小者。Amazon Route 53 SOA 记录的默认最小 TTL 为 900 秒。

http://docs.aws.amazon.com/Route53/latest/DeveloperGuide/SOA-NSrecords.html

这就是你 5-10 分钟的来源。这实际上是 15 分钟（900 秒）的最坏情况。

减少此计时器将减少行为良好的解析器缓存记录不（尚未）存在的事实的时间量。

“太好了，”你反对，“但我没有在它存在之前查询主机名。现在怎么办？”

您可能这样做了，因为 Route 53 不会立即使记录可见。对托管区域进行更改的时间与 Route 53 开始返回记录的时间之间存在短暂的延迟。

Route 53 API 支持该GetChange操作，该操作INSYNC在托管区域的权威服务器返回更改的预期答案之前不应返回（当然这使用“更改”，因为“插入”和“更新”都是变化”）。

您还可以通过直接查询专门分配给您的托管区域的服务器之一来确定这一点（如在控制台中看到的，以及其他地方）。

$ dig @ns-xxxx.awsdns-yy.com example.com

因为您是直接查询权威服务器，所以只要服务器可用，您就会看到更改的结果，因为路径中没有将缓存响应的解析器。

¹出于这个答案的目的，我掩盖了这样一个事实，即 DNS 中通常被称为“传播延迟”的事实实际上是一种无关紧要的东西——它实际上是现有记录的基于 TTL 的缓存逐出延迟。