摘要

  • DENIC 对 2026 年 5 月 5 日 .de DNSSEC 故障的最终说明，把核心原因定位在第三代签名系统中一个自研 ZSK 轮换代理的错误：在多个 HSM 参与的正式运行环境里，它没有生成一组密钥并加载到所有 HSM，而是为不同 HSM 生成了不同密钥对，同时给这些密钥使用相同元数据和 key tag 33834。
  • 这起事件的责任问题不是“有没有冗余”，而是冗余是否承载了同一个可验证的签名状态。anycast、多站点和多 HSM 能提高连续性，但只有在共享区域数据、DNSKEY、RRSIG、NSEC3 记录和发布授权关系一致时才有效。

一次顶级域签名状态故障，而不是普通网站不可用

.de 是德国国家顶级域。对使用者来说，访问某个 .de 域名往往表现为浏览器能否打开网站、邮件能否投递、应用能否连接服务器；但在网络基础设施层面，这些现象背后首先是递归解析器能否从 .de 顶级域得到可信的委派信息。DNSSEC 使这套委派不只依赖“有响应”，还依赖响应能否被加密签名链验证。注册局发布的 DNSKEY、由区签名密钥产生的 RRSIG、证明不存在或证明没有 DS 记录的 NSEC3 记录，都参与了递归解析器对一个回答是否可信的判断。

这就是 2026 年 5 月 5 日事件的基础边界。它不是一个单一网站故障，也不是某个二级域持有人配置错误。它发生在 .de 顶级域 DNSSEC 签名与发布关系上，影响的是验证型递归解析器如何看待来自 .de 区的数据。DENIC 在最终报告中称，例行 DNSSEC 密钥轮换导致 .de 域访问受到约三小时的显著限制。这个结论需要与其他历史事件分开：它不是 2010 年 5 月 .de 区发布故障的重演，也不是 2024 年 .ru DNSSEC 事件的替代叙事，更不能被归入泛化的“顶级域偶发宕机”列表。它的特殊性在于，正式运行拓扑中的多 HSM 签名状态没有保持一致，而这种不一致被发布到了依赖 DNSSEC 验证的全球解析路径中。

DENIC 给出的正式运行时间线应作为注册局层面的事件边界使用。其已解决公告称，2026 年 5 月 5 日 21:57 起出现明显影响；2026 年 5 月 6 日 00:08 开始分发正确区域；到 01:15 恢复到此前运行状态。Cloudflare 在其递归解析器遥测中观察到更早的验证失败，这是另一个观察层。两个时间点都重要，但不能被合并成一个“全球统一开始时间”。注册局看到的是自身生成、验证、发布和恢复链路中的状态变化；递归解析器看到的是从外部网络收到的数据何时无法通过验证。一个大型递归解析器的遥测不能直接替代注册局内部时间线，注册局公告也不能覆盖所有网络、缓存和解析器在外部看到的差异。

这种区分不是细枝末节。DNS 故障很容易被描述为“从某时起全部不可用”，但 DNSSEC 事件的实际影响受到缓存、解析器策略、是否验证、是否使用 serve-stale、应用重试行为、网络路径以及被查询记录类型影响。公开资料没有给出逐解析器、逐网络、逐域名、逐应用的完整可用性数据。也没有证明每一个 .de 域名在整个区间内对每一个用户都不可达。因此，严谨的表述应当是：DENIC 报告 .de 域名访问在约三小时内受到显著限制；验证型解析器会拒绝无法认证的数据；非验证型解析器仍可返回数据；不同递归运营商在缓存与临时绕行策略上有不同外部表现。

ZSK 轮换代理和 key tag 33834 的状态错配

DENIC 将根因归于自研轮换代理中的错误。该代理属于第三代签名系统的一部分，这套系统在 2026 年 4 月进入正式运行，结合了 Knot DNS、自研组件和分布在两个地理与网络分离数据中心的多个硬件安全模块。HSM 的作用是保护私钥并执行签名相关操作；在一个设计良好的多 HSM 环境里，多个模块可以提供冗余、隔离和操作连续性。但这种优势建立在同一密钥状态被正确生成、分发、识别和使用的前提之上。

按照 DENIC 的说明，例行 ZSK 轮换期间，错误的代理没有生成一个密钥对并把它加载到所有连接的 HSM，而是为每个连接的 HSM 生成了不同密钥对。这些密钥对却带有相同的元数据和相同 key tag：33834。公开 DNSKEY 记录只写入了其中一个公钥。结果是，只有持有与公开 DNSKEY 匹配私钥的那个 HSM，才能产生可被验证的签名。由其他 HSM 使用不同私钥产生的签名，虽然在元数据上看似属于同一轮换状态，却无法与已发布的 DNSKEY 对应起来。

