摘要

  • RFC 8901 是体现 IETF 共识的 Informational 文档，不是 Standards Track 强制规范，也不能证明某家命名提供商已经部署多签名者 DNSSEC。
  • 在它给出的两种模型中，每家提供商的 DNSKEY RRset 都必须包含所有参与者的活跃 ZSK。否则解析器可能缓存 A 的密钥，又在故障切换时收到 B 的签名，最终拒绝答案。
  • 区域所有者必须在故障前协调公钥交换、KSK 与父区 DS 的连接方式、共同算法和轮换时序。第二供应商只是潜在路径，证据链完成后才是 DNSSEC 冗余。

服务器活着，验证链却断了

设想一个区域由两家独立的权威 DNS 提供商服务。验证解析器沿安全委派进入区域，从 Provider A 取得 apex DNSKEY RRset，用父区 DS 验证后放入缓存。稍后，这份缓存仍然有效，但 A 已不可达。解析器选中 Provider B，B 用自己的 ZSK 对查询结果签名并返回。

B 的服务没有停，答案仍可能不可用。如果解析器从 A 缓存的 DNSKEY 集合里没有 B 当前使用的 ZSK，它就找不到经过认证的公钥来验证 B 的 RRSIG。解析器也许会继续尝试其他权威服务器，承担额外往返与计算成本；也可能在重试或延迟上限前放弃，或者让下游客户端先超时。

RFC 8901 没有改变解析器的行为。它要求签名者提前构造一个共同密钥视图，使现有验证行为在权威路径切换后仍能工作。两条网络、两份供应商合同和更多 NS 记录只证明可能存在第二条权威可达路径，不能证明 B 的签名能被从 A 取得的缓存状态验证。只有验证路径也能跨过故障，冗余才完整。

一个不变量，两种托管结构

Model 1 由区域所有者持有共同 KSK，并管理父区 DS；每家提供商持有自己的 ZSK。所有者收集各家的 ZSK 公钥，组合成同一个 DNSKEY RRset，用共同 KSK 签名，再分发给所有提供商。即使密钥集合不变，DNSKEY 的 RRSIG 临近到期时，所有者也要重新签名和分发。

这种结构让父区只需要连接所有者的 KSK，也让各处呈现同一份签名密钥集。代价同样集中：KSK 托管、周期性签名、各家 API 权限和可靠分发组成一个共同控制面。只要一家仍展示旧版本，成功的密钥仪式也会变成分裂现实。

Model 2 让每家提供商分别持有 KSK 和 ZSK。每家把其他签名者的 ZSK 公钥导入自己的 DNSKEY RRset，再用自己的 KSK 签名。父区 DS RRset 同时包含各家 KSK 的 DS。解析器无论从哪家取得 DNSKEY，都能沿相应 DS 入口完成认证。

私钥托管因此保持分散，但需要同步的公开状态更多。A 的 KSK 轮换会改变父区中属于 A 的 DS 路径；A 的 ZSK 轮换会改变所有其他提供商必须发布的 DNSKEY 视图。私钥彼此独立，并不消除对共同公开状态的依赖。

轮换是一笔分布式交易

在 Model 1 中，A 生成新 ZSK 后不能立即用它签名。区域所有者要取得该公钥，把它加入组合 DNSKEY，重新签名并部署到所有提供商。激活必须等待全体权威发布和 DNSKEY TTL；删除旧 ZSK 则要等旧签名覆盖的数据和最长相关 TTL 都不再依赖它。KSK 轮换还要跨越父区 DS 的发布与缓存。

在 Model 2 中，A 可以用自身 KSK 签 DNSKEY，但仍要把新 ZSK 交给区域所有者，由所有者推动 B 及其他签名者导入。A 应当等导入、双方所有权威节点传播以及 DNSKEY TTL 全部完成后，才用新 ZSK 签普通数据。删除旧密钥要反向完成同一协调。

因此，“密钥已生成”“API 返回 200”或“一次 DNSKEY 查询正确”都不是连续性收据。可信记录应按顺序保存：导出、所有者接收、各家导入、每个权威服务面发布、TTL 经过、使用各家答案的独立验证，然后才是激活或退役。

算法与否定答案也属于合同

参与者必须使用共同的 DNSSEC 签名算法，或相同的算法集合。DNSKEY 同时出现多种算法时，RFC 4035 的签名要求会作用于区域 RRset。两家各自选择互不兼容的算法，不会因为存在“多供应商”标签就自动互补。

NSEC 或 NSEC3 否定证明随负面答案一同返回，所以不同提供商在技术上可以采用不同机制。但把 NSEC 与 NSEC3 混用会让攻击者直接查询采用 NSEC 的提供商，从而削弱 NSEC3 对区域枚举的限制；长期混合配置也可能降低负缓存效率。RFC 8901 倾向单一机制，无法统一时也应把差异降到最低。

因此，只验证主页 A 或 AAAA 记录不够。正面答案可能正常，否定名称或类型查询却经过另一套签名、证明和缓存路径。

文档没有证明什么

RFC 8901 是 Informational。它没有证明任何命名提供商支持所需 API、正确导入外部 ZSK、完成过真实故障切换，也没有给出停机事件、时延分布、可用性提升或采用率。DNSSEC 验证成功同样不证明商业授权、应用健康、流量已切走或服务最终可用；它只证明所观察数据、签名、公钥和信任链之间的有限密码学关系。

可执行结论因此十分克制：购买第二家提供商只能减少一类依赖。区域所有者必须在第一家消失前，就能重现共同密钥视图、父区入口、算法选择和轮换时间线，这条备用路径才是 DNSSEC 意义上的冗余。

来源