加载失败
DENIC eG（德国 .de 国别顶级域名 ccTLD 的注册局）这次把一份错误的 DNSSEC 签名发布到了 .de 区里，导致验证型 resolver 在校验 RRSIG 时失败并返回 SERVFAIL。Cloudflare 的 1.1.1.1 等公共 resolver 因此临时按 RFC 7646 停止对 .de 的 DNSSEC 验证，以便域名继续解析。因为 DNS 有缓存、anycast 和不同 resolver 行为差异，用户看到的现象并不一致：有些域名还能访问，有些很快全挂。讨论还顺带牵扯到 DNSSEC 的 key rollover、NSEC3、TLD 级单点故障，以及安全和可用性究竟该怎么取舍。
不少人先把问题定位到 DENIC 发布了错误的 DNSSEC 签名，而不是 nameserver 整体宕机。具体看起来是 NSEC3/RRSIG 之类的签名与 ZSK 不匹配，导致验证型 resolver 直接返回 SERVFAIL。由于 anycast 还会让部分节点继续吐出旧签名，重试时就会出现“有时能通、有时不能”的假象。很多评论把这更像一次 botched key rollover 或维护失误，而不是单纯的网络中断。
[来源1] [来源2] [来源3] [来源4] [来源5] [来源6]
用户体感非常不一致：同一个 .de 域名，有的人能打开，有的人直接报错，还有人发现 Chrome 和 Firefox 表现不同。评论里反复提到，这取决于是否命中缓存、上游 resolver 是否启用 DNSSEC 验证，以及缓存里的旧记录还能撑多久。只要 TTL 没过，部分站点就还能“苟住”；一旦缓存耗尽，故障会从局部变成普遍。很多人因此先怀疑自己家里的 unbound、Pi-hole 或注册商配置，而不是 TLD 本身。
[来源1] [来源2] [来源3] [来源4] [来源5] [来源6] [来源7]
批评者认为 DNSSEC 把原本可缓存、可回退的 DNS 变成了 fail-closed 系统，一处签名错误就能把大量域名踢出互联网。还有人拿 HTTP/HTTPS、TLS 的历史对比，认为安全协议越复杂，越容易被运维失误击穿。DNSSEC 的低 adoption 也被多次提起，很多域名根本没签，使用它更像是勾 compliance 的盒子，而不是实际安全刚需。Cloudflare 直接停掉 .de 验证，更让人怀疑把验证交给第三方公共 resolver 是否真有意义。
[来源1] [来源2] [来源3] [来源4] [来源5] [来源6] [来源7]
另一派认为，这次事故说明的是 DENIC 的签名流程出了错，不是 DNSSEC 这个机制本身“有罪”。DNS 本来就是分层和单一权威的，`.de` 作为 ccTLD 由一个组织管理，这种中心化并不是 DNSSEC 才引入的。DNSSEC 反而让第三方缓存 resolver 也能在验证后返回可信答案，而不是每次都必须直接信任 authoritative server。至于 Cloudflare 停验，评论里强调如果你的安全模型依赖 DNSSEC，就应该做本地验证，而不是把最终决定权交给公共 resolver；DANE 之类方案也正是建立在 DNSSEC 之上。
[来源1] [来源2] [来源3] [来源4] [来源5] [来源6] [来源7]
很多评论把焦点放在基础设施韧性上，认为 TLD、DNS 和 BGP 这种层级都应该有跨 AS、跨地区的冗余。有人分享了自己用低成本 VPS、BIND、PowerDNS 和 WireGuard mesh 做多点 slave 的方案，强调这个级别的冗余并不昂贵。也有人提到 zonemaster 的单 AS 告警、灾难恢复演练、以及关键基础设施法规，主张这种系统不能只靠“不会出错”的假设。更悲观的声音则担心，任何更上层的中心化点出问题，都会触发连锁故障。
[来源1] [来源2] [来源3] [来源4] [来源5] [来源6] [来源7] [来源8]
不少站长和运维第一反应都是先怀疑自己，花了大量时间排查 unbound、Pi-hole、注册商迁移和本地 DNS。等确认是 .de 整体异常后，讨论迅速变成德国式黑色幽默：派对、Feiertag、传真审批、谁来背锅、以及“德国互联网下班了”。但这并不只是玩笑，评论里也提到 on-call 压力、邮件和监控受影响、还有客户短时间内无法访问服务的焦虑。有人甚至担心 postmortem 会拖很久，透明度也未必足够。
[来源1] [来源2] [来源3] [来源4] [来源5] [来源6] [来源7] [来源8]
DNSSEC: DNS Security Extensions，用签名验证 DNS 回答的真实性与完整性。
RRSIG: DNS 资源记录签名，用来证明某组 DNS 记录没有被篡改。
NSEC3: DNSSEC 中用于证明某名字不存在的记录，常用于加密化的否定应答。
ZSK/KSK: Zone Signing Key / Key Signing Key；前者签区内记录，后者签 DNSKEY 和信任链。
anycast: 同一个 IP 由多个节点同时宣布，流量会被路由到最近或可达的节点。
SERVFAIL: DNS resolver 的通用失败响应，常见于验证失败或上游异常。
TTL: 缓存存活时间，决定 DNS 记录多久后会重新暴露给 resolver。
DANE: 利用 DNSSEC 发布 TLSA 等信息，让 TLS 信任部分依赖 DNS。