Jiayun's Blog

引言：当信任链的一环碎裂

2026 年 5 月 5 日，UTC 时间约 19:30，德国国家顶级域名 .de 的 DNSSEC 签名出现错误。在接下来的数小时内，全球所有启用 DNSSEC 验证的递归解析器——包括 Cloudflare 的 1.1.1.1、Google 的 8.8.8.8——对 .de 下属域名的查询开始大规模返回 SERVFAIL。

1700 万个域名，一夜之间对相当一部分互联网用户变得"不存在"。

这不是 DDoS 攻击，不是光缆中断，甚至不是服务器宕机。出问题的是一段密码学签名——几百字节的数据。负责运营 .de 的 DENIC 在发布 DNS 区域更新时，推送了不正确的 RRSIG 记录。对于不验证 DNSSEC 的解析器来说，一切如常；但对于遵守协议规范、执行严格验证的解析器来说，这些签名无法通过校验，协议要求的唯一正确行为就是：拒绝响应。

一个旨在保护互联网安全的机制，反过来成了瘫痪互联网可用性的原因。这个悖论，值得我们深入思考。

事件时间线

让我们先还原事故的完整经过：

整个事故持续约 6 小时。但在互联网基础设施的语境下，6 小时已经是一场灾难。

DNSSEC 的工作原理：理解信任链

要理解这次事故为何如此严重，我们需要先了解 DNSSEC（Domain Name System Security Extensions）的设计原理。

DNS 的原罪

传统 DNS 协议设计于 1980 年代，完全没有考虑安全性。DNS 查询和响应以明文传输，且没有任何机制验证响应数据的真实性。这意味着中间人可以轻松伪造 DNS 响应，将用户引导至恶意网站——这就是所谓的 DNS 缓存投毒攻击。2008 年 Dan Kaminsky 公开的攻击方法让整个行业意识到这个问题的严重性，直接推动了 DNSSEC 的大规模部署。

信任链的构建

DNSSEC 通过公钥密码学为 DNS 记录添加数字签名，构建一条从 DNS 根区（root zone）向下延伸的信任链（chain of trust）。这条链涉及几种关键记录类型：

• DNSKEY 记录：包含区域的公钥。每个启用 DNSSEC 的区域都有一对密钥：KSK（密钥签名密钥）和 ZSK（区域签名密钥）。
• RRSIG 记录：对区域中每一条 DNS 记录集（RRset）的数字签名，由 ZSK 的私钥生成。
• DS 记录：存放在父区域中，包含子区域 KSK 的哈希值，用于将信任从父区域传递到子区域。

一次完整的 DNSSEC 验证过程如下：

1
2
3
4
5

根区 (.) → 根区的 DNSKEY 签名 .de 的 DS 记录
    ↓
.de 区域 → .de 的 DNSKEY 签名 example.de 的 DS 记录
    ↓
example.de → example.de 的 DNSKEY 签名 www.example.de 的 A 记录

解析器从根区的信任锚点（trust anchor）开始，逐级验证每个环节的签名，任何一环验证失败，整个链条就断裂了。

这次事故中断裂的位置

在 .de 事故中，DENIC 发布了无法正确验证的 RRSIG 记录。这意味着信任链在 .de 这一级断裂。不是某一个域名受影响，而是整个 .de 下属的所有域名都无法通过验证。对于启用了验证的解析器来说，.de 下面的一切都变成了"不可信"的。

“验证即拒绝”：安全优先于可用性的设计哲学

这次事故最核心的技术争议在于 DNSSEC 的基本设计原则：fail closed（失败即关闭）。

RFC 4033-4035 定义的 DNSSEC 协议有一个明确的立场：当签名验证失败时，验证解析器必须将该响应视为伪造，返回 SERVFAIL 错误，而不是将未经验证的数据交给用户。

这个设计选择背后的逻辑很清晰：

如果在验证失败时仍然返回数据，那么攻击者只需要使签名失效（比如篡改签名），就能绕过 DNSSEC 的保护。整个机制将形同虚设。

