当DNSSEC出错时：我们如何应对.de顶级域中断事件
TL;DR · AI 摘要
2026年5月5日，.de因DNSSEC签名错误导致全球解析失败，Cloudflare等验证解析器返回SERVFAIL，影响数百万网站。
核心要点
- DNSSEC签名错误会导致整个TLD下所有域名解析失败，影响范围巨大。
- 密钥轮换期间若签名与DNSKEY不匹配，验证解析器必须拒绝响应并返回SERVFAIL。
- Cloudflare通过临时降级策略缓解影响，强调应急响应机制在核心互联网协议中的必要性。
结构提纲
按章节快速跳转。
思维导图
用一张图看清主题之间的关系。
查看大纲文本（无障碍 / 无 JS 友好）
- .de TLD DNSSEC 中断事件
- 根本原因
- 错误的DNSSEC签名发布
- 密钥轮换协调失败
- 技术机制
- DNSSEC链式信任
- ZSK与KSK角色
- DS记录验证
- 影响范围
- 所有.de子域名
- 全球验证解析器
- SERVFAIL泛滥
- 应对措施
- 临时绕过验证
- 监控与告警
- 与注册局协作
金句 / Highlights
值得收藏与分享的关键句。
任何验证型DNS解析器收到错误的DNSSEC签名都必须拒绝响应并返回SERVFAIL。
DNSSEC确保的是数据完整性而非隐私，签名随记录传输，可在任意跳点验证。
密钥轮换期间若新旧签名未正确同步，将导致整个TLD下的域名无法解析。
随着缓存过期，更多解析请求获取到错误签名，故障呈阶梯式扩散。
客户端重试行为显著推高查询量，放大了监控图表中的异常表现。
Cloudflare采取临时降级策略，在保障安全前提下最小化服务中断。
标题：当 DNSSEC 出现问题时：我们如何应对 .de 顶级域中断事件
来源网址：http://blog.cloudflare.com/de-tld-outage-dnssec/
发布时间：2026-05-06T18:00+01:00
Markdown 内容： 2026-05-06
8 分钟阅读
2026 年 5 月 5 日大约世界标准时间 19:30，.de 国家代码顶级域（TLD）的注册管理机构 DENIC 开始为 .de 区域发布错误的 DNSSEC 签名。根据 DNSSEC 规范，任何收到这些签名的验证型 DNS 解析器都必须拒绝它们，并向客户端返回 SERVFAIL 错误，这包括 Cloudflare 运营的公共 DNS 解析器 1.1.1.1。
德国的国家代码顶级域 .de 是互联网上规模最大的顶级域之一。在 Cloudflare Radar 上，它始终位列全球查询最广泛的顶级域前列。此类 DNS 层级关键节点的中断可能导致数百万个域名无法访问。
本文将介绍我们观察到的现象、此次事件造成的影响，以及在 DENIC 解决问题期间我们采取的临时缓解措施。
DNSSEC 的工作原理
DNSSEC（域名系统安全扩展）为 DNS 添加了加密认证功能。当一个区域使用 DNSSEC 签名后，每组记录都会附带一个称为 RRSIG 记录的数字签名，使解析器能够验证这些记录未被篡改。与 DNS over TLS (DoT) 和 DNS over HTTPS (DoH) 等加密 DNS 协议不同，DNSSEC 关注的是数据完整性而非隐私性。记录内容是公开可见的，但其真实性可以被验证。
DNSSEC 的独特之处在于，签名与其保护的数据一同传输。这意味着无论响应经过了多少缓存或跳转路径，都可以验证其完整性。缓存中的记录与新获取的记录具有同等可验证性。
DNSSEC 建立在信任链的基础上。从根区域开始，其信任锚点被硬编码在解析器中，每个区域通过委派签名者（DS）记录将信任传递给子区域。父区域中的 DS 记录包含子区域公钥的加密哈希值。当解析器验证 example.de 时，会验证整个链条：根信任 .de，.de 信任 example.de。该链条中任何一处断裂都会导致其下所有内容验证失败，因此像 .de 这样的顶级域一旦配置出错，会影响其下的每一个域名。
区域通常使用两种类型的密钥：用于签署区域记录的区域签名密钥（ZSK），以及用于签署 ZSK 本身的密钥签名密钥（KSK）。KSK 的公钥正是父区域 DS 记录所指向的内容，构成了信任链的锚点。轮换 ZSK 相对简单：生成新密钥、重新签署区域记录、等待缓存过期即可。而轮换 KSK 更为复杂，因为必须同时更新父区域的 DS 记录，通常需要与注册商或注册局协调。
在密钥轮换过程中，存在一个关键窗口期：旧密钥正在逐步停用，新密钥正在启用。如果区域中发布的签名使用的密钥无法被解析器通过该区域公布的 DNSKEY 记录验证——无论是因为签名步骤失败、时间安排不当，还是新密钥尚未完全分发——解析器别无选择，只能拒绝响应并返回 SERVFAIL。
我们观察到的情况
2026 年 5 月 5 日大约世界标准时间 19:30，.de 顶级域运营商 DENIC 开始为 .de 区域发布错误的 DNSSEC 签名。任何收到这些记录的验证型解析器都必须按照 DNSSEC 规范拒绝它们并返回 SERVFAIL。1.1.1.1 也不例外。
下图显示了事件期间 1.1.1.1 针对 .de 查询返回的响应码情况。
UTC 时间 19:30 出现 SERVFAIL 的立即激增后，接下来三小时内持续缓慢上升，这是因为缓存记录逐渐过期所致。随着各个域名的缓存记录到期，解析器重新向 DENIC 请求最新数据时，收到的是损坏的签名，从而开始失败。
图中还可看到查询量大幅增加。这在 DNS 故障期间很常见，因为客户端会重试失败的查询，通常重试三次或更多次，导致原始数据被放大。因此 SERVFAIL 的比率看起来比实际用户影响更严重，因为其中许多查询代表的是同一用户反复尝试访问同一域名。
可能令人惊讶的是，在整个事件过程中 NOERROR 响应率保持相对稳定。这是“serve stale”机制在起作用，我们将在下一节详细介绍。
Serve stale
递归解析器会将从权威名称服务器接收到的记录缓存一段时间，具体时长由每条记录的 TTL（生存时间）决定。在记录处于缓存期间，解析器直接提供该记录，无需再次查询权威名称服务器。当 TTL 到期后，解析器才会重新获取一份新的副本并再次缓存。
在中断期间，新发起的记录查询最终返回了 SERVFAIL。DNSSEC 签名已损坏，解析器正确地拒绝了这些响应。但许多 .de 记录在事件开始前就已存在于缓存中。1.1.1.1 并未立即丢弃这些记录并返回 SERVFAIL 给用户，而是继续提供这些已过期的缓存记录。这被称为“提供陈旧响应”（serving stale）。
1.1.1.1 实现了 RFC 8767，该标准正式定义了这种行为。当上游解析失败时，解析器可以选择继续提供已过期的缓存记录，而不是返回错误。这显著减轻了上游服务中断的影响，为运维人员争取了响应时间。
下图展示了这一结果，显示了事件期间排除陈旧响应后的 .de 查询响应码。如果没有陈旧响应，NOERROR 的比例从 19:30 开始持续下降。这些代表的是用户之所以能获得正常响应，仅仅因为相关记录仍在缓存中。
我们的缓解措施
尽管问题很大程度上不在我们的控制范围内，且“提供陈旧响应”机制已在正常工作，但大量用户仍受到了实际影响。幸运的是，我们采取了一些措施来改善情况。
负信任锚点（Negative Trust Anchors）
RFC 7646 定义了负信任锚点（NTA）的概念。在正常的 DNSSEC 操作中，验证型解析器会维护一组信任锚点：即信任链根部的公钥。每个使用 DNSSEC 签名的 DNS 区域都有一个信任锚点，其子区域在此基础上构建自己的信任链。当连接这些链的加密签名被破坏时，响应将被拒绝并导致 SERVFAIL。而 NTA 是一种明确的例外机制，它告诉解析器将某个特定区域视为未签名状态，从而绕过该区域下所有域名的验证。
NTA 正是为应对这类事件而设计的。当天顶级域（TLD）运营商发布了损坏的签名时，每一个支持 DNSSEC 验证的解析器都不得不对该 TLD 下的所有域名返回 SERVFAIL。这不是因为这些域名本身有问题，而是因为其父区域配置错误。在这种情况下继续返回 SERVFAIL 已无安全意义：故障已是公开已知的问题，并正在修复中。RFC 7646 明确指出，TLD 配置错误正是 NTA 的主要使用场景。
我们实际部署的方案
对于 1.1.1.1，我们使用自研的解析器，称为 Big Pineapple，它同时为 1.1.1.1 for Families、Gateway DNS、DNS Firewall 等服务提供支持。目前，我们尚未实现原生的 NTA 机制。相反，我们利用现有的覆盖规则机制，将 .de 标记为不安全区域，从而使所有 .de 查询像未启用 DNSSEC 一样进行解析。此功能等效于 NTA，尽管它并未在任何 RFC 中正式定义。
绕过 DNSSEC 的决定是一种有意的权衡。在事件持续期间，.de 域名将面临 真实攻击 的风险。但我们评估认为这是可接受的，因为此次签名失效范围广泛、已被公开确认，并且对互联网上所有验证型解析器的影响是均等的。正如我们在内部事故群组中所说：“_现在没有任何 1.1.1.1 用户在解析 .de 域名时，会宁愿看到 SERVFAIL 而不是未经验证的响应。_”
我们于 UTC 时间 22:17 推出了缓解措施，标志着 1.1.1.1 受影响状态的结束。我们也通过 DNS-OARC Mattermost 与其它 DNS 运营商共享了这一信息。
源站解析的缓解措施
虽然所有互联网用户都可以访问我们的 1.1.1.1 解析器，但我们对使用 Cloudflare CDN 平台服务的客户负有特殊责任。那些源站名称为 .de 的客户也受到了此次中断的影响。
Cloudflare 为源站解析运行着一个独立的内部解析器，与公开的 1.1.1.1 服务不同。为了减轻影响，我们在内部解析器服务上对 .de 应用了类似的 NTA 设置，恢复了受影响客户的源站连接。
扩展 DNS 错误（Extended DNS Errors）
在我们实施缓解之前，无法从缓存中获取响应的查询会从 1.1.1.1 收到 SERVFAIL 响应。每个 SERVFAIL 都包含一个扩展 DNS 错误（EDE）码，由 RFC 8914 定义，用于向客户端提供更详细的错误信息。
一些解析器返回 EDE 6（DNSSEC Bogus），并附带描述性消息，直接指向损坏的签名。这是正确的行为：
EDE: 6 (DNSSEC Bogus): RRSIG with malformed signature found for example.de/nsec3 (keytag=33834)而 1.1.1.1 返回的是 EDE 22（No Reachable Authority），表面上看像是上游域名服务器的连接问题，而非 DNSSEC 验证失败。
其原因是我们在将 DNSSEC EDE 码从信任链验证器向上传递的过程中存在一个缺陷。当验证器检测到无效签名时，会生成 DNSSEC Bogus EDE 码，但该码从未被插入到响应中。相反，解析器外层看到递归解析出现问题但无具体错误码，于是回退为报告“No Reachable Authority”。这掩盖了底层的 DNSSEC 问题。
我们已意识到这对 1.1.1.1 用户并不友好，将修复响应以正确暴露 DNSSEC 错误。
这是否意味着 DNSSEC 技术本身的失败？
DNS 是大多数互联网通信请求链中的关键部分。人们很容易因此得出结论：这次中断以及所采取的缓解措施意味着 DNSSEC 作为一项技术已经失败了。然而，任何被错误配置的技术都会给依赖它的用户带来风险。将重要的光纤电缆暴露在海底任由鲨鱼啃咬，并不能否定水下电缆在当今互联网通信中的重要作用；它仅仅说明我们有时未能妥善保护这些设施。同样的道理也适用于此次事件。DNSSEC 在确保我们能够信赖 DNS 响应、防止恶意行为者篡改方面发挥着至关重要的作用。
#HugOps
没有人希望发生严重事故。但不幸的是，任何大规模运营关键基础设施的人都可能遇到这类问题。当事故发生时，DNS 社区通常会彼此支持、携手应对。
此类事件也凸显了运营商之间建立关系的重要性。DNS 是一个去中心化的系统，没有任何单一组织能控制全部环节，其稳定运行依赖于注册机构、解析器运营商和更广泛社区之间的相互信任与畅通沟通。像 DNS-OARC 这样的论坛正是为此而存在：它们提供了共享的邮件列表和聊天室，使运营商在出现问题时能够跨越组织边界快速协调。
DENIC 已发布一篇关于此事件的简短博客文章，其中指出：“此次中断与一次例行的计划内密钥轮换有关。在此过程中生成并分发了无法验证的签名。作为预防措施，在确切的技术原因查明之前，未来的密钥轮换已被暂停。”
我们相信，待他们完成分析后，会有更多信息公布。
此次事件的启示
此次事件揭示了 DNS 层级结构的一个现实：当日顶级域（TLD）级别的注册机构出现故障时，该 TLD 下的所有域名都会同时受到影响，无论其托管位置或使用的解析器为何。这并非 DNSSEC 特有现象——如果某个 TLD 的域名服务器无法访问，也会产生相同后果。让全球 DNS 能够运作的层级结构，也正是导致顶层故障向下传播的原因。
对此并没有简单的解决方案。行业所能做的是在事故发生时迅速且一致地响应。在本次事件中，全球各地的解析器运营商在不到一小时内独立部署了负信任锚（Negative Trust Anchors），在 DENIC 修复区域数据的同时恢复了解析服务。尽管无法消除根本性的依赖关系，但成熟的运维实践、行业内的沟通渠道（如 DNS-OARC）以及“serve stale”等功能都能有效减轻影响。
我们也从中认识到自身可以改进的地方。我们将进一步优化扩展诊断信息（EDE）错误提示，以便更清晰地暴露 DNSSEC 错误。
我们期待 DENIC 发布事后分析报告，并感谢他们在整个过程中展现出的透明度。
如果你想了解更多关于 DNSSEC 如何工作的知识，请访问我们的页面：DNSSEC 是如何工作的？ 你也可以随时在 Cloudflare Radar 上查看实时 DNS 趋势和顶级域数据。
Cloudflare 的连接云可保护整个企业网络，帮助客户高效构建互联网规模的应用程序，加速任何网站或互联网应用，抵御 DDoS 攻击，阻止黑客入侵，并可在您迈向零信任架构的旅程中提供支持。
从任意设备访问 1.1.1.1，即可开始使用我们的免费应用程序，让您的互联网更快更安全。