DNS 传播时间计算器

DNS 是带缓存的分布式数据库：你修改权威服务器的记录后，全球各级递归解析器里还存着旧答案，直到各自的缓存到期（TTL 倒计时归零）才会重新查询。所以「传播时间」不是主动推送的耗时，而是「最后一个缓存过期」的等待：TTL 3600 意味着修改后最坏 1 小时全球收敛，最佳情况（无缓存的解析器）秒级生效。实际观察到的收敛曲线是渐进的：5 分钟时可能 60% 的解析器已更新，30 分钟 90%，1 小时 99%+。

运维的标准动作是「降 TTL 前置」：计划切换前 24-48 小时把 TTL 从 86400 降到 300（5 分钟），等旧 TTL 的缓存全部过期后再做切换——切换的传播窗口就从一天压缩到 5 分钟，回滚也同样快。切换完成稳定后再把 TTL 调回大值（降低权威服务器压力、加快解析）。坑位提醒：① 部分运营商递归服务器无视 TTL 强制缓存（尤其实小 TTL 被提升到 15 分钟甚至更久）② 应用层还有自己的 DNS 缓存（JVM 默认 30 秒-∞、浏览器约 1 分钟）③ TTL 是「每条记录」的属性，改 NS 记录涉及父域（注册局）TTL，通常 48 小时无法加速。

TTL 是传播时间的「硬上限」而非保证：全球递归服务器实际在几秒到几十分钟内就可能先后拿到新记录（取决于各自缓存时间和查询触发），90% 的客户端会在 1 个 TTL 内看到新值，但最坏情况（某个递归器刚缓存了旧记录）要等整整一个 TTL 才过期。所以计算传播窗口时，按「最大 TTL × 层级」预估更稳妥——权威→根/TLD 的 48 小时粘连、托管商覆盖新 NS 记录的延迟，都可能让实际传播长于直觉。

需要立即验证时，用「绕过缓存」的手段而不等自然过期：nslookup 指定公共递归（如 8.8.8.8 / 208.67.222.222）直接查，或用 dig +trace 从根一步步看权威的当前值，配合在线 DNS 传播监测站点（多节点轮询）确认各地区是否已更新。切换完成记得把 TTL 从临时的 300 恢复回 86400，避免长期维持低 TTL 让每个查询都打到权威服务器（官方解析量会被放大几十倍、增加成本与 DDoS 暴露面）。