德国域名"断网"1.5小时：一次密钥轮换的代价

「DNSSEC 密钥轮换」这个听起来很安全的操作，怎么就让整个德国的网站集体消失了？

20:58 UTC，故障触发

5月5日，德国域名注册机构 DENIC 按计划执行 DNSSEC 密钥轮换。这个操作本意是提升安全性——定期更换密钥防止被破解。

但流程出了岔子。DENIC 用 Keytag 33834 的新密钥给区域数据签了名，却忘了在 DNSKEY 记录里公布这个公钥。

验证解析器拿到签名后找不到对应的公钥验证，直接把响应标记为「DNSSEC Bogus」并拒绝返回。相当于给所有 .de 域名盖了「此路不通」的章。

亚马逊德国站（amazon.de）、DHL 德国站（dhl.de）等头部网站相继无法访问，用户看到的只有 SERVFAIL 错误。

21:20 UTC，Cloudflare 紧急拆弹

Cloudflare 在 22 分钟后识别出问题根源。他们的应急方案很直接：在 1.1.1.1 公共解析器上临时禁用 DNSSEC 验证。

这相当于绕过了签名校验，让 .de 域名恢复解析。代价是这 1.5 小时内，用户访问这些域名时失去了 DNSSEC 的安全防护。

另一个选项是 Quad9 的 9.9.9.10 解析器——它默认不强制验证 DNSSEC，反而成了用户的临时避风港。

05:43 北京时间，官方承认

DENIC 在故障发生约 7 小时后发布推文，承认 DNS 服务中断，技术团队已介入。DNS 记录的全球同步预计需要 2 小时。

2 小时后，官方宣布修复完成。从触发到完全恢复，整个事件持续约 9 小时，其中用户感知的中断约 1.5 小时。

为什么这件事值得复盘

DNSSEC 的设计逻辑是「不信任就拒绝」，这本该是安全特性。但 DENIC 的案例暴露了一个系统性风险：密钥管理的单点失误可以瞬间放大为国家级服务中断。

Cloudflare 的应急操作也很有代表性——当安全机制本身成为故障源时，平台方需要在「安全」和「可用」之间做实时取舍。

更深层的问题是：全球互联网基础设施的韧性，很大程度上依赖少数几家解析服务商的应急能力。这次是他们反应够快，下次呢？

对了，DNSSEC 密钥轮换本应是自动化、零感知的流程。DENIC 这次手动操作失误，让人想起那句老话——最安全的系统，往往败在最不安全的环节：人。