移动签名区域是一种协调的信任过渡。注册商可以控制授权和 DS 更改，而新旧DNS提供商控制区域数据和签名密钥。成功的导入并不能证明验证解析器可以遵循每个中间状态。
盘点旧的信任路径
参考： RFC 6781 §4.3.5.
导出普通记录、DNSKEY和DS数据、签名配置、相关TTL和授权地址。记录谁可以更改父 NS 和 DS 数据。确认新提供商是否支持导入现有密钥、协调签名或仅支持新的独立密钥集。除非经批准的安全程序和兼容的提供商需要，否则请勿导出私有签名密钥。
在选择迁移方法之前，请测试新权限是否一致地为整个区域提供服务。包括MX 、选择器、身份验证TXT和 TLSA 记录。保留否定答案行为和现有代表团。一个新健康的 DNSSEC chain 不补偿丢失的邮件记录。
选择记录的过渡
参考： RFC 6781 §4.1, RFC 6781 §4.3.5, RFC 8767 §4.
RFC 6781描述了DNSSEC轮转和运营商变更注意事项。不存在独立于提供商能力的安全通用序列。当缓存的 DS、DNSKEY 和 NS 信息重叠时，协调的转换可以保持旧的和新的验证路径可用。如果提供商无法支持所选方法，请与他们一起安排记录的过渡，而不是发明时间捷径。
故意的签名到未签名到签名的迁移是一种安全降级，具有自己的依赖顺序和等待期。父 DS 不得继续指向不可用的子密钥。相反，在相应的签名子项可达之前添加新的 DS 可能会导致失败。在切换之前降低 TTL 不会缩短已使用旧 TTL 缓存的记录的生命周期。 RFC 8767允许在指定的刷新失败条件下提供陈旧服务；不要将 TTL 过期单独视为每个依赖路径已废弃旧数据的证据。
演练不兼容的缓存状态
参考： RFC 6781 §4.3.5, RFC 4035 §5.
建立一个一次性的家长和两个权威的儿童服务。定义旧 DS/密钥 A 和新 DS/密钥 B，以及固定MX和 TLSA 测试数据。测试至少四种解析器状态：使用旧信任数据的旧委派、使用兼容信任数据的新委派、使用仅限新密钥的旧缓存 DS 以及使用仅限旧密钥的新缓存 DS。最后两种是故意的不兼容情况，不可接受的过渡状态。
对于每个状态，保留父 DS、子 DNSKEY 和 RRSIG 数据、解析器缓存设置、时钟、精确查询和验证器跟踪。在所选重叠之前、期间和之后重复。如果邮件端点发生更改，请单独检查证书与 TLSA 的关联。这些是基于解析器的迁移测试的要求。下面保留的离线加密矩阵仅涵盖签名数据兼容性，而不是实时迁移。
使回滚成为信任操作
参考： RFC 6781 §4.3.5, RFC 4035 §5.
改回 NS 不会刷新缓存的 DS 或 DNSKEY 信息。回滚计划必须指定哪些键仍然可用以及哪些缓存组合仍然有效。保留旧服务和所需的签署材料以供批准的重叠使用，并采用受监控的停用标准而不是方便的日历日期。
切换后，比较每个权威服务器、多个相关解析器路径和代表性电子邮件测试。在预期的缓存转换后确认验证，然后通过更改过程淘汰旧的基础设施。保留准确的最终 DS 和委托证据，以便下一个操作员可以解释生成的信任路径。
观察到的合成迁移矩阵
参考： RFC 4035 §5.
2026 年 11 月 7 日保留的密码实验室进行了检查，但未重新运行本次审查，测试了七个签名数据状态。旧 DS/密钥 A、与密钥 A 重叠的 A/B DS、与密钥 B 重叠的 DS 以及最终 DS/密钥 B 均经过验证。具有仅新密钥 B 的仅旧 DS 失败，仅用 B 替换 DS 后回滚到密钥 A 也是如此。恢复匹配 再次验证材料。这些是使用生成的测试密钥进行的实际签名和 DS 检查，而不是模拟的通过标签。它们展示了不兼容的缓存数据组合，但不模拟解析器缓存、提供程序 API 或已用的 TTL 转换。实时提供程序迁移、计时和回滚执行仍待处理。