几年前，当我将一些设备从一个数据中心移到另一个数据中心时，我必须在几个星期内做几次DNS更改。 当时我这样做的时候，世界上大约95％的名字服务器似乎都尊重TTL的价值，大约有5％的人忽略了我们的自己。 换句话说，95％的stream量在我们定义的15分钟TTL内移动。 另有3％是在第一个小时，第一天是1％，一些零散的人花了三天时间。
（是的，好的，我把stream量百分比和名称服务器的百分比混淆了，请插入手机。）
但是，这大约在2001年，而我们正在用恐龙来传送数据包。 我的猜测是，今天的域名服务器performance得更好，散兵者的问题也会减less。 有没有人有一个感觉，在这些天定义的TTLstream量的百分比会切换？ 还有很多忽略TTL的名字服务器吗？
我们最近搬到了DNS，遇到各种各样的问题。
当我们做了大部分客户的摇摆开始立即打到新的IP。 但是，有些人还是打了几个星期的旧IP。 我们离开了一个月左右的服务器。 最后，我们浏览了旧机器上的IIS日志，并呼叫客户告诉他们在公司或ISP DNS服务器上刷新DNS。 最后他们被移交了。
与旧的IP保持一致的是less数人。 在20万客户中，第一天之后可能有50个问题。
（非常）长的TTL值是在2011年5月，由大多数DNSparsing名称服务器在2周内颁发。
在使用just-dnslookup.com进行的testing中，有50个全球分布式主动测量点，AloggingTTL设置为99.999.999 = 165周（精确：165周2天9小时46分39秒），默认TTL 2周（= SOA + NS TTL）。
首先查找返回：
连续查找返回（转换为原始TTL值）：
第二个testing（使用不同的域），默认的TTL设置为4周（= SOA + NS TTL）结果如下。
首先查找返回：
连续查找返回（转换为完整的TTL长度）：
从最知名/最好的公共解决scheme服务：
我最近把DNS移动到了几个域名，这些域名从GoDaddy托pipe我的个人网站和项目网站到内部的DNS（是的，我的房子 ）。 总的来说，我有远程访问的每个站点都尊重TTL，并且过渡的很好。 我可以通过固定电话和手机查询每个朋友的报告。 具有讽刺意味的是，唯一的问题是我工作的$ University的主要cachingDNS服务器，这似乎完全忽略了TTL的caching查询（甚至忽略了分配给caching结果的TTL值）。
总的来说，似乎TTL应该受到尊重。 56％的.com和.net域名的权威服务器正在运行BIND，这显然与标准相一致。 Cablevision / Optimum（至less在新泽西州）似乎在使用Nominum CNS，它也尊重TTL。
这不是专门针对你的问题的答案。 而是需要考虑更多的东西来进行testing：
链接的DNS Recursors和caching守护进程
这不仅仅是cachinglogging的边缘DNSrecursion。 有时候人们会把循环链接起来，这会增加时间。 根据人们试图解决的问题，是否应该做这件事可能是一个漫长的讨论。 我在数据中心看到了3个recursion级别。 混合recursion可能有混合的结果，因为TTL递减并不总是被保留下来。 一些操作系统cachinglogging。 一些系统也使用nscd ， dnsmasq和其他方法来减less本地recursor问题的影响，并减lessrecursors的负载。 操作系统的特性因发布版本，caching守护进程，caching守护进程的版本等而异。
[编辑]重申，这不是recursor或caching守护进程的正常行为。 我不会羞于越野车，但其中一个被认为是无人维护，即使它与许多Linux发行版捆绑在一起。
应用程序DNScaching
一些浏览器也cachinglogging。 Java和其他应用程序也cachingDNS。 你有时可以限制应用程序中的最大ttl。
最终的结果可能会偏离
上述项目可以很容易地把一个15分钟TTL变成60+分钟甚至更长时间。
这就是为什么我经常build议应用程序或网站应考虑在其容错devise中使用多个活动节点，以便客户端在进入您的站点的一个入口点出现故障时能够更快速地确定，并自动以优雅和可预测的方式处理问题，如果可行的话。 Anycast是一些公司用来使故障转移稍微透明的方法，而不是如此严重依赖于DNS更改。 还有一些聪明的负载均衡方法，可以使用多个DNSlogging在JavaScript中完成。
老问题，但新的答案（2017年，6年后）：
在进行下面的实验之前，我之前将TTL从14400（秒= 4小时）改为300（秒= 5分钟），但是在实验前2小时，TTL为4小时，因此我不确定我的改变如果DNS服务器没有自己的最小TTL的话，会得到。
我的实验：
实验1：
我在授权服务器上更改了名称到IP的翻译（Alogging），然后检查：
5分钟（300秒）后，这些站点检查的全球服务器中有一半已经被使用。
7分钟后，除1之外全部更新。
实验2：
Google和OpenDNS允许您手动清除特定域的DNScaching。 链接：
我更新了另一个Alogging，然后立即刷新了Google的DNScaching。 他们有一个validation码，使我“点击所有广场上的招牌”3次，所以花了1-2分钟才能完成冲水。
4分钟后，这些站点只检查一个DNS服务器的旧IP地址。 所有其他人已经更新。
因此，清除Google的DNScaching并迫使其重新查询授权服务器似乎已经加速了全球DNS传播，可能是通过触发全球服务器的caching更新。
但即使没有谷歌冲洗，它似乎传播在几分钟内，而不是几小时或几天。