换句话说，DNSSEC 选择了安全性优先于可用性。宁可让用户暂时无法访问网站，也不能让用户在不知情的情况下被引导到恶意网站。

但这次事故暴露了这个设计在实践中的残酷一面：当出错的不是攻击者，而是基础设施运营方自己时，“验证即拒绝"变成了"自己的错误惩罚自己的用户”。

验证 vs 非验证：两个平行的互联网

事故期间，互联网实际上分裂成了两个平行世界：

• 启用 DNSSEC 验证的解析器（Cloudflare 1.1.1.1、Google 8.8.8.8、大部分运营商解析器）：.de 域名全部不可达
• 未启用 DNSSEC 验证的解析器（部分老旧或配置简单的解析器）：一切正常

这创造了一个荒诞的局面——使用更安全、更现代基础设施的用户反而受到了更大的影响。

Cloudflare 在事后博客中详细记录了他们的 1.1.1.1 解析器在事故期间的行为。作为一个严格遵守 DNSSEC 协议的验证解析器，1.1.1.1 正确地拒绝了所有无法验证的 .de 响应。Cloudflare 强调，这是协议规定的正确行为——解析器不应该在验证失败时"降级"到非验证模式，因为这会给攻击者创造可利用的窗口。

但他们同时也承认，这种"正确"的行为在用户看来就是"你的 DNS 坏了"。

历史回顾：DNSSEC 事故并非首次

.de 事故不是 DNSSEC 首次造成大规模解析失败。回顾历史，类似事件反复发生：

2009 年的 .se 事件尤其值得关注。作为最早大规模部署 DNSSEC 的 ccTLD 之一，瑞典的 .se 因为 RRSIG 签名到期未更新，导致整个瑞典的域名解析出现问题。这是 DNSSEC 部署历史上第一个引起广泛关注的"自伤"事件。

17 年后，同样性质的事故再次发生在 .de 上。技术细节不同（签名过期 vs 签名错误），但根本问题相同：DNSSEC 的运营复杂性超过了很多组织的管理能力。

DNSSEC 的采用困境

根据 APNIC 的统计数据，截至 2026 年，全球 DNSSEC 验证率约为 30%——这意味着约三分之一的 DNS 查询经过了 DNSSEC 验证。这个数字在过去几年增长缓慢。

为什么？

部署复杂性

DNSSEC 的部署和运维要求极高：

• 密钥管理：需要定期轮转 ZSK（通常每 1-3 个月）和 KSK（通常每 1-2 年）
• 签名更新：RRSIG 有有效期限制，必须在过期前重新签名
• 父区协调：DS 记录的更新需要与父区域注册管理机构协调
• 监控告警：需要持续监控签名状态，任何疏忽都可能导致整个区域失效

不对称的风险收益

对于域名运营者来说，DNSSEC 的价值主张面临一个尴尬的不对称性：

• 收益：防止 DNS 缓存投毒攻击（这是一种真实但相对罕见的攻击向量）
• 风险：一旦运维出错，自己的域名对所有验证解析器变得不可达

每一次 DNSSEC 事故，都在强化那些持观望态度的运营者的判断：“这玩意儿风险太大，不值得部署”。这形成了一个恶性循环——采用率低导致生态系统不成熟，生态系统不成熟导致更容易出错，更容易出错导致采用率更低。

替代方案与技术演进

面对 DNSSEC 的困境，行业一直在探索替代和互补方案。

DoH 和 DoT：传输层加密

DNS over HTTPS (DoH) 和 DNS over TLS (DoT) 通过加密 DNS 查询的传输通道，防止中间人窃听和篡改。但需要注意的是：

• DoH/DoT 保护的是传输通道，不是数据本身
• 它们依赖对解析器的信任（你信任 1.1.1.1 或 8.8.8.8 不会给你返回虚假数据）
• DNSSEC 保护的是数据的真实性，与传输方式无关

两者解决的是不同层面的问题，理论上应该同时使用。但在实践中，DoH/DoT 的部署远比 DNSSEC 简单，用户体验也更透明，因此获得了更快的采用。

自动化密钥管理

.de 事故再次凸显了 DNSSEC 密钥和签名管理自动化的紧迫性。目前已有一些改进方向：

