理解 DNS TTL：为什么变更需要时间才能生效

每条 DNS 记录都带有一个 TTL（time to live，生存时间），以秒为单位。这是域名的权威域名服务器向每个获取该记录的解析器发出的指令：“在再次询问之前，您可以在这么长的时间内复用这个应答。”300 秒的 TTL 意味着，刚刚查询过某个域名的解析器，在接下来的五分钟内不会再去询问，即使这期间记录已经变化。

TTL 所权衡的取舍

较长的 TTL 意味着更少的 DNS 查询、更快的平均查询速度（因为更多请求由缓存直接响应），以及权威域名服务器上更低的负载。较短的 TTL 则意味着记录的变更传播得更快，代价是查询更加频繁。并不存在放之四海而皆准的值，这取决于记录预计多久变更一次，以及当前情形对过期应答的容忍程度。

变更期间究竟发生了什么

更新一条 DNS 记录，并不会把变更推送给互联网上的每个解析器，它只是改变了权威域名服务器下一次被询问时给出的答案。每个已经缓存了旧应答的解析器，都会继续提供旧应答，直到其缓存副本的 TTL 过期。这就是为什么同一个域名，可能会因为作答的解析器和缓存不同，而在短时间内解析到不同的地址。

• 计划迁移之前，一个常见的实用做法是提前一两天调低 TTL，让最终的切换传播得更快。
• 迁移完成后，通常会把 TTL 调回正常值。
• 一条长期没有变更、TTL 又很长的记录，一旦发生变更，仍可能需要整个 TTL 窗口的时间，才能从全球各地的缓存中完全清除。

实际如何选择 TTL

否定应答同样会被缓存，这一点很容易被忽视。当域名不存在时，NXDOMAIN 响应本身会被缓存，其时长由另一个值决定（SOA 记录的最小 TTL，而不是某条本来就不存在的记录的 TTL）。新注册的域名，有时会在随后的一小段时间内看起来无法解析，原因仅仅是解析器在注册完成之前，就已经缓存了它的 NXDOMAIN。

TTL 是一种请求，而不是保证

需要知道的是，TTL 只是建议性的，并没有任何外部权威来强制执行。从技术上讲，解析器可以自由地把应答缓存得比声明的 TTL 更久（有些解析器在高负载下会这样做，以减少查询量），也可以更早地将其驱逐（内存不足的解析器可能提前丢弃缓存条目）。在绝大多数情况下，运营良好的公共解析器和 ISP 解析器都会严格而可预测地遵守 TTL，但这也正是为什么基于 TTL 的传播时间估算只是一条可靠的经验法则，而不是严格的、有合同约束力的保证。如果某项变更在旧 TTL 窗口过去之后仍然没有明显生效，那么某个异常激进的中间缓存，就是虽然少见但确实存在、值得牢记的解释之一。

如果您要验证 DNS 变更是否已经生效，单次查询只能告诉您某一个解析器当前缓存了什么。相隔几分钟重新运行查询，或者安排一次周期性检查，是确认变更已真正传播的更可靠方式，而不是只碰到一次过期的缓存应答，就以为那是最终结果。