TTL 是域名解析里很重要的参数，却经常被运维人员忽略，TTL 代表解析记录在递归 DNS 服务器当中的缓存存活时间，DNS 查询结果会清晰展示每一条记录对应的 TTL 数值，读懂这个数值，就可以理解解析修改之后的传播规律。TTL 数值以秒作为单位，数值越大，缓存保存周期就越长。不少运维人员做解析变更时，完全忽略 TTL 参数，导致修改解析之后，长时间内部分用户依旧访问旧 IP。

准备修改解析记录，做服务器迁移之前，提前把 TTL 调小，解析变更之后，各地缓存就可以更快过期刷新。如果 TTL 设置为一天，修改解析之后，部分 DNS 服务器最多会保留一整天旧记录，用户依旧访问旧服务器。DNS 查询可以看到当前生效的 TTL，确认参数调整已经对外生效，再去修改解析记录本身。调整 TTL 同样需要等待原有缓存过期，不能修改之后立刻执行解析切换操作。

TTL 也不是设置越小越好，数值过低会让递归 DNS 频繁向权威服务器发起请求，增加解析查询压力，解析响应速度也会受到一定影响。业务稳定运行阶段，适合使用偏大的 TTL，解析需要频繁改动的特殊时期，临时降低 TTL 完成切换，业务稳定之后再恢复常规数值。长期低 TTL 会提升解析服务负载，极端情况下还会出现解析响应超时的情况。

修改解析记录之后，DNS 查询返回的 TTL 会随着缓存逐步消耗不断递减，不同节点 TTL 剩余时长各不相同，对应各个节点距离缓存过期的剩余时间。看到不同节点 TTL 数值差异，就可以理解为什么有的地区更新快，有的地区更新慢。不同运营商递归 DNS 刷新策略存在差异，也会进一步拉大各地缓存过期的时间差。

不要盲目等待固定时长，借助 DNS 查询观察 TTL 与实际解析返回内容，判断解析传播真实进度。结合业务场景合理设置 TTL，兼顾解析变更灵活性与域名解析整体性能。理解 TTL 背后的缓存逻辑，配合 DNS 查询掌握解析同步状态，能够更科学地规划解析变更操作，减少业务访问波动。