这不是经典意义上的 key tag 碰撞。经典 key tag 碰撞通常指不同 DNSSEC 密钥经过算法计算后出现相同 key tag，从而在识别上形成歧义。DENIC 在最终报告中明确把本事件与这种情况区分开来：这里的关键是自研代理给不同密钥对赋予了相同的元数据和 key tag，并且只有一个匹配公钥被写入区中。也不能把它描述成 HSM 故障、Knot DNS 故障或入侵。DENIC 表示没有发现妥协迹象，也排除了 Knot 或 HSM 本身故障。责任分析因此应落在签名状态生成、测试拓扑、发布验证、告警处理和回滚授权上，而不是推断未被公开记录支持的组件失效或攻击行为。

DENIC 还称，实践中大约三分之一的签名可验证。这个表述尤其需要保持精确。它描述的是签名输出与唯一已发布 DNSKEY 的匹配关系：只有由持有匹配私钥的 HSM 产生的签名能够通过验证。它不是说三分之一的域名可用，不是说三分之一用户可访问，不是说三分之一查询成功，也不是说整个互联网的可用性稳定在某个比例。由于 SOA 记录随区域更新而变化并被重新签名，具体记录在不同时间点上的验证状态还可能变化。把“三分之一”从签名输出关系扩展成域名、流量或用户影响比例，会制造一种公开证据没有支撑的精确性。

为什么单 HSM 测试环境没有暴露正式运行问题

这起事件最重要的控制边界之一，是测试环境与正式运行拓扑的差异。DENIC 表示，测试环境只有一个地点的一台 HSM，因此触发缺陷所需的多 HSM 行为没有在那里执行。既有测试场景没有覆盖该情形，先前测试、外部审计以及冷并行运行也没有暴露这个正式运行环境才出现的行为。

这并不意味着“没有测试”。相反，它说明测试是否充分不能只看是否运行过测试、是否有外部检查、是否有并行准备，而要看测试拓扑是否复制了会改变系统状态的关键条件。对 DNSSEC 签名系统而言，多 HSM 不是外围容量配置，而是直接参与密钥生成、私钥持有、签名输出和发布一致性的状态主体。如果测试环境只有单个 HSM，它可以验证许多代码路径和普通轮换行为，却无法验证“多个 HSM 是否收到同一密钥材料、是否在同一元数据下保持同一状态、是否会生成相互不匹配但看似同一 key tag 的签名输出”。

正式运行拓扑等价性因此成为问责测试。一个控制体系若声称能覆盖 ZSK 轮换，就需要覆盖轮换时真实存在的状态关系：HSM 数量、分布方式、连接顺序、并发行为、密钥材料加载路径、DNSKEY 写入路径、RRSIG 生成路径、区域序列变化、发布前验证、失败时阻断条件和回滚路径。只验证单实例实验室行为，不足以证明多实例正式环境的状态一致性。

这里的教训比“测试环境要更像正式环境”更具体。对 DNSSEC 注册局而言，测试应当验证的是可以破坏信任链的关系，而不是只验证组件能否正常运行。一个 HSM 能签名，不等于多个 HSM 会签同一状态；一个 DNSKEY 能发布，不等于所有 RRSIG 都能被该 DNSKEY 验证；一个区域能被生成，不等于区域内所有 NSEC3 证明和委派相关记录都处在可验证状态；一个告警能出现，不等于它会阻止错误区域继续发布。

DNSSEC 验证为何会影响未启用 DNSSEC 的二级域

对许多 .de 二级域持有人而言，最容易误解的一点是：即便自己的域没有配置 DNSSEC，也可能在验证型解析器上受到影响。原因在于，顶级域对委派状态的证明本身是被签名的。DNSSEC 不只保护已签名子域的 DS 链路，也要证明某个未签名子域没有 DS 记录。NSEC3 记录提供经过哈希处理的认证否定证明，用于说明某个名字或某个 DS 记录不存在。验证型解析器依赖这些签名证明来判断“这个子域确实没有 DS，因此可以作为未签名委派继续解析”，而不是攻击者删除了 DS 记录或篡改了委派信息。

当 .de 顶级域中相关 NSEC3 记录的签名无效时，问题就不局限于使用 DNSSEC 的子域。验证型解析器可能无法确认未签名子域的委派状态，从而把委派信息判断为 bogus。它不是随意拒绝服务，也不是把安全策略变成可用性攻击；它是在公开信任链下执行 DNSSEC 的设计语义：无法认证的数据不能被当作可信结果返回。RFC 4033、4034、4035 定义了 DNSSEC 的基本验证模型，RFC 5155 描述了 NSEC3 认证否定机制。这些语义在事件中使故障的外部影响超出了“谁主动启用了 DNSSEC”的范围。

