我把 TTL 设成 60，解析反而慢了

听说 TTL 短切换快，我把一个稳定站的 TTL 调到 60 秒，想着以后改记录立刻生效。

结果解析耗时上去了，权威服务器收到的查询也多了。稳定期根本不需要这么短，纯粹给自己找麻烦。那次之后我把它调回去，耗时立刻恢复正常。

两端各付什么代价

短 TTL：变更生效快，但缓存命中率低，每次都要回源问一遍，解析耗时会上升，权威侧压力也大。

长 TTL：缓存命中高、解析快，但改完之后要等更久才全网生效，出故障时切不走。

没有哪一端绝对好，只有当下阶段更需要什么。查询量大的站，短 TTL 的代价会被放大。TTL 太长也会拖慢故障切换，特别是多机房互备的场景。

DNS 查询：多地区多运营商解析结果对比

DNS 查询：多地区多运营商解析结果对比

按阶段选

稳定运行、不常改的站，TTL 可以设长一些，让缓存发挥作用。具体多长，看解析商建议和业务容忍度。没有变更计划的站，没必要为了「灵活」牺牲性能。

设值前先问自己：这个域名多久会变一次。答案不是某个数字，而是你的事故恢复目标和变更频率。

计划换 IP、迁移机房、切换解析商之前，提前把 TTL 调短，等旧缓存过期，再动记录。这一步要提前做，不要等出事才想起来。

迁移完成、确认稳定后，再把 TTL 调回正常值。

实际生效会被打折扣

有些递归服务器不完全遵守 TTL，会自己设上下限。你写了很短的值，它可能仍然缓存更久。

客户端的缓存也是一层，浏览器、系统、路由器各有各的策略。

所以「设了 60 就 60 秒生效」只是理想情况，评估时要留余量。一些公共 DNS 还会对极短的 TTL 做下限处理。

怎么验证

用宝塔拨测的 DNS 测速从多地区多运营商节点查，看各地返回的记录值和解析耗时。

改 TTL 之后，观察耗时有没有变化。短 TTL 下，各地不一致的窗口会缩短，但平均耗时会上升。

再直接查权威，确认 TTL 值真的改上去了，别只看后台界面的显示。验证时最好在变更前后各留一组数据，方便对比。

复测和常见坑

改 TTL 本身也要等旧值过期，不是立刻生效。顺序是：先调 TTL，等一轮，再改记录。

连查两三次，确认各地收敛。改完记录，再把 TTL 调回去，同样要等一轮。

最容易被忽略的是：只改了记录没改 TTL，或者反过来，结果两边对不上，排查时越想越乱。把变更时间线记下来，排查时能对得上。也别忘了，递归侧的结果才是用户真正看到的。