多方签名 DNSSEC 包含两种模型，允许不同的权威 DNS 提供商同时为同一 zone 提供服务并启用 DNSSEC。
这意味着与需要在查询时对 DNS 记录进行实时签名（live-signing）的 DNS 功能有更好的兼容性，也使你能够在不禁用 DNSSEC 的情况下将 zone 迁移到 Cloudflare。
你可以使用 RFC 8901 ↗ 中描述的任一模型来设置多方签名 DNSSEC。
多方签名 DNSSEC 关注 DNSSEC 验证所需的信任链，并利用它来保证即使涉及多个提供商，验证也能完成。
否则验证可能出问题的一个示例情况是：解析器已缓存某个提供商的 DNSKEY 记录集 ↗，却收到由另一个提供商签名的响应。
为避免此类问题，设置多方签名 DNSSEC 时，你需要调整：
- 各 DNS 提供商在其 DNSKEY 记录集中拥有的区域签名密钥（ZSK）。
- 谁负责安全入口点（SEP）、密钥签名密钥（KSK）以及委派签名者（DS）记录。
当这些配置以如下方式调整后——(a) 所有相关提供商都拥有彼此的公钥区域签名密钥（ZSK），且 (b) 委派签名者（DS）记录引用必要的密钥签名密钥（KSK）——多个提供商对 zone 进行实时签名就不再是问题。
在两种模型中，所有提供商都会将彼此的区域签名密钥（ZSK）添加到其 DNSKEY 记录集中；而在模型 1 中，仅使用一个密钥签名密钥（KSK）来签名这些 DNSKEY 记录集。该 KSK 的管理及其由 DS 记录（即安全入口点）的引用，由 zone 所有者或仅由一个提供商（由 zone 所有者指定）负责。
另一方面，在模型 2 中，每个提供商使用自己的 KSK 签名自己的 DNSKEY 记录集，然后这些 KSK 由 DS 记录（安全入口点）引用。
在 Cloudflare 上开启多方签名 DNSSEC 时，会发生以下变化：
- 内部标志：Cloudflare 设置一个内部标志，允许你向 zone 添加 DNSKEY 记录。
- 包含外部 ZSK：当你添加来自辅助提供商的 DNSKEY 记录时，Cloudflare 会将它们包含在 DNSKEY RRset 中。
- 使用 Cloudflare 的 KSK 签名：Cloudflare 使用 Cloudflare 的 KSK 签名外部 ZSK，从而创建多方签名 DNSSEC 模型 2 RRset。
- 生成 CDS/CDNSKEY：若你添加其他提供商的 KSK（非必需但建议），Cloudflare 会生成 CDS/CDNSKEY RRset，以便与验证工具兼容。
此配置可确保解析器能够验证来自任一提供商的响应，因为所有 ZSK DNSKEY 均由 DS 记录中引用的相应 KSK 签名。
设置多方签名 DNSSEC 时，请遵循以下最佳实践，以帮助顺利部署。
Cloudflare 建议多方签名设置使用模型 2。在此模型中，每个提供商都有自己的 KSK DNSKEY，从而产生两条 DS 记录（每个提供商一条）。这可提供更好的独立性与灵活性。
- ZSK（区域签名密钥）：标志
256 - KSK（密钥签名密钥）：标志
257
在提供商之间交换密钥时，请确保向 DNSKEY RRset 添加正确的密钥类型（通常为 ZSK）。
在对 DNSKEY 与 DS 记录进行更改后，请始终等待 TTL 时长再进行下一步。这可确保缓存记录在新记录生效前过期，从而防止验证失败。
并非所有 DNS 提供商都支持将外部 DNSKEY 添加到其 DNSKEY RRset。在开始多方签名迁移之前：
- 确认你的其他提供商支持多方签名 DNSSEC。
- 确认他们可以将 Cloudflare 的 ZSK 添加到其 DNSKEY 记录中。
- 如有可能，在非生产环境中测试该配置。
部分第三方提供商可能不支持所需功能。
多方签名 DNSSEC 涉及在多个提供商之间协调加密密钥。在部署到生产环境之前：
- 验证双方提供商的 DNSKEY RRset 中都包含彼此的 ZSK。
- 确认注册商处存在两条 DS 记录。
- 使用 DNSSEC 验证工具测试来自双方提供商的解析。
- 在过渡期间监控验证错误。