摘要

  • DNSSEC 通过给缺失名称与记录类型两侧的有序边界签名，把否定答复变成了可以验证的证据。
  • NSEC3、Opt-Out 和验证缓存的复用，不只是协议调优；它们在信息披露、计算成本、委派保证和新名称生效时间之间重新分配责任。

设想一座档案馆，馆内每份现存文件都有可靠签名。这些签名能证明文件是真的，却不能证明管理员没有藏起你索要的那一份。要证明“没有”，还需要一份带签名且有固定顺序的目录，让缺口本身可见。

这正是 DNSSEC“经认证的不存在证明”所完成的概念转换。

普通 DNS 会在名称不存在时返回 NXDOMAIN，也会在名称存在、但所查询记录类型不存在时返回“无数据”。没有 DNSSEC 验证，这个否定结论的可信度取决于响应路径。路径上的攻击者甚至不必把用户引向错误地址；让服务从解析结果中消失，往往已经足够。

RFC 4034 让签名区域能够描述自己的空隙。NSEC 记录写明按区域规范顺序排列的下一个权威名称，并用位图列出当前名称拥有的记录类型。RFC 4035 则规定验证方式：如果查询名称落在两个已签名边界之间，这个区间就能证明精确名称不存在；如果名称存在，但位图中没有所需类型，证明的就是该类型不存在。名称错误还必须排除可能生成答案的通配符。

协议并没有为每一种可能的问题预制一条否定记录——可能的标签空间大得无法穷举。真正的证据是有序区间：两个已认证事实把一片空白夹在中间。

最初的证明暴露了太多

NSEC 的清晰也带来了另一项性质。每条记录都指向下一个权威名称，耐心的查询者就能沿链条走完区域。

这种“区域遍历”并不是解密 DNS 原本承诺保密的数据；DNS 名称本来就是为使用而发布的。但一份容易枚举的名单，仍可能暴露命名习惯、看似内部的服务标签，或一张过去需要付出更高成本才能拼出的侦察地图。验证者需要足够明确的边界，区域运营者却未必愿意交出一份明文索引。

RFC 5155 因此引入 NSEC3。链式结构仍在，但直接可读的名称被散列值取代。验证者仍能确认查询名称的散列落在一个已签名区间内；枚举者则必须离线猜测候选标签。

这增加了阻力，却没有创造秘密。常见 DNS 标签可以预测，也会出现在证书、日志和链接里。RFC 9276 对收益递减说得很清楚：增加散列迭代，会让权威服务器和验证器付出更多计算，却不会让容易猜到的名字变成机密。

Opt-Out 把规模成本写进证明

对拥有大量委派的区域而言，另一项成本来自未签名子区域。如果每个未签名委派都要有自己的 NSEC3 记录，签名和内存负担可能很高。NSEC3 的 Opt-Out 允许一个区间覆盖多个不安全委派，而不为每个委派单独生成散列记录。

节省是真实的，语义上的让步也是真实的。RFC 5155 明确指出，Opt-Out 区间不会断言其中某个不安全委派究竟存在还是不存在。其他权威数据仍然受到保护，但这条边界上的证明被有意缩窄。区域以更便宜、更快的委派变更，换取不再对每个未签名子区域作出同等强度的密码学声明。

因此，Opt-Out 是治理选择，不只是服务器选项。它决定运营者愿意为哪些“不存在”背书。RFC 9276 不建议小型区域使用 Opt-Out，只把它留给规模极大、变化频繁且签名委派比例很低的场景。

缓存里的空隙可以回答未来问题

RFC 8198 允许验证型解析器积极复用缓存中的 NSEC 或 NSEC3 区间。如果后续查询落在已经证明为空的区间内，解析器无需再次询问权威服务器，就能合成否定答复。

这样可以降低延迟和权威负载，减少泄露给上游的无效查询，也能吸收一部分随机标签拒绝服务流量。但缓存现在是在把一项已签名声明应用到未来问题上，其有效期就成为运营条件。

RFC 8198 指出，NSEC 或 NSEC3 的 TTL 与区域的否定缓存值共同决定新名称多久能开始工作。若团队刚发布一段覆盖面很大的“不存在”证明，随即创建新名称，一些验证器仍有权根据缓存回答“不存在”。协议没有出错；变更计划忽略了否定证据的有效窗口。

今天更强的实践反而更克制

RFC 9276 建议：不需要 NSEC3 特性时优先使用 NSEC；必须使用 NSEC3 时，额外迭代次数必须为零，并建议使用空盐值。额外迭代会把计算成本施加给所有验证方，放大 CPU 耗尽攻击风险，还可能导致互操作失败；静态盐值帮助有限，因为完整域名本身已经让计算按区域隔离。

参数变更后，RFC 还要求运营者用已知不存在的名称检查辅助权威服务器。这项测试很有价值：正向记录看起来完全健康时，否定证明链仍可能过期、不一致，或对某个实现而言计算过重。

这些 RFC 定义了机制和当前最佳实践，并不能证明某个未指明运营者的实际配置可靠。部署质量仍需在真实权威端与验证端测量。

来源