DNS A记录延迟的原因
Cause of DNS A record delays
我有一些主机在 EC2 中按需出现，当它们执行启动它们的服务时，会在现有区域下的 Route53 中创建 A 记录。
A 记录的格式为：randomid.example.com。
所以它不是现有 name/IP 对的更新或更改，它是全新的条目。不应该有任何传播延迟。
我看到的是，在添加条目并可在任何 Amazon 服务器上使用 DNS 进行查找后，我自己的客户端 PC 似乎在 5-10 分钟内无法解析该名称。你 ping 它，我希望看到它的 IP。但我只是得到 "no such host".
如果我将我的 /etc/resolv.conf 名称服务器条目从我的本地名称服务器更改为 8.8.8.8 (google dns)，它会解析。我切换回来，它没有解决。鉴于 google 答案，这似乎与 Route53 没有任何关系。
什么会导致这种情况？我的本地解析器不应该查询相关的名称服务器，并最终查询 example.com 的名称服务器，它应该得到 randomid.example.com 的答案吗？
There shouldn't be any propagation delay.
是的，应该有。
所有 DNS 配置都有“传播延迟”。¹
对于新记录，在记录实际可从权威名称服务器获得之前查找主机名会导致 负缓存： 当解析器查找非-existent 记录，NXDOMAIN 响应由解析器缓存一段时间，并且此响应为后续请求 returned，直到默认 TTL 过去并且响应从解析器的缓存中逐出。
Negative caching is useful as it reduces the response time for negative answers. It also reduces the number of messages that have to be sent between resolvers and name servers hence overall network traffic.
https://www.rfc-editor.org/rfc/rfc2308
当您使用 dig 查询新记录时，您会看到 TTL 倒计时到 0。一旦发生这种情况，您就会开始看到预期的答案。在 Linux 上，watch 实用程序对此很方便，如 watch -n 1 'dig example.com'.
计时器应从最小 TTL 开始设置，可在您的托管区域的 SOA 记录中找到：
The minimum time to live (TTL). This value helps define the length of time that an NXDOMAIN result, which indicates that a domain does not exist, should be cached by a DNS resolver. Caching this negative result is referred to as negative caching. The duration of negative caching is the lesser of the SOA record's TTL or the value of the minimum TTL field. The default minimum TTL on Amazon Route 53 SOA records is 900 seconds.
http://docs.aws.amazon.com/Route53/latest/DeveloperGuide/SOA-NSrecords.html
这是你 5-10 分钟的来源。这实际上是 15 分钟（900 秒）的最坏情况。
减少此计时器将减少行为良好的解析器缓存记录不（尚未）存在这一事实的时间。
“太好了，”你反对道，“但我没有在它存在之前查询主机名。现在怎么办？”
您可能做到了，因为 Route 53 不会立即使记录可见。对托管区域进行更改的时间与 Route 53 开始 return 记录的时间之间存在短暂的滞后。
Route 53 API 支持 GetChange 操作，在您的托管区域的权威服务器 returning 之前不应 return INSYNC更改的预期答案（当然，在“插入”和“更新”都是“更改”的意义上，这使用“更改”）。
您还可以通过直接查询专门分配给您的托管区域的服务器之一来确定这一点（如在控制台等其他地方看到的那样）。
$ dig @ns-xxxx.awsdns-yy.com example.com
因为您正在直接查询权威服务器，所以一旦服务器可用，您就会看到更改的结果，因为路径中没有缓存响应的解析器。
¹为了这个答案的目的，我掩盖了一个事实，即在 DNS 中通常被称为“传播延迟”的东西实际上是一种无关紧要的东西——它实际上是一种基于 TTL 的缓存逐出延迟现有记录。
我有一些主机在 EC2 中按需出现，当它们执行启动它们的服务时，会在现有区域下的 Route53 中创建 A 记录。
A 记录的格式为：randomid.example.com。 所以它不是现有 name/IP 对的更新或更改，它是全新的条目。不应该有任何传播延迟。
我看到的是，在添加条目并可在任何 Amazon 服务器上使用 DNS 进行查找后，我自己的客户端 PC 似乎在 5-10 分钟内无法解析该名称。你 ping 它，我希望看到它的 IP。但我只是得到 "no such host".
如果我将我的 /etc/resolv.conf 名称服务器条目从我的本地名称服务器更改为 8.8.8.8 (google dns)，它会解析。我切换回来，它没有解决。鉴于 google 答案，这似乎与 Route53 没有任何关系。
什么会导致这种情况？我的本地解析器不应该查询相关的名称服务器，并最终查询 example.com 的名称服务器，它应该得到 randomid.example.com 的答案吗？
There shouldn't be any propagation delay.
是的，应该有。
所有 DNS 配置都有“传播延迟”。¹
对于新记录，在记录实际可从权威名称服务器获得之前查找主机名会导致 负缓存： 当解析器查找非-existent 记录，NXDOMAIN 响应由解析器缓存一段时间，并且此响应为后续请求 returned，直到默认 TTL 过去并且响应从解析器的缓存中逐出。
Negative caching is useful as it reduces the response time for negative answers. It also reduces the number of messages that have to be sent between resolvers and name servers hence overall network traffic.
https://www.rfc-editor.org/rfc/rfc2308
当您使用 dig 查询新记录时，您会看到 TTL 倒计时到 0。一旦发生这种情况，您就会开始看到预期的答案。在 Linux 上，watch 实用程序对此很方便，如 watch -n 1 'dig example.com'.
计时器应从最小 TTL 开始设置，可在您的托管区域的 SOA 记录中找到：
The minimum time to live (TTL). This value helps define the length of time that an NXDOMAIN result, which indicates that a domain does not exist, should be cached by a DNS resolver. Caching this negative result is referred to as negative caching. The duration of negative caching is the lesser of the SOA record's TTL or the value of the minimum TTL field. The default minimum TTL on Amazon Route 53 SOA records is 900 seconds.
http://docs.aws.amazon.com/Route53/latest/DeveloperGuide/SOA-NSrecords.html
这是你 5-10 分钟的来源。这实际上是 15 分钟（900 秒）的最坏情况。
减少此计时器将减少行为良好的解析器缓存记录不（尚未）存在这一事实的时间。
“太好了，”你反对道，“但我没有在它存在之前查询主机名。现在怎么办？”
您可能做到了，因为 Route 53 不会立即使记录可见。对托管区域进行更改的时间与 Route 53 开始 return 记录的时间之间存在短暂的滞后。
Route 53 API 支持 GetChange 操作，在您的托管区域的权威服务器 returning 之前不应 return INSYNC更改的预期答案（当然，在“插入”和“更新”都是“更改”的意义上，这使用“更改”）。
您还可以通过直接查询专门分配给您的托管区域的服务器之一来确定这一点（如在控制台等其他地方看到的那样）。
$ dig @ns-xxxx.awsdns-yy.com example.com
因为您正在直接查询权威服务器，所以一旦服务器可用，您就会看到更改的结果，因为路径中没有缓存响应的解析器。
¹为了这个答案的目的，我掩盖了一个事实，即在 DNS 中通常被称为“传播延迟”的东西实际上是一种无关紧要的东西——它实际上是一种基于 TTL 的缓存逐出延迟现有记录。