如今，有多少百分比的名称服务器支持TTL？

几年前，当我将一些设备从一个数据中心移到另一个数据中心时，我不得不在几周的时间内进行几次DNS更改。在我这样做的时候，世界上大约95％的域名服务器似乎都尊重TTL值，而大约5％的域名服务器却忽略了我们的TTL值，而是自己决定了。换句话说，有95％的流量在我们定义的15分钟TTL之内移动。另外3％的用户在第一个小时就做到了，第一天就达到了1％，一些流浪者最多花了三天。

（是的，好的，我将流量百分比与名称服务器百分比混淆了。请插入信号交换。）

不过，那是在2001年左右，我们正在使用恐龙通过管道传输数据包。我的猜测是，当今的域名服务器表现得更好，而流浪者的问题将更少。有人能感觉到这些天将在定义的TTL内切换多少流量吗？那里还有许多忽略TTL的名称服务器吗？

我们最近搬家了，DNS出现了各种各样的问题。

当我们进行交易时，大多数客户立即开始使用新IP。但是有些仍在使用旧IP达数周之久。我们将服务器搁置了一个月左右。最终，我们浏览了旧计算机上的IIS日志，并致电客户，告诉他们在该公司或ISP DNS服务器上刷新DNS。那让他们中的最后一个移了过来。

保留旧IP的人很少。在第一天之后，在2万名客户中，可能有50名遇到了问题。

（非常）很长的TTL星期值在2011年5月被大多数DNS解析名称服务器使用了长达2周的时间。

在使用just-dnslookup.com进行的测试中，有50个全局分布式活动测量点，A记录TTL设置为99.999.999 = 165周（精确度：165周2天9小时46分钟39秒），并且使用默认TTL 2周（= SOA + NS TTL）。

第一次查找返回：

• TTL为1周，适用于50个测量点中的3个
• TTL 165周，适用于50个测量点中的47个

连续查找返回（转换为原始TTL值）：

• TTL为1周，适用于50个测量点中的3个
• TTL为2周，适用于50个测量点中的46个
• TTL 165周，适用于50个测量点中的1个

下面是第二个测试（使用其他域），其中默认TTL设置为4周（= SOA + NS TTL）。

第一次查找返回：

• TTL为1周，适用于50个测量点中的3个
• TTL为2周，适用于50个测量点中的1个
• TTL 165周，适用于50个测量点中的46个

连续查找返回（转换为完整的TTL长度）：

• TTL为1周，适用于50个测量点中的3个
• TTL为2周，适用于50个测量点中的47个
• TTL 165周，适用于50个测量点中的0个

从最知名/最佳连接的公共解析器服务中：

• Google公共DNS [8.8.8.8和8.8.4.4]减少为1天。
• UltraDNS [rdns（1 | 2）.ultradns.net]可以使用165周。
• Sprintlink [ns（1 | 2 | 3）.sprintlink.net]完整服役165周。

最近，我将用于托管我的个人站点和项目站点的几个域的DNS从GoDaddy移到了内部DNS（是的，实际上是我的房子）。总体而言，我可以远程访问的每个站点都尊重TTL，并且可以很好地进行过渡。我可以要求通过座机和手机进行检查的每个朋友都报告了同样的情况。具有讽刺意味的是，唯一的问题是我工作的$ University的主要缓存DNS服务器，它似乎完全不考虑TTL用于缓存的查询（甚至不考虑它们分配给缓存结果的TTL值）。

总体看来，TTL应该受到尊重。.com和.net域中权威的服务器中有56％在运行BIND，这显然符合标准。Cablevision / Optimum（至少在新泽西州）似乎正在使用Nominum CNS，它也遵守TTL。

这并不是您对问题的专门回答；而是要考虑的其他事项会影响您的测试：

链接的DNS递归和缓存守护进程

缓存记录的不仅仅是边缘DNS递归。有时人们链接递归，这会增加时间。基于人们试图解决的问题，是否应该进行长时间的讨论。我已经在数据中心看到3个级别的递归。混合递归可能会产生混合结果，因为TTL递减并不总是被保留。一些操作系统缓存记录。有些系统还使用之类的东西nscd，dnsmasq和其他方法，以尽量减少当地recursor问题的影响，并减少对recursors负荷。操作系统的特性因发行版本，缓存守护程序，缓存守护程序的版本等而异。

[编辑]重申，这不是一个recursor或缓存后台进程的正常行为。我不会羞辱越野车，但即使其中的许多Linux发行版都捆绑了其中的一个，也可以认为其中之一是不需要维护的。

应用程序DNS缓存

一些浏览器还缓存记录。Java和其他应用程序也缓存DNS。您有时可以在应用程序中限制最大ttl。

最终结果可能偏斜

以上项目可以轻松将15分钟的TTL转换为60分钟甚至更长的时间。

这就是为什么我经常建议应用程序或网站在其容错设计中考虑考虑多个活动节点，以便客户端可以更快地确定您网站的一个入口点发生故障时，并以优美且可预测的方式自动处理该问题。 ，如果可行。 Anycast是一些公司用来使故障转移稍微透明并且不那么依赖DNS更改的一种方法。还有一些聪明的负载平衡方法，可以使用多个DNS记录在javascript中完成。

老问题，但新答案（2017年，六年后）：

1. 似乎几乎所有全球的DNS服务器都在5分钟内更新
2. Google和OpenDNS允许您手动刷新DNS记录，从而加速传播更新

在下面的实验之前，我之前已将TTL从14400（秒= 4小时）更改为300（秒= 5分钟），但是我在实验前2小时做了此操作，由于之前的TTL是4小时，所以我不确定我的更改如果DNS服务器没有自己的最小TTL，那就早该解决了。

我的实验：

实验1：

我在权威服务器中更改了名称到IP的转换（A记录），然后进行了检查：

• https://www.whatsmydns.net
• https://dnschecker.org

5分钟（300秒）后，这些站点检查的全球服务器中大约有一半已被删除。

7分钟后，除1以外的所有内容均已更新。

实验2：

Google和OpenDNS允许您手动刷新特定域的DNS缓存。链接：

• 刷新您所在域的Google的DNS缓存条目：https : //developers.google.com/speed/public-dns/cache
• 刷新您域的OpenDNS的DNS缓存条目：https : //cachecheck.opendns.com/

我更新了另一个A记录，然后立即刷新了Google的DNS缓存。他们有一个验证码，使我“单击带有标志的所有方块” 3次，因此我花了1-2分钟才能完成冲洗。

4分钟后，这些站点仅检查了1个DNS服务器的旧IP地址。所有其他均已更新。

因此，清除Google的DNS缓存，并迫使其重新查询权威服务器，似乎已经加速了全球DNS的传播，这可能是通过触发全球服务器的缓存更新来实现的。

但是，即使没有Google同花顺，它的传播似乎也在几分钟之内，而不是几小时或几天。