NSEC3 Opt-Out：有效证明不是完整委派名录

摘要

带 Opt-Out 标志的 NSEC3 区间可以覆盖真实存在的不安全委派，同时既不声称它存在，也不声称它不存在。遍历签名节点所得的是有边界的否认投影，不是父区数据库的认证副本。
父区运营者应分别保管源名录、签名生成结果、各权威节点的 NS/DS 回答和验证器判断。任何把“链中无节点”直接改写成“委派不存在”的系统，都越过了证明权限。

一次演练中，审计程序完整遍历某父区的 NSEC3 链，所有签名均有效，却找不到一个子名称的哈希节点。它据此把该委派标成“已删除”。运维人员直接向父区查询，却收到正常的 NS 转介，没有 DS。子区一直存在，只是尚未形成安全委派。

两份结果并不矛盾。矛盾来自程序擅自扩大了签名链的职责。

RFC 5155 规定，不安全委派的名称哈希可以被省略，只要相应位置落在带 Opt-Out 标志的 NSEC3 区间内。该区间明确不证明其中委派的存在或不存在。正因为没有作出这项声明，父区增删符合条件的委派时，可以不重算相邻链节点。

签名证明的是这项有限规则得到了遵守，而不是区间内部一片空白。

源名录记录委派名称、NS、必要的 glue、DS、变更时间和批准来源。签名器读取这些数据，再生成按哈希值排序的 NSEC3 链。链上每条记录携带算法、标志、迭代次数、盐、下一个哈希和类型位图，用于回答特定的存在或不存在问题。

如果父区有 NS 而没有 DS，这个子区是不安全委派；同时存在 NS 和 DS，则是安全委派。Opt-Out 的许可只针对前者及由其单独派生的某些空非终结点。安全委派、父区权威数据和其他必须表示的名称，不能为了缩短链而随意消失。

因此，每个未出现在链中的委派都需要一条反向证据：源名称是什么，NS/DS 状态为何使其符合条件，计算后的哈希落在哪个区间，覆盖记录是否带 Opt-Out，签名生成编号是什么，各权威服务器实际回答什么。

若只保存“DNSSEC 验证成功”，就无法区分合法省略、签名器错误和权威集群版本分裂。

常见盘点工具只提供“存在”和“不存在”两种结果。遇到 Opt-Out 区间时，必须增加第三种：仅凭此链无法判断。

要确认名称，系统可以读取获授权的源区数据或注册记录，也可以直接查询父区 NS 与 DS。NS 转介证明父区正在委派；DS 决定该委派是否通过父区进入 DNSSEC 信任链。NSEC3 节点集合不能替代这两类事实。

RFC 8198 对验证器也设置了同一道边界。验证器可以利用已验证的 NSEC/NSEC3 范围，在缓存中合成某些否定回答；但覆盖记录带有 Opt-Out 时，它没有证明名称不存在，因此不能跨过该区间进行激进否定缓存。

审计或安全产品若仍这样做，并不是比标准更谨慎，而是在制造一项从未获得签名的声明。

通配符和名称不存在证明依赖 closest encloser，即查询名称最长的已存在祖先。在 Opt-Out 区域内，被省略的委派或只因它而存在的空非终结点可能没有 NSEC3 节点。此时证明只能停在 closest provable encloser，也就是链能够证明存在的最长祖先。

这个差别必须进入证据。保存查询名称、完整 NSEC3 与 RRSIG、next-closer、匹配或覆盖关系、哈希空间回绕、类型位图和验证时间。一个绿色状态灯既看不出证明停在哪里，也看不出 Opt-Out 是否禁止了“不存在”结论。

RFC 9276 建议：如果不需要 NSEC3 的特性，优先使用 NSEC；确需使用 NSEC3 时，推荐算法 1、额外迭代为 0、空盐。

增加迭代会放大权威服务器和验证器的计算负担，并引入互操作风险。盐可以改变哈希，却不能让可猜测名称成为秘密。验证器可以按本地资源政策把超出支持范围的迭代视为不安全或返回 SERVFAIL；在验证相关记录后，还可以给出 EDE 27。这说明验证器拒绝了计算参数，不说明委派不存在。

小型区域不应使用 Opt-Out。对于规模巨大、以委派为主、绝大多数子区尚无 DS 的稀疏签名区域，Opt-Out 才可能有现实收益。运营者要记录规模、变更率、安全委派比例、签名成本与审计能力，而不是继承旧模板。

修改盐或迭代次数，需要重建完整 NSEC3 链并重新签名。验证器判断时使用所验证 NSEC3 中的参数；单独的 NSEC3PARAM 不是否认证明。

上线前，应核对源名录、旧新签名生成、序列号或代次、RRSIG 有效期以及每个从服务器的传送状态。探针至少覆盖一个确定不存在的名称、一个被省略的不安全委派、一个安全委派和一个通配符边界，并逐个查询所有重要权威地址。

若集群在计划窗口之外仍提供两代链，“服务器在线”不能消除分歧。决定者需要保留上一代一致区域，结合 TTL 与缓存中的旧证明，选择继续发布或回滚。