DNS A 记录延迟的原因

Question

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

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

我看到的是，在添加条目并可在任何亚马逊服务器上使用 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://www.rfc-editor.org/rfc/rfc2308

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

应从托管区域的SOA 记录中找到的最小 TTL 开始设置计时器：

最短生存时间 (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 的缓存驱逐延迟记录。