几年前，当我将一些设备从一个数据中心移动到另一个数据中心时，我不得不在几周内进行多次 DNS 更改。当时，世界上大约 95% 的名称服务器似乎都遵守 TTL 值，而大约 5% 的名称服务器忽略了我们的值并自行制定了 TTL 值。换句话说，95% 的流量在我们定义的 15 分钟 TTL 内移动。另有 3% 的流量在第一小时内完成，1% 的流量在第一天完成，少数落后者则需要长达三天的时间。
（是的，好吧，我把流量百分比和名称服务器百分比混淆了。请挥手示意。）
不过，那是在 2001 年左右，当时我们使用的是过时的方法来通过管道传输数据包。我猜想，如今的名称服务器表现得更好，落后者的问题会更少。有谁知道现在有多少比例的流量会在定义的 TTL 内切换？是否仍有许多名称服务器忽略 TTL？
答案1
我们最近搬家了，遇到了各种各样的 DNS 问题。
当我们进行迁移时，大多数客户立即开始使用新 IP。但有些客户仍在使用旧 IP 数周。我们将服务器保留了一个月左右。最后，我们查看了旧机器上的 IIS 日志，并打电话给客户，告诉他们刷新公司或 ISP DNS 服务器上的 DNS。这样，他们中的最后一个就迁移过来了。
只有少数人继续使用旧 IP。在 2 万名客户中，大概有 50 名在第一天后就遇到了问题。
答案2
2011 年 5 月，大多数 DNS 解析名称服务器都遵守长达 2 周的 (非常) 长 TTL 值。
在使用 just-dnslookup.com 的测试中，拥有 50 个全球分布式活跃测点，A 记录 TTL 设置为 99.999.999 = 165 周（精确：165 周 2 天 9 小时 46 分 39 秒），默认 TTL 为 2 周（= SOA + NS TTL）。
首次查找返回：
- 50 个测量点中的 3 个的 TTL 为 1 周
- TTL 为 165 周，涵盖 50 个测量点中的 47 个
连续查找返回（转换为原始 TTL 值）：
- 50 个测量点中的 3 个的 TTL 为 1 周
- 50 个测量点中的 46 个的 TTL 为 2 周
- TTL 为 165 周，针对 50 个测量点中的 1 个
第二次测试（使用不同的域），其中默认 TTL 设置为 4 周（= SOA + NS TTL）结果如下。
首次查找返回：
- 50 个测量点中的 3 个的 TTL 为 1 周
- TTL 为 2 周，针对 50 个测量点中的 1 个
- TTL 为 165 周，涵盖 50 个测量点中的 46 个
连续查找返回（转换为完整的 TTL 长度）：
- 50 个测量点中的 3 个的 TTL 为 1 周
- 50 个测量点中的 47 个的 TTL 为 2 周
- 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 周的义务。
答案3
我最近将托管我个人网站和项目网站的几个域名的 DNS 从 GoDaddy 移到了内部 DNS（是的，实际上是我的房子）。总体而言，我远程访问的每个站点都遵守了 TTL 并顺利完成了转换。我要求检查的每个朋友都报告了同样的情况，无论是通过固定电话还是手机。具有讽刺意味的是，唯一的问题是我工作的 $University 的主要缓存 DNS 服务器，它似乎完全无视缓存查询的 TTL（甚至无视它们分配给缓存结果的 TTL 值）。
看来，总体而言，TTL 应该受到尊重。56% 的服务器对 .com 和 .net 域名具有权威性正在运行 BIND，它显然与标准配合得很好。Cablevision/Optimum（至少在新泽西州）似乎正在使用 Nominum CNS，它也遵守 TTL。
答案4
这并不是针对您的问题的具体回答；而是在测试中需要考虑的其他事项：
链式 DNS 递归程序和缓存守护进程
缓存记录的不仅仅是边缘 DNS 递归器。有时人们会链接递归器，这会增加时间。是否应该这样做可能会是一个漫长的讨论，具体取决于人们试图解决的问题。我曾在数据中心看到过 3 个级别的递归。混合递归器可能会产生混合结果，因为 TTL 递减并不总是保留的。一些操作系统会缓存记录。一些系统还使用诸如nscd和dnsmasq其他方法来最大限度地减少本地递归器问题的影响并减少其递归器的负载。操作系统的特性因发布版本、缓存守护程序、缓存守护程序版本等而异……
[ 编辑 ]重申一下，这不是递归程序或缓存守护进程的正常行为。我不会责怪那些有缺陷的程序，但其中一个程序被认为是无人维护的，尽管它与许多 Linux 发行版捆绑在一起。
应用程序 DNS 缓存
一些浏览器也会缓存记录。Java 和其他应用程序也会缓存 DNS。有时您可以限制应用程序内的最大 ttl。
最终结果可能会出现偏差
上述项目很容易将 15 分钟的 TTL 变成 60 分钟甚至更长时间。
这就是为什么我经常建议应用程序或网站应该考虑在其容错设计中拥有多个活动节点，以便客户端可以更快地确定网站的一个入口点何时发生故障，并在可行的情况下以优雅且可预测的方式自动处理问题。 任播是一些公司用来使故障转移透明化并且不过度依赖 DNS 更改的一种方法。还有一些巧妙的负载平衡方法，可以在 javascript 中使用多个 DNS 记录来实现。