DNS迁移并不是简单地替换几条记录，它涉及权威服务器、递归缓存、本地DNS缓存以及各类客户端行为等多个环节。一次计划不周的迁移可能造成邮件丢失、HTTPS证书验证失败，或者网站长时间无法访问。理解整个切换过程的时间窗口和缓存机制，是保证迁移平稳落地的关键。下面从迁移前的准备、具体执行步骤、切换后的验证与风险控制三个方面，梳理一套可操作的流程。
迁移前必须完成的准备工作
迁移前最容易犯的错误是直接在新服务商建立几条常用记录就开始切换，忽略了旧环境中可能存在的大量隐藏记录。完整的记录盘点应当包括A、AAAA、CNAME、MX、TXT、SRV、NS以及任何与邮件认证、域名验证相关的条目。建议使用旧服务商提供的导出功能，或者通过脚本调用API拉取全部记录，并与业务方逐条确认。很多故障都源于遗漏了SPF、DKIM、DMARC这类TXT记录，导致切换后邮件被拒收或进入垃圾箱。
确认新DNS服务商的支持情况同样重要。不同服务商对CNAME展平、ALIAS记录、DNSSEC、地域解析、负载均衡等高级功能的支持存在差异。如果旧环境使用了这些特性，需要提前验证新环境能否等价实现。例如某些服务商不允许在顶级顶点使用CNAME，而旧环境可能通过ALIAS或ANAME实现了类似效果。迁移前应列出一张功能对照表，逐项核对，避免切换后才发现关键功能缺失。
TTL的预降是整个迁移中至关重要的一步。TTL决定了递归服务器和客户端缓存旧解析结果的时间。如果旧记录TTL为86400秒，切换后最长可能还有24小时用户会访问旧地址。因此至少提前一个TTL周期，将所有要迁移的记录TTL调整为300秒或更低。这样做虽然会增加旧服务商的查询压力，但能显著缩短切换后新旧解析并存的过渡期。需要特别注意，TTL修改只能在旧权威服务器上进行，并在正式切换前等待旧TTL自然过期。
DNS切换的具体执行步骤
在旧环境TTL已经降低并等待足够时间后，可以开始在新DNS服务商建立完全相同的区域和记录。建议先创建一个与旧环境完全一致的副本，注意记录类型、值、优先级、权重等字段不能有差异。对于MX记录，需要保留原有的优先级数值；对于TXT记录，如果包含分号或特殊字符，要注意新服务商是否需要转义。创建完成后不要立刻修改注册商的NS指向，而是先通过新服务商提供的测试工具或直接查询新权威服务器验证记录是否正确。
验证新权威服务器可以直接使用dig命令。假设新DNS服务商的权威服务器地址为ns1.newdnsprovider.com，要验证www.ipipp.com的A记录，可以执行以下命令：
dig @ns1.newdnsprovider.com www.ipipp.com A +short
如果返回的IP地址与旧环境一致，说明记录复制成功。同时建议验证MX、TXT、CNAME等关键记录，确保没有遗漏。对于DNSSEC场景，新服务商需要重新生成或迁移DS记录，这一过程更为复杂，可能需要先在旧环境移除DS记录，等待缓存过期后再在新环境启用，否则会导致解析失败。
当新环境记录验证无误后，就可以修改域名注册商处的NS记录，将权威服务器指向新服务商。这一步通常在业务低峰期执行，以便预留充分的观察时间。修改NS记录后，解析不会立即切换，因为顶级域服务器会逐步更新NS缓存，递归服务器也会继续使用旧NS一段时间。此时不要立刻关闭旧DNS服务，至少保留24到72小时，作为回退和过渡的保障。同时可以降低旧环境记录的TTL，使切换过程更平滑。
切换后的验证与风险控制
切换后需要从多个位置验证解析是否已指向新环境。使用公共递归解析器进行查询，可以观察新记录是否开始生效。以下命令使用了公共DNS服务器8.8.8.8查询NS记录，以确认当前可见的权威服务器：
dig @8.8.8.8 ipipp.com NS +short
如果返回的新NS地址与预期一致，说明顶级域和递归层已经开始接受新权威信息。还可以使用带trace的dig命令观察完整解析路径，定位是哪个环节仍在使用旧缓存。对于重点域名，建议从不同运营商、不同地区发起查询，因为各地递归服务器缓存进度可能不一致。
切换后的监控不能只看NS记录，还要关注实际业务表现。网站访问、邮件收发、API调用等都可能受解析缓存影响。如果发现部分用户仍然访问旧地址，可以检查旧服务上的连接日志，判断这些请求来自哪些地区或运营商，并评估是否需要临时在旧环境做反向代理或跳转，以保护用户体验。旧DNS服务此时仍然保持可用，是处理异常的最后一道防线。
需要重点观察的一个指标是解析错误率。如果出现SERVFAIL、NXDOMAIN或响应超时，可能意味着新环境的记录格式有问题，或者DNSSEC配置不匹配。此时应优先回退NS记录到旧服务商，并继续排查。回退时需要重新在注册商处改回旧NS，并等待缓存恢复。由于旧环境记录仍存在，回退通常能够较快生效，但前提是旧服务未被关闭。
容易被忽略的注意事项
迁移过程中经常被忽视的是邮件相关记录。MX、SPF、DKIM、DMARC等记录如果配置错误，会造成邮件投递失败或域名信誉下降。尤其当邮件服务托管在第三方平台时，需要确认新DNS服务商是否支持相同的TXT记录长度和分割方式。某些服务商对长TXT记录有长度限制，而SPF记录可能超过单个字符串限制，需要拆分为多个带引号的字符串。切换前应发送测试邮件，检查邮件头中的认证结果。
另一个容易出错的环节是TTL预降的时间窗口。很多团队在修改TTL后立即切换NS，结果旧缓存尚未过期，新旧记录混杂时间远超预期。正确做法是：在旧环境将TTL调低后，等待至少等于旧TTL的时间，确保所有递归缓存中的旧TTL已经过期。举例来说，如果旧TTL为86400秒，调低后至少等待24小时再切换。这个等待过程虽然降低了迁移效率，但能避免切换后长时间的不一致。
如果旧环境启用了DNSSEC，处理不当会导致解析完全失败。DNSSEC要求DS记录与签名链严格匹配，换到新服务商后，需要在新环境重新签名并重新提交DS记录。更为稳妥的做法是：先在注册商处删除DS记录，等待DS缓存过期，再切换NS到新环境并重新添加DS。整个过程需要仔细规划操作顺序，任何一步颠倒都可能让域名无法解析。
最后要强调的是，不要在切换完成当天就停用旧DNS服务。至少保留旧服务运行到确认所有递归缓存都已更新，通常建议观察48到72小时。通过监控旧服务的查询量，如果查询量已经降到很低且没有异常请求，再逐步停止解析或删除记录。DNS迁移的成功标准不是修改了NS记录，而是所有用户都能稳定解析到新地址且业务无异常。