如何确认 DNS 迁移顺利完成

迁移 DNS，无论是更换服务商、改用新的域名服务器方案，还是重构大批记录，风险都比大多数基础设施变更更高，原因恰恰在于出错时不会大张旗鼓地失败。一条出问题的记录只是悄无声息地不再解析，或者解析到了错误的对象，而最先发现问题的往往是一张客服工单，而不是告警。

迁移之前

• 从当前服务商导出所有现有记录，要完整的区域文件或等效文件，而不只是您记得配置过的那些。
• 对即将变更的记录调低 TTL，至少提前一个完整的 TTL 周期。
• 记下所有记录的当前值：A/AAAA、CNAME、MX、TXT（包括 SPF/DKIM/DMARC），以及正在使用的任何不太常见的记录类型。

迁移之后

1. 直接向新的权威域名服务器查询每一条已迁移的记录，并把每个应答与迁移前的导出内容进行比对。
2. 对每个以前有 A 或 AAAA 的主机名，分别独立检查二者，迁移了一种地址族却忘记另一种，是很容易发生的疏漏。
3. 专门验证 MX 以及周边的邮件身份验证记录，DNS 迁移导致邮件出问题的情况格外常见，造成的影响也格外严重。
4. 在宣布迁移完成之前，请通过不止一个解析器重新检查，最好还能覆盖不止一个网络位置。
5. 等旧 TTL 窗口过去之后再检查一次，切换之后立即得到干净的结果，并不能保证全球所有缓存了旧应答的解析器都已跟上。

对完整的主机名列表做批量查询，在切换后立即运行一次，并在旧 TTL 窗口过去之后再运行一次，就能把这件事从逐条记录的手动检查，变成一个可重复的单一步骤，并为您留下一份可导出的记录，说明究竟验证了什么、是在何时验证的。

不要过早拆除旧的一侧

迁移之后最常见的遗憾，并不是漏掉了某条记录，而是在新的域名服务器上线的当天，就取消或停用了旧服务商的账户或域名服务器。由于全球仍有一部分解析器在使用指向旧配置的缓存应答，直到其 TTL 过期，所以在切换之后，让之前的服务商至少再保持一个完整的旧 TTL 窗口的运行（即使没有任何新内容指向它），是一份廉价的保险。如果确实需要快速回滚，旧的一侧仍在应答，意味着几分钟内就能把域名服务器切回去，而不必在压力下凭记忆重建区域文件。

预演能在问题成真之前发现大部分错误

如果新的 DNS 服务商允许，请提前搭建好完整的新区域，配置齐全但暂不委派，并直接查询它（绕过正常的委派流程，可以明确地把测试工具指向它的域名服务器，或使用服务商自带的预览功能）。这会把迁移验证从切换后的手忙脚乱，变成切换前的检查，一旦出错，也不会对用户造成任何影响。任何缺失、配置有误或与预期不同的记录，都会在任何一个真实的解析器见到它之前暴露出来，这比在切换已经上线之后才发现错误，压力要小得多。