摘要

  • 恶意签名区域可以堆叠相同 key tag 的 DNSKEY 与多份 RRSIG，让验证器在判定失败前执行数量失衡的密码运算。
  • 有效修复不是放弃 DNSSEC，而是由每个解析器限制单次验证的工作量、保障其他查询继续运行，并记录限额触发情况。

报文很小，账单很大

DNSSEC 允许一个区域同时存在多把密钥和多份签名。这对密钥轮换、算法迁移和多签名者部署都很重要。RRSIG 中的 16 位 key tag 用来帮助寻找候选密钥，却不是唯一标识；不同 DNSKEY 完全可能拥有同一个 tag。

KeyTrap 把这种正常弹性变成不对称成本。攻击者控制一个签名区域，生成大量 tag 碰撞的密钥，再附上无法验证的候选签名。按既有逻辑勤勉尝试的验证器，会在宣布失败前遍历许多组合。发送方只传输有限数据，接收方却反复承担公钥运算。

这不是伪造。恶意数据没有因此获得 Secure 状态，攻击者也没有取得其他域名的权威，更没有击穿根信任链。攻击针对的是可用性。若为避开负载而长期关闭 DNSSEC，虽然省掉计算，也同时丢掉了数据源认证。

ATHENE 团队从 2023 年 11 月起向主要解析器开发者和运营商协调披露，厂商于 2024 年 2 月 13 日公开公告和修复。实验中，不同实现与配置出现从约一分钟到数小时的极端阻塞。这些是测试结果，不是所有生产解析器的统一停机预测。

三种实现，划出同一条边界

ISC 将 CVE-2023-50387 评为 High，确认经评估的 BIND 9 分支可被远程构造的响应拖入 CPU 耗尽，并建议升级到修复版本。公告同时表示披露时未知存在主动利用。漏洞能力不能被写成未经证实的现实事故。

Unbound 1.19.1 采用暂停机制：达到一定验证次数后，昂贵任务让出处理时间；其他工作得以继续；有限次数的恢复后，敌意查询最终失败。这说明调度本身就是安全边界。解析器不必为了完整回答一个问题而停止回答所有问题。

Cloudflare 为单个 RRset 和整次解析任务分别设置验证上限，增加超限错误与观测指标。其公开时间线显示，1.1.1.1 在 2023 年 12 月 8 日完成 KeyTrap 修复，内部 CDN 解析器在 2024 年 2 月 13 日完成 KeyTrap 及相关 NSEC3 问题的修复。

各家不需要采用同一个数字，却都承认同一项权限：区域发布者可以提交签名材料，但无权无限占用依赖方的 CPU、队列和时延预算。

正确流程也必须有成本上限

RFC 4034 定义 DNSSEC 资源记录，RFC 4035 描述验证行为。这些共同规则让认证可以互操作。但如果输入方能决定搜索空间，而协议不表达上限，“最终会得到正确答案”仍可能演变为不可用系统。

一份 2026 年的 Internet-Draft 讨论 DNS 上限值，明确记录与 DNSKEY、DS、RRSIG 相关的缺口。它证明问题仍在推进，不代表 IETF 已形成最终共识。

因此，这起事件长期对应的制度焦点是 IETF 标准进程。问题不再只是哪个厂商最先修补，而是哪些上限应进入共同协议契约，哪些资源决策必须继续由具体实现本地掌握。个人提交的草案并不等于 IETF 共识，运营者也不能用尚在推进的标准工作替代已经部署的工作量边界。

Heng Lu 的三项设计原则在这里形成清晰分工：最低初始规范保留共同密码学语义；未来决策本地化，让每套运行系统按自身架构管理验证成本；自愿采用则允许多种实现先以可测结果证明边界，而不是把某个厂商的调度器升级为唯一制度。

“已经启用”不是证据

可靠清单必须列出实现、精确版本、下游软件包来源、补丁证明和部署日期。“DNSSEC：是”无法说明 KeyTrap 路径是否仍然存在。

监控应拆分签名尝试次数、验证耗时、工作线程排队、缓存服务能力和超限失败。一份只显示平均查询时延的看板，可能看不到少数线程已被昂贵验证绑住。恶意区域测试要在隔离环境完成，同时确认普通缓存命中与非缓存查询仍可前进。

若实战中必须临时关闭验证，这应是一项单独的紧急决定：有责任人、有最小范围、有到期时间、有恢复证据。否则短期可用性例外会沉淀为长期信任降级。

证据边界

现有主源没有证明 KeyTrap 已在全球被利用，没有记录一次全球 DNS 中断，也没有给出所有易受影响解析器的完整比例。厂商发布补丁不等于每个发行版和私有机群同步升级。ATHENE 的测量不能外推到所有配置，宣传式最高级措辞也不能替代比较数据。

可以确认的结论更窄，也更重要：签名材料能够制造不对称验证成本。依赖方不仅有权决定是否相信结果，也必须有权决定为得出结果投入多少资源。

来源