什么是 DNS TTL：解析缓存时间如何影响变更生效

DNS TTL（Time To Live，生存时间）是 DNS（域名系统）记录中指定解析结果可以被缓存的时间长度，单位为秒。TTL 决定了域名变更在全球生效的速度：TTL 越长，解析结果缓存越久、查询负载越低，但变更传播越慢；TTL 越短，变更生效越快，但查询压力越大。理解 TTL 是管理域名迁移、故障切换和解析调度的基础。

定义

每条 DNS 记录都携带一个 TTL 值。递归解析器在收到权威服务器的应答后，会按 TTL 把结果缓存起来；在缓存过期前，再次查询同一记录时直接返回缓存结果，不再向上游发起请求。TTL 到期后缓存失效，下一次查询会重新向权威服务器获取最新记录。它与DNS 负缓存是同一机制的正反两面：负缓存缓存的是”记录不存在”的判定，普通 TTL 缓存的是记录本身的值。TTL 只影响各级缓存保留旧结果多久，不改变权威服务器上的记录内容。

工作原理

TTL 的作用贯穿解析链路的每一层缓存：

• 递归解析器：按记录 TTL 缓存应答，公共 DNS 服务通常还会设置自己的 TTL 上限（例如不超过 1 天），即使权威记录写了更大的值。
• 操作系统：本机解析缓存（如 systemd-resolved、nscd）同样遵循 TTL，过期后重新查询。
• 浏览器：现代浏览器有自己的 DNS 缓存，一般取 TTL 与内部上限中较小的值。
• 应用层：某些长连接库会缓存解析结果到进程生命周期，忽略 TTL 更新。

因为缓存存在于多层，域名变更的实际生效时间是以”最长一层缓存的剩余 TTL”为准的。权威服务器上的记录修改是即时的，但全球用户看到新值需要等各级缓存逐层过期。

TTL 对变更生效的影响

假设一条 A 记录的 TTL 是 86400 秒（一天），在周一 10:00 把解析从旧 IP 改到新 IP：缓存已持有旧值的解析器，最晚要到周二 10:00 才会重新查询；在此期间它们仍会把用户导向旧 IP。如果旧服务器在周二前下线，这部分用户就会访问失败。因此标准做法是：计划迁移前，先把 TTL 降到 300 秒（5 分钟）等一个旧 TTL 周期（此处为一天）过去，让所有缓存都持有短 TTL 版本后再改值，这样变更在 5 分钟内即可全球生效。

应用场景

TTL 最常见的三个应用场景：其一是网站迁移与域名管理，迁移前降低 TTL 是标准前置步骤；其二是高可用切换，配合 GeoDNS 或加权解析做故障转移时，短 TTL 让摘除故障节点更快生效；其三是 CDN（内容分发网络）调度，CDN 的 CNAME 记录通常使用较短 TTL，以便调度系统快速调整边缘节点。此外，在邮件系统场景中 MX 记录与 SPF（发件人策略框架）记录的变更同样受 TTL 影响，调整邮件服务前预先缩短相关记录的 TTL，可以避免新旧服务器并行收信的时间窗口过长。

常见误区

第一种误区是认为”改了解析立即全球生效”。权威侧确实即时生效，但各级缓存按剩余 TTL 继续返回旧值，忽略 TTL 的迁移计划必然出现部分用户访问旧站。第二种误区是把 TTL 设得极短（如 30 秒）图省事。极短 TTL 会显著增加权威服务器查询压力，也可能在解析器高负载时放大延迟，只适合切换窗口期临时使用。第三种误区是忘记迁移后把 TTL 调回较长值——切换完成后恢复 1 小时或 1 天，才能降低日常解析负载。第四种误区是忽视应用层缓存：数据库连接串、长驻进程可能持有超过 TTL 的旧解析，变更后需要重启相关服务。

排查变更不生效

当修改解析后部分用户仍访问旧值时，按层级排查：用 dig +trace 域名 查权威链路是否已返回新值；用 dig @8.8.8.8 域名 对比不同公共解析器的缓存结果；在受影响机器上清除本地缓存（Linux 下 systemd-resolve --flush-caches）后再测。如果权威已返回新值而某解析器仍是旧值，剩余 TTL 到期后自然恢复，无需干预。

排查时还应区分”缓存旧值”与”解析失败”两类现象。缓存旧值表现为部分用户稳定访问旧站点，这是 TTL 机制的正常行为；解析失败则表现为 NXDOMAIN（域名不存在）或 SERVFAIL（服务器失败），通常是权威配置错误或链路异常，与 TTL 无关。混淆两者会把正常的缓存等待误判为故障而反复回滚变更，反而延长恢复时间。对关键业务，建议在变更窗口内同时监控权威服务器查询日志与用户侧解析成功率，用数据确认新值覆盖率，而不是凭个别用户反馈判断全局状态。

参考资料

• RFC 1034：Domain Names – Concepts，TTL 概念的原始定义。
• RFC 1035：Domain Names – Implementation，DNS 记录格式中 TTL 字段的规范。
• RFC 2308：Negative Caching，SOA 最小 TTL 与负缓存的关系。

总结

DNS TTL 是解析结果的缓存寿命，直接决定域名变更的全球生效速度。长 TTL 减轻查询负载但变更传播慢，短 TTL 切换迅速但查询压力增大。正确做法是把 TTL 当作运维工具：稳定期用较长值，计划变更前提前降到 300 秒并等待一个旧 TTL 周期，切换完成后再恢复。掌握”先降 TTL、再改值、后恢复”的节奏，域名迁移和故障切换就不会被各级缓存拖后腿，解析变更也就从”等待运气”变成可预期的时间窗口。