我有一些主机在EC2中出现需求，当他们启动它们的服务时，在现有区域下的Route53中创建A记录。
A记录的格式为：randomid.example.com。 因此，它不是现有名称/ IP对的更新或更改，而是全新的条目。不应该有任何传播延迟。
我所看到的是，在任何亚马逊服务器上添加条目并使用DNS查找后，我自己的客户端PC无法解析5-10分钟的名称。你ping它，我希望看到它的IP。但我只是“没有这样的主人”。
如果我将我的/etc/resolv.conf名称服务器条目从我的本地名称服务器更改为8.8.8.8（谷歌dns），它会解析。我换回来，它没有解决。鉴于google的答案，这似乎与Route53没有任何关系。
这会导致什么？我的本地解析器不应该查询相关的名称服务器，最终查询example.com的名称服务器，它应该获得randomid.example.com的答案吗？
答案 0 :(得分：1)
不应有任何传播延迟。
是的，应该有。
所有DNS配置都有“传播延迟”.¹
对于新记录，在权威名称服务器实际可用记录之前查找主机名会导致否定缓存：当解析程序查找不存在的记录时，解析器缓存NXDOMAIN响应一段时间，并且为后续请求返回此响应，直到默认TTL结束并且响应从解析程序的缓存中逐出。
负缓存非常有用，因为它可以减少否定答案的响应时间。它还减少了必须在解析器和名称服务器之间发送的消息数量，从而减少了整体网络流量。
当您使用dig查询新记录时，您会看到TTL倒计时为0.一旦发生这种情况，您就会开始看到预期的答案。在Linux上，watch实用程序非常方便，如watch -n 1 'dig example.com'。
计时器应该从最小TTL设置，该TTL位于托管区域的SOA记录中：
最短生存时间（TTL）。此值有助于定义DNS解析器应缓存NXDOMAIN结果（表示域不存在）的时间长度。缓存此否定结果称为负缓存。负缓存的持续时间是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的缓存驱逐延迟记录。