非验证型解析器的行为不同。它们不执行完整 DNSSEC 验证，因此可以继续返回数据。这个差异解释了为什么同一时间、同一域名，在不同网络或不同递归服务后面可能出现不同用户体验。一个用户可能看到域名无法解析，另一个用户可能仍能访问；一个应用可能因缓存保持可用，另一个应用可能在缓存过期后失败；一个递归运营商可能通过 serve-stale 或临时策略减轻影响，另一个则严格拒绝 bogus 数据。这些差异不削弱签名状态故障本身，反而说明根因位于共享权威数据的可信性，而外部影响由递归生态的验证与缓存策略进一步塑形。

Cloudflare 的外部缓冲：serve-stale 和临时 NTA

Cloudflare 的说明提供了递归解析器侧的另一层事实。它报告 1.1.1.1 使用 stale data 缓冲了部分影响，并在确认权威签名问题后，对 .de 临时应用 DNSSEC Negative Trust Anchor。serve-stale 的含义是在权威数据暂时不可用或不可验证时，在一定条件下继续提供缓存中的过期数据，以减少解析中断。RFC 8767 对这种机制有说明。它不是无限期忽略新数据，而是在故障窗口中用缓存状态换取可用性，并需要受限的策略条件。

Negative Trust Anchor 更敏感。RFC 7646 把 NTA 定义为临时、本地作用域的例外：递归解析器在确认某个区域的 DNSSEC 状态出现问题后，可以在有限时间内把该区域当作未签名来处理，以恢复解析。Cloudflare 对 .de 的做法应被理解为递归运营商在外部验证到权威签名问题之后作出的受限缓解。它不是证明“关闭 DNSSEC 更可靠”，也不是注册局修复的替代品。NTA 把一个安全决定临时转移给递归运营商：在限定范围内暂停对某个区域的验证，以避免大范围用户不可达。这种决定必须有触发证据、范围边界、到期机制和恢复验证条件。

这也揭示了跨层责任结构。注册局负责发布可验证的权威区域状态；递归解析器负责根据 DNSSEC 语义验证并返回结果；大型递归运营商在权威层故障时可能承担临时缓冲和例外判断。但递归侧缓解不能修复权威层签名不一致。它只能减轻特定解析器用户的体验，并且可能在不同运营商之间表现不同。因此，事件复盘不能把 Cloudflare 的 NTA 描述成全网恢复，也不能把它作为注册局控制充分性的证据。它说明外部生态有应急能力，同时也说明当顶级域签名状态不可信时，外部运营商会被迫在安全验证和服务连续性之间作出短期、可撤销的选择。

检测到了，不等于控制住了

DENIC 表示，三个持续运行的测试和验证工具按预期检测到了缺失或不可验证的签名，但相关通知没有被正确处理，因此未能在无效材料造成广泛影响前及时干预。这一事实把事件从单纯“技术错误”推进到控制设计问题。检测是一种证据产生机制；控制是一种可以改变系统状态的机制。二者之间如果没有明确责任、确认时限、升级路径和发布阻断权，检测就可能只是在事后证明系统曾经发出过警报。

关键问题包括：哪些验证结果足以阻止区域发布？如果候选区域中存在不可验证 RRSIG 或 NSEC3 证明，发布链路是否会自动停止？谁拥有 DNSSEC 验证告警？告警是否需要人工确认？确认超时后是否自动升级？是否有独立于生成系统的验证器对已候选发布状态执行完整链验证？是否存在一个可审计工件，证明 DNSKEY、HSM 私钥状态、RRSIG 输出、区序列号和发布授权互相匹配？如果错误已经发布，哪个角色有权切换到已知良好的签名区域？这个切换是否经过演练，并且能在时限内完成？

这些问题并不是事后苛责。DNSSEC 的失败模式决定了，错误签名区域一旦被权威服务分发，就会被验证型递归解析器正确拒绝。所谓“正确拒绝”，在用户体验上仍可能表现为域名不可用。因此，控制体系必须把验证失败视为发布级风险，而不是普通监控噪声。一个能发现异常但不能阻止发布的验证器，在责任分析中只能算早期证据来源，不能算已经发挥作用的保护层。

恢复时间线和已知良好状态

DENIC 的公告称，2026 年 5 月 6 日 00:08 开始分发正确区域，并在 01:15 恢复到此前运行状态。这里有两个值得分开的动作：一个是开始分发可验证的正确区域，另一个是恢复到先前的运行状态。对外部用户而言，前者可能使部分解析路径开始恢复；后者更接近注册局对自身服务状态的整体恢复判断。但同样，递归解析器缓存、负面缓存、serve-stale、NTA 到期和不同网络刷新节奏，可能使外部观察到的恢复时间不完全一致。

