TTL 是 DNS 里最需要权衡的一个参数：短了灵活，长了省事。

两个方向

TTL 短，递归服务器很快就来重新问，你改记录能迅速生效，代价是查询量变大，权威服务器压力高，解析链路出问题时影响面也更直接。

TTL 长，缓存命中率高，解析快、压力小，但改记录要等很久才铺开，出故障时也没法快速切走。

没有绝对正确的值，只有适合当前阶段的配置。

常见场景的建议值

  • 经常变更的记录：300–600 秒，比如测试环境、灰度切换、临时活动域名
  • 稳定业务：3600 秒以上，官网、主站这类一年改不了几次的
  • 准备迁移前：提前 24 小时调到 300 秒，切完再调回去
  • 邮件记录：可以长一些，3600–86400 秒，MX 不常动

很多 DNS 服务商的默认值是 600 或 3600，对大多数站点够用。

为什么不要设得太短

设成 60 秒听起来很灵活，但意味着每个递归服务器每分钟都要来问一次。

域名访问量大的时候，这会变成实打实的查询费用和延迟开销。而且 TTL 太短，缓存几乎不起作用，权威服务器一抖动，用户立刻受影响。

为什么也不要太长

设成 86400 秒，改一次解析要等一天。

更麻烦的是出故障的时候。服务器挂了想切到备用 IP，结果全国用户还在用缓存里的旧地址，只能干等。这种时候 TTL 长短直接决定了故障时长。

一个实用习惯

平时用长 TTL，变更前提前调短。

具体做法：计划明天上午切换，今天上午把 TTL 改成 300，等一天让旧缓存全部过期；明天改记录值，几分钟就能铺开；确认稳定后，再把 TTL 调回 3600。

多花一天准备，换来回滚的余地，很值。