开启DNSSEC后迁移DNS：DS记录怎么衔接才不会断解析
为什么记录全部复制了，域名仍然失败
DNSSEC给解析数据增加可验证的签名关系。父区发布的DS记录用于关联子区的密钥，新DNS平台通常有自己的DNSKEY与签名。如果名称服务器已经切到新平台，父区却仍保留无法与新区域对应的DS，执行验证的解析器可能拒绝返回结果。
这解释了迁移后常见的一种现象：在部分查询工具里可以看到地址，用户却收到SERVFAIL。问题未必是A记录缺失，而可能是信任链衔接错误。Cloudflare的配置与排障文档都强调，迁移时要处理注册商侧的DS记录。DNSSEC说明、排障文档
迁移前先收集三个位置的信息
分别记录注册商处的名称服务器与DS、旧权威服务的DNSKEY及签名状态、新平台的DNSSEC能力。不要把注册商、DNS托管商和服务器供应商混成一个角色；它们可能由不同公司提供，负责人的登录权限也可能不同。
保存全量区域记录及现有TTL，检查邮件、验证用TXT、CAA与容易遗漏的子域名。DNSSEC迁移还要关注父区DS的TTL，它与普通A记录TTL不是一回事。仅把A记录TTL调低，并不能让旧DS缓存同步快速消失。
迁移计划应写明每一步的执行人、验证人和停止条件。旧平台在迁移窗口内应继续提供正确答案，避免新平台出现问题时没有可靠回退对象。域名注册商的恢复方式和账号权限也应提前验证，防止关键修改无法执行。
根据平台能力选择迁移路线
一种路线是按平台官方流程先解除父区DS关系，等待相关缓存过期并验证，再迁移名称服务器，最后在新平台重新启用DNSSEC。这里存在一段没有DNSSEC保护的窗口，应由业务负责人理解并安排。不能先关闭旧区域签名却保留父区DS，那会让仍依赖旧链路的验证器遇到错误。
另一种路线是连续签名迁移，利用兼容的密钥发布或多签名能力在过渡期同时建立可信关系。它要求两边平台具备必要功能，并严格遵循各自的步骤。Cloudflare官方主动迁移教程就有明确的前置能力和密钥衔接要求，不能把其中片段套到任何DNS供应商。官方迁移教程
一般网站不应自行拼接两条路线。先核实双方支持能力，再采用完整且可验证的流程。如果平台不支持导入或联合发布所需密钥，应调整迁移方案，而不是猜测哪些记录“应该可以直接复制”。
等待时间要依据实际记录与流程
不要用“等十分钟”作为通用标准。不同记录有不同TTL，注册商到父区的更新也需要实际验证。执行某步后，应观察父区权威结果和多个验证解析器，再按所采用流程等待旧缓存退出。某个本地查询已经更新，不代表所有缓存都已更新。
假设旧DS的TTL明显长于网站地址记录，就需要把密钥转换阶段安排得更早，或延长变更窗口。这个时间安排来自实际DNS状态，而不是服务器距离或机房所在地。计划中的等待阶段仍应保持旧服务可用并监测失败率。
新平台启用签名后，核对注册商发布的DS与新平台提供的参数一致，再测试主域名和关键子域名的验证结果。既要看到预期地址，也要确认签名链有效。最后保存变更前后结果和完成时间，取消旧平台前再核实不存在仍依赖它的委派或区域。
如果迁移过程中出现验证失败，优先按记录好的状态回退或修复不匹配关系。连续反复开关DNSSEC会让缓存状态更加复杂，延长恢复时间，也削弱已有证据的价值。