回滚或恢复不是简单把旧文件放回去。DNSSEC 区域状态包括 DNSKEY、RRSIG、NSEC3、SOA 序列、签名有效期和委派相关证明。一个已知良好区域必须经过完整验证，并且要能被权威服务一致分发。对多站点、多 HSM、anycast 的注册局来说，恢复控制还要证明所有发布点看到的是同一个可验证状态，不能一部分节点提供新状态、一部分节点提供旧状态、一部分签名与公开 DNSKEY 不匹配。否则，分布式架构会继续把状态差异暴露给递归解析器。

这就是“服务器数量”和“有效共享状态”之间的差别。anycast 名称服务可以把查询引导到近处或可用的权威节点；多个数据中心可以减少单点机房故障；多个 HSM 可以提高密钥保护和签名能力的连续性。但这些机制不能自动验证签名材料是否一致。如果每个节点都在分发同一个错误区域，冗余只是提高错误响应的覆盖范围。如果多个 HSM 在同一 key tag 下持有不同私钥，冗余甚至可能引入只有正式运行拓扑才有的状态分叉。基础设施连续性因此必须同时覆盖物理层、网络层、软件层和密码状态层。

公开记录的测量边界

目前公开资料仍有明显空白。DENIC 没有公开缺陷源代码，也没有公开轮换代理内部的准确条件顺序。完整正式运行部署图、HSM 选择或签名调度、三个验证系统的原始输出、每个系统首次发现无效材料的精确时间、告警路由与确认配置、完整内部时间线、外部审计范围、冷并行运行证据、逐解析器或逐域名影响数据、经济损失、邮件投递影响、交易失败和补偿安排，都没有形成完整公开记录。

这些空白不应该被猜测填补。严肃的网络基础设施问责，不是把不可见细节转换成人名归因，也不是把“可能造成广泛影响”写成“所有用户全部中断”。公开记录足以支持一个明确结论：.de 顶级域在例行 DNSSEC 轮换期间发布了不一致的签名状态，导致验证型解析器对相关数据 fail closed；单 HSM 测试环境没有覆盖多 HSM 正式运行行为；已有验证工具检测到异常但通知处理未能转化为及时干预；外部递归运营商采取了缓存和临时 NTA 等缓解。公开记录尚不足以支持更强断言：比如具体某段代码如何分支、某个值班人是否失职、全部域名不可达比例、每个网络的恢复时间、或所有整改是否已经有效完成。

测量边界也影响后续控制评估。若未来出现记录证明多 HSM 行为在上线前已被完整演练并通过，那么主要控制问题可能从测试拓扑转向发布授权或告警执行。如果出现记录证明无效材料绕过了强制阻断器，那么重点会转向阻断器设计和权限。如果独立解析器测量显示可见影响范围小于媒体描述，严重性评估可以调整，但共享签名状态故障的性质不会改变。如果有独立证据证明所有整改已经完成并经过演练，前瞻性风险判断也应更新。

DENIC 公布的整改措施应视为承诺

DENIC 发布的整改方向包括更严格代码检查、增强告警、加快有效区域切换、部署前部分验证、暂停进一步 ZSK 轮换直至追加工作完成、扩展测试环境，以及外部安全和流程分析。这些措施都与事件根因和控制缺口相关，但在公开记录中，它们首先是承诺，而不是已经被独立证明全部完成的控制状态。

“加强代码检查”需要说明哪些变更会捕获同类密钥状态错误，是静态检查、同行检查、测试覆盖、形式化约束，还是对密钥对象生命周期的强制不变量验证。“增强告警”需要说明哪些告警有发布阻断权、哪些只是通知、谁必须确认、超时后如何升级。“加快有效区域切换”需要实际演练数据：从检测到错误签名状态，到生成或选取已知良好区域，到跨站点分发，再到外部递归验证恢复，需要多少时间。“部署前部分验证”需要界定部分验证覆盖哪些记录类型、哪些签名算法、哪些 NSEC3 证明和哪些委派场景，是否足以阻止本事件同类状态进入发布链路。“扩展测试环境”需要证明多 HSM、多站点或等价状态关系已经被纳入轮换测试，而不是只增加一般环境容量。

外部安全和流程分析同样需要结果证据。是否公开范围、发现、整改验收和再测试结果，决定了外部依赖方能否评估注册局控制是否已经改变。对一个顶级域来说，许多受影响方没有能力自行审计注册局内部签名系统。他们只能依赖注册局发布的信息、递归运营商观察、标准语义和独立测量。因此，整改透明度本身就是连续性控制的一部分。