迁移 DNS 时怎样避免 DNSSEC 断链：从 DS 记录开始核对

更换 DNS 托管商后，部分网络能打开网站，部分网络却返回 SERVFAIL，这时应检查 DNSSEC 信任链。只核对 A、AAAA 和 CNAME 记录是否复制完整，无法证明签名配置也正确。

两个管理面必须同时纳入变更

DNS 托管商负责签名与密钥相关记录，注册商侧的 DS 记录把子域密钥与上级信任链连接起来。Cloudflare 的 DNSSEC 文档提醒，迁移时遗留的 DS 记录可能与新服务不匹配。是否采用多签名迁移、如何调整 DS，应依据双方提供商支持的正式流程。

迁移前准备一张核对表

• 当前权威 NS 与注册商登记是否一致，谁能执行各自的变更。
• DNSSEC 是否启用，现有 DS 参数、密钥标签和相关 TTL 是什么。
• 新服务是否支持目标迁移方式，是否已完成全部业务记录与签名准备。
• 哪些关键域名用于网站、邮件、API 和身份登录，谁负责逐项验收。

保留当前配置的受控备份和变更时间线。DS、DNSKEY 与 NS 的修改顺序应写入变更单，并按实际 TTL 安排等待与验证；不要凭“已经过了几分钟”推断全球缓存已更新。

验收应包含会验证签名的解析路径

分别检查权威侧记录和多个递归解析路径，记录是否启用 DNSSEC 验证、响应状态与查询时间。某个不做验证的解析器能返回地址，不能作为信任链正常的证明。出现失败时，先区分记录不存在、委派错误、签名失败和网络问题。

事先约定暂停与回滚条件，例如关键登录域名在验证解析器持续失败时停止下一步。恢复也必须按提供商流程处理信任链；反复来回切换 NS 和 DS 可能延长不一致窗口。

DNSSEC 提供解析数据真实性与完整性验证，不负责隐藏查询内容，也不能替代 HTTPS。配图是概念示意，不表示真实 DNS 层级。

参考：Cloudflare：DNSSEC。核对日期：2026年10月4日。