DNS A记录延迟的原因

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

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

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

如果我将/etc/resolv.conf nameserver条目从本地nameserver更改为8.8.8.8（google dns），它将解析。我切换回去，它没有解决。考虑到谷歌的回答，这似乎与路由53没有任何关系

这是什么原因造成的？我的本地解析器不应该查询相关的名称服务器，并最终查询名称服务器example.com，它应该为randomid.example.com获得答案吗

不应该有任何传播延迟

是的，应该有

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

对于新记录，在记录从权威名称服务器实际可用之前查找主机名会导致负面缓存：当解析程序查找不存在的记录时，

NXDOMAIN

响应由解析程序缓存一段时间，在默认TTL过期并从解析器的缓存中逐出响应之前，将为后续请求返回此响应

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

当您使用

dig

查询新记录时，您将看到TTL倒计时为0。一旦发生这种情况，你就会看到预期的答案。在Linux上，

watch

实用程序非常方便，如

watch-n1'dig example.com'

中所述

计时器应从托管区域的

SOA

记录中的最小TTL设置：

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

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

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

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

你可能是这样做的，因为53号公路不会立即让记录可见。对托管区域进行更改的时间与路由53开始返回记录的时间之间存在短暂的延迟

Route 53 API支持该操作，在托管区域的权威服务器返回更改的预期答案之前，该操作不应返回

INSYNC

（当然，这使用了“更改”，因为“插入”和“更新”都是“更改”）

您还可以通过直接查询专门分配给托管区域的一台服务器来确定这一点（如控制台中的其他位置所示）

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

---

---

在回答这个问题时，我要强调一个事实，即DNS中通常称为“传播延迟”的东西实际上并不是这类东西——它实际上是现有记录的基于TTL的缓存逐出延迟。

是什么让你认为新条目没有传播延迟？@Peterdk-这是一个全新的条目。您不会将新的IP地址传播到现有的IP地址，也不会将记录传播到缓存它的世界。因此，解析程序将执行完整的查找，首先到.com，然后到.example.com，以将IP获取回客户端。但是我不确定为什么我的本地dns名称服务器和ISP的名称服务器不能解决这个问题。嗯，也许它与anycast有关。路由53使用这个。所以这是一种不同类型的传播延迟。我认为重要的是不要谈论传播延迟，即使每个人都这么说。因为它给人一种错误的印象，事情是“自上而下”完成的，你只需要等待得到正确的结果。这是错误的。只有当您进行查询且缓存为空或条目TTL值已过期时，才能获得正确的（更新的）结果。将传播和TTL混为一谈会给人留下错误的印象。@PatrickMevzek这是一个公平的观点。在这里，我将考虑一些改进。

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