多亏 DNSSEC，一个坏数据包就能让脆弱的 DNS 服务器宕机
新披露的 DNSSEC 标准“KeyTrap”漏洞允许单个精心构造的数据包耗尽验证型解析器的 CPU，直到打补丁前都可能让主要 DNS 软件下线。评论者认为，这暴露了 DNSSEC 更深层的设计问题——运维复杂度高、存在自我 DoS 风险、由于签名率低而现实收益有限，以及依赖中介进行密钥管理——尤其是在 HTTPS、DoH/DoT 和 CT 已经处理了大多数面向用户的安全需求的情况下。也有人反驳说，DNSSEC 对于解析器与权威服务器之间的篡改检测仍然重要，并且支撑了 DANE 等机制，但也承认其部署仍然不均衡且往往很脆弱。
漏洞范围
- 该攻击只影响进行 DNSSEC 验证的递归解析器，不影响普通的权威服务器。
- 利用漏洞（“KeyTrap”）滥用了 DNSSEC 中一个已有 20 多年的设计选择：验证器可能会在追踪和检查多个错误密钥/签名上花费无限时间。
- 所有主要验证器（BIND、Unbound、dnsmasq、PowerDNS 等）都受影响，因为它们遵循了该规范。
- 补丁大多是在验证工作量/时间上增加限制；从技术上说，这使实现变得不符合规范，凸显的是规范缺陷，而不是经典的内存漏洞。
DNSSEC 的设计与运维问题
- DNSSEC 设计于 1990 年代，当时基于加密成本高的假设而采用离线签名；有人认为这一架构选择是一个“原罪”。
- 密钥轮换和过期被描述为主要的采用阻碍：很容易把自己搞成 DoS，难以自动化；CDS/CDNSKEY 虽然有帮助，但支持并不好。
- 配置错误和损坏的区域会导致晦涩的故障（“Internet is broken”），使运营者在实践中关闭验证。
- 有人把 DNSSEC 称作“footgun”“infrastructure tax”，并建议将 DNSSEC 本身视为高严重性的负担。
安全价值 vs. WebPKI / DoH
- 支持 DNSSEC 的观点：
- 在解析器和权威服务器之间提供篡改检测；是“信任某个区域内容”的唯一方式。
- 使 DANE 以及基于 DNS 的 SSHFP/PGPKEY 验证等协议成为可能。
- 怀疑者的观点：
- DNSSEC 不提供隐私或加密；DoH/DoT/ODoH 能更有效地保护最后一公里，而且更容易部署。
- 对 Web 而言，TLS + CA + Certificate Transparency 已经处理了完整性问题；错误的 DNS 应答大多只会变成 DoS，而不是静默入侵。
- 存在 DNSSEC 降级/剥离攻击；验证主要发生在递归解析器中，而不是终端客户端。
采用情况与现实使用
- 据称，全球主要 TLD（.com、.net）的 DNSSEC 签名率非常低（大约只有几个百分点），而一些 ccTLD（.nl、.se、.ch）则高得多。
- 在解析器上测得的验证率据报全球约为 30–40%，但批评者指出这并不等同于端到端的客户端安全。
- 围绕许多域名由注册商代管 DNSSEC 是否算“有意义的”采用存在争论。
替代方案与未来方向
- 有人推广 DNSCurve 或 DNSCrypt，认为它们是带有正确传输安全的更好设计，但也承认 DoH 已经事实上“赢下”了那个细分领域。
- 一些人认为 DNSSEC 不太可能取代 WebPKI；浏览器中的 DANE 实验曾被尝试后又移除。
- 对更安全的新一代 DNS 实现（例如基于 Rust 的解析器）存在兴趣，但多位评论者强调，这个具体问题是协议设计问题，而不是内存安全问题。