改一条地址记录很容易,预测每个解析器何时停止使用旧应答却很难。时间到活性(TTL)值随 DNS 响应传播,并控制缓存可复用的时长。在迁移那一刻降低 TTL,并不能改写更早被缓存下来的应答。
在事件前降低 TTL
如果既有记录是一天的 TTL,至少要在计划切换前一个旧 TTL 时就把它降低。这样在旧端点仍然权威时,缓存有时间去取较短的值。确切间隔应写进变更计划,而不是在迁移中即兴执行。
记录来自权威服务器与至少一个递归解析器的应答:
dig +noall +answer www.example.test A
dig @1.1.1.1 +noall +answer www.example.test A
递归解析器显示的剩余 TTL 是它当前缓存状态的证据。不同解析器合理地显示不同的剩余值。
让两侧都保持有效
切换期间,保持旧端点与新端点都能为预期主机名提供服务。TLS 名称、重定向与应用配置在两侧必须一致。权威记录改变后立刻移除旧端点,会给仍持有先前应答的客户端造成本可避免的停机。
否定应答也会被缓存。一个最近返回 NXDOMAIN 的名字,其出现可能很慢才可见,因为根据区域的权威数据,否定响应可能仍留在递归缓存里。
观察后恢复 TTL
一旦权威与具有代表性的递归应答都指向新端点,且旧缓存窗口已过,就恢复正常 TTL。在变更记录中保留旧值、新值、权威应答与回滚条件。
来源
- RFC 1034 — Domain Names: Concepts and Facilities,缓存模型,已核验 2026-08-22。
- RFC 1035 — Domain Names: Implementation and Specification,TTL 字段,已核验 2026-08-22。
- RFC 2308 — Negative Caching of DNS Queries,否定缓存模型与保留的错误 TTL,已核验 2026-08-22。