我有一些主机在EC2中按需出现，当它们执行启动它们的服务时，在Route53中在现有区域下创建了一个A记录。
A记录的形式为:randomid.example.com。因此，这不是对现有名称/IP对的更新或更改，而是全新的条目。不应该有任何传播延迟。
我看到的是，在条目被添加并可在任何Amazon服务器上使用DNS进行查找后，我自己的客户端PC无法解析该名称，似乎有5-10分钟。你ping它，我希望看到它的IP。但我只是得到"no such host"。
如果我将我的/etc/resolv.conf nameserver条目从我的本地名称服务器更改为8.8.8.8 (google dns)，它会解析。我换回去，还是没解决。鉴于谷歌的答案，这似乎与Route53没有任何关系。
是什么原因导致的?我的本地解析器不应该查询相关的域名服务器并最终查询example.com的域名服务器得到randomid。example.com的答案吗?
不应该有任何传播延迟。
是的，应该有。
所有DNS配置都有一个"传播延迟"。¹
在新记录的情况下，在记录从权威名称服务器实际可用之前查找主机名会导致负缓存:当解析器查找不存在的记录时，解析器将NXDOMAIN响应缓存一段时间，并返回此响应用于后续请求，直到默认TTL过期并将响应从解析器的缓存中驱逐。
负缓存很有用，因为它减少了对负答案的响应时间。它还减少了必须在解析器和名称服务器之间发送的消息数量，从而减少了整个网络流量。
https://www.rfc-editor.org/rfc/rfc2308
当您使用dig查询新记录时，您将看到TTL倒数到0。一旦这种情况发生，你就会开始看到预期的答案。在Linux上，watch实用程序非常方便，如watch -n 1 'dig example.com'。
定时器应该从最小TTL设置，它可以在您的托管区域的SOA记录中找到:
TTL最小生存时间。该值用于定义指定域名不存在的NXDOMAIN结果被DNS解析器缓存的时间长度。缓存这个负面结果称为负面缓存。负缓存的持续时间是SOA记录的TTL或最小TTL字段的值中较短的一个。Amazon Route 53 SOA记录的默认最小生存时间是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，直到您的托管区域的权威服务器返回预期的更改答案(当然这使用了"change")在这个意义上，两者都"插入"。和";update"
您还可以通过直接查询专门分配给您的托管区域的服务器之一来确定这一点(如在控制台中所示，以及其他位置)。
$ dig @ns-xxxx.awsdns-yy.com example.com
因为您是直接查询权威服务器，所以一旦服务器可用，您就会看到更改的结果，因为路径中没有缓存响应的解析器。
¹为了回答这个问题，我忽略了一个事实，即通常所说的"传播延迟"。