• CDS/CDNSKEY 记录（RFC 7344）：允许子区域自动向父区域传播 DS 记录更新，减少手动协调
• 多签名者模型（RFC 8901）：允许多个 DNS 提供商独立对同一区域签名，提供冗余
• 自动化签名平台：如 Cloudflare、AWS Route 53 等托管 DNS 服务已经实现了完全自动化的 DNSSEC 签名管理

但 TLD 级别的运营，如 DENIC 对 .de 的管理，涉及的规模和复杂度远超一般域名。1700 万个授权记录的区域文件签名，任何自动化系统都需要经过极其严格的测试。

需要一个"ACME 时刻"

回顾 HTTPS 的普及历程，一个关键转折点是 Let’s Encrypt 的出现。在 Let’s Encrypt 之前，SSL/TLS 证书的获取和部署是昂贵且繁琐的——与今天 DNSSEC 面临的处境何其相似。

Let’s Encrypt 通过 ACME 协议实现了证书签发的完全自动化，将部署成本降至零，将人为错误的可能性降至最低。HTTPS 的采用率从 2015 年的约 40% 飙升到今天的 95% 以上。

DNSSEC 需要同样的变革。具体来说：

1. 完全自动化的签名和密钥轮转：不应该有任何需要人工干预的环节
2. 自动化的健康检查和回滚：签名发布前应有自动验证，发现问题自动回滚
3. 简化的信任链管理：DS 记录的更新不应需要跨组织的手动协调
4. 标准化的故障恢复协议：当签名出错时，应有明确的自动恢复路径

也许我们需要一个"Let’s DNSSEC"——一个让 DNSSEC 部署变得像今天安装 SSL 证书一样简单的项目。

更深层的问题：互联网的脆弱性

退一步看，.de 事故揭示的不仅仅是 DNSSEC 的问题，而是互联网基础设施的一个根本性特征：系统性的单点脆弱性。

DNS 体系结构中，每个 TLD 都是其下所有域名的单点依赖。一个 TLD 的运营失误，影响的是该 TLD 下的所有域名。.de 有 1700 万个域名，.com 有超过 1.5 亿个。如果类似事故发生在 .com 上，后果将是灾难性的。

BGP 劫持、证书颁发错误、DNS 根服务器攻击……互联网的信任基础设施一直在各种"不太可能但后果严重"的风险之间走钢丝。DNSSEC 的 fail-closed 设计是正确的安全选择，但它把运维零容错的压力推到了 TLD 运营者身上。

结语

.de DNSSEC 事故是一面镜子，照出了互联网安全机制设计中安全性与可用性之间永恒的张力。

DNSSEC 的设计者做出了正确的选择：在不确定数据是否被篡改时，拒绝响应比返回可能有毒的数据更安全。但这个选择的代价是，任何签名错误——无论来自攻击者还是运营方自身——都会导致服务中断。

解决方案不是放弃 DNSSEC 或放松验证标准，而是让正确的事情变得更容易做到。自动化、标准化、简化——这些看似平凡的工程实践，才是保护互联网信任基础设施最有力的武器。

就像 Let’s Encrypt 证明的那样：当做正确的事情比做错误的事情更容易时，整个生态系统就会自然而然地走向正确的方向。

DNSSEC 正在等待它的"ACME 时刻"。希望在下一次 TLD 级别的签名事故发生之前，这个时刻能够到来。

参考资料

1. Cloudflare Blog. “When DNSSEC Goes Wrong: The .de TLD Outage.” https://blog.cloudflare.com/when-dnssec-goes-wrong-de-tld-outage
2. DENIC eG — .de 域名注册管理机构. https://www.denic.de
3. APNIC DNSSEC Validation Statistics. https://stats.labs.apnic.net/dnssec
4. RFC 4033 — DNS Security Introduction and Requirements
5. RFC 4034 — Resource Records for the DNS Security Extensions
6. RFC 4035 — Protocol Modifications for the DNS Security Extensions
7. ICANN DNSSEC Deployment Reports. https://www.icann.org/resources/pages/dnssec