Step 01
变更前记录当前真实状态
保存当前 A、AAAA、CNAME、MX、TXT、NS 和 DNSSEC 相关记录，记录权威服务器、TTL 与变更时间。截图不够可靠，最好保留可复制的文本结果和配置导出。
确认变更对象是否被 CDN、邮件、证书验证或第三方 SaaS 使用。删除看似无用的记录前，先找到业务负责人。
Step 02
提前规划 TTL 和回滚
需要快速切换时，应在旧 TTL 完整经过后再实施变更。临时把 TTL 调低并不会让已经缓存的旧记录立刻失效。
准备清晰的回滚值、执行人和触发条件。如果新服务异常，团队应能在几分钟内恢复旧记录，而不是重新从聊天记录寻找地址。
Step 03
同时检查权威配置和实际传播
先直接查询权威 DNS，确认配置已经正确发布，再从多个递归解析器和地区节点检查传播。权威结果正确而部分地区仍旧，通常需要等待缓存；权威结果不一致则应先修复配置。
如果启用了 DNSSEC，还要检查签名、DS 与委派链。只验证普通 A 记录无法发现信任链错误。
Step 04
变更后验证业务而不是只看 DNS
解析到新地址后，继续验证 HTTPS 证书、Host 路由、API、邮件和监控。DNS 正确但服务未配置主机名，同样会造成用户故障。
在观察窗口内保留新旧服务日志，确认流量已经迁移且错误率正常，再下线旧目标和恢复长期 TTL。
Action Checklist
执行清单
Questions
常见问题
把 TTL 调低后，旧缓存会马上失效吗？
不会。已经缓存的记录仍会遵循原来的 TTL，必须等待旧缓存周期经过后，新的较低 TTL 才能普遍发挥作用。
DNS 传播通常需要多久？
没有固定全球时间。它取决于旧 TTL、递归解析器缓存和权威配置。应分别检查权威结果与多个递归节点，而不是只等待一个经验数字。
权威 DNS 已正确，部分用户仍访问旧地址怎么办？
通常应先等待旧缓存到期，同时保持旧服务可用。若影响超出预期，检查是否存在其他权威服务器、CNAME 链或本地缓存。