摘要

  • NSEC 与 NSEC3 认证的是已签名 zone 内容中的具体否定命题。证明受到签名者、zone 边界、查询类型、TTL 和签名有效期约束。
  • Opt-Out 允许未配置 DS 的委派不进入各自的 NSEC3 链条。因此，验证者可以确认没有建立安全委派，却不能把覆盖区间解释成“其中所有名称都不存在”。

“不存在”的密码学含义很窄

递归解析器查询一个没有地址记录的标签。权威服务器可能返回 NXDOMAIN，也可能返回名称存在、但请求类型不存在的空数据回答。未签名 zone 的否定结果依赖权威服务器和传输路径；已签名 zone 则能携带 NSEC 或 NSEC3，让验证器沿信任链检查签名和否定证明。

这项保护非常重要。攻击者不能只把真实的正面回答替换成伪造的否定回答，就期待验证解析器接受。但 RFC 4035 的表述有一个不能省略的限定：经过认证的 NSEC 证明某个 RRset 不在“一个已签名 zone”中。

它不是对历史的全面搜索，也不是关于名称权利的裁决。一个标签可能从未注册，可能已经到期，可能被暂停，可能因供给系统故障而漏发，可能迁移了委派，也可能只是签名者发布了一份错误 zone。DNSSEC 能说明这份公开数据是否由可信密钥链签出，不能单独判断哪种原因成立。

NSEC 用有序关系构造证据

NSEC 把现有 owner name 按规范顺序连起来。每条记录指出下一个名称，并用 type bitmap 列出自身名称拥有的记录类型。经过签名的相邻区间可以证明两端之间没有另一个 owner name；bitmap 则可以证明名称存在，但查询的类型不存在。

因此，NXDOMAIN 与 NODATA 不是同一件事。前者否定名称，后者否定记录类型。empty non-terminal 自己可能没有 RRset，却仍然拥有更深的子名称。通配符还增加一道证明：系统不仅要排除完全匹配，有时还要排除更近的 wildcard 来源。

一个可靠的否定结果其实是一段小型论证。验证器要回答：哪个 zone 应该包含结果；哪个区间覆盖名称；哪个 bitmap 覆盖类型；是否存在 wildcard；签名是否在有效期内；DNSKEY 与 DS 是否一路连接到本地信任锚。

NSEC 的有序链也会暴露 zone 结构。持续查询可以逐步枚举名称。NSEC3 的一项动机正是降低这种直接披露。这个取舍提醒治理者：强可验证性有时会同时增加可观察性，隐私与审计并非天然同向。

NSEC3 让标签难读，却没有创造秘密

NSEC3 使用公开参数对名称做哈希，再为哈希值区间签名。解析器对 closest encloser、查询名称和 wildcard 候选重复计算，从区间关系中完成证明。

哈希阻止了直接阅读，却挡不住对可猜名称的离线试算。IANA 的 NSEC3 Hash Algorithms 登记目前只为 SHA-1 分配了编号 1。RFC 9276 因此反对用高迭代次数制造安全感：更多迭代会让权威签名与递归验证共同付出成本，却很难阻止现代硬件猜测常见标签。日常部署的指导是零迭代、空 salt；若无 zone enumeration 顾虑，则优先选择 NSEC。

这正符合最小共同机制原则。参数越大不代表制度越安全。应当问的是运行代码究竟增加了什么保护、把成本交给了谁、失败时能否诊断。

Opt-Out 刻意留下了未决定空间

大型父 zone 主要包含子委派。若每个没有 DS 的不安全子委派都必须拥有独立 NSEC3 和签名，zone 体积与签名成本会大幅增长。Opt-Out 允许某些不安全委派，以及由它们产生的 empty non-terminal，不进入 NSEC3 链。

这不是无关紧要的压缩。Opt-Out flag 改变证明语义。RFC 7129 明确指出：一条 Opt-Out NSEC3 记录不能证明或否定其区间内名称是否存在。验证器可以借它确认候选委派没有建立经过认证的 DS，并把后续路径视为 insecure；却不能把整个区间写成“名称不存在”。

若监控平台只留下绿色的“authenticated”标签，再写入 name_absent=true，就会把有限证明升级成错误事实。正确事件应保留覆盖区间、Opt-Out 标志、DS 缺席、潜在不安全委派与验证器最终状态。

事故处置时，这一区别直接影响归因。一个有争议的 child 可能没有 DS，却仍然在运行并位于 Opt-Out 区间。父 zone 的签名证明不能回答注册局是否有意发布、所有权威实例是否一致，也不能回答供给交易应否撤销。

缓存可以代表权威回答

RFC 2308 定义 negative caching。RFC 8020 允许解析器把一个已接受的 NXDOMAIN 作为切点，暂时将其子树视为不可达。RFC 8198 又允许验证解析器使用缓存中的 NSEC/NSEC3 区间直接合成新的否定回答，而不再次询问权威服务器。

这能降低延迟、权威负载和重复查询产生的隐私泄露，却也把解析器变成证据保管者。用户在某一时刻收到的否定结果，可能来自仍在 TTL 与签名有效期内的旧证明。即使权威 zone 已更新，这份缓存回答仍可能符合协议。

所以审计不能只保存截图。需要记录查询名称与类型、response code、权威 zone、证明记录、closest encloser、wildcard 判断、Opt-Out、收到时间、TTL、签名起止时间、信任链，以及回答是新鲜权威结果还是本地合成。

签名否定不是删除命令

注册局或注册商控制注册交易；权威 DNS 运营者控制 zone 发布；注册人可能拥有合同权利；争议机构或法院只控制被授予的救济；递归解析器控制自己的缓存与验证政策。这些角色不会因一份 NSEC 证明而合并。

否定证明不说明删除是否有授权，不说明通知是否送达、付款是否逾期、资格是否终止、申诉是否完结。它不授权第三人获得标签，也不让 zone signer 成为名称权利的所有者。

完整责任链至少要连接四种对象：注册或资格记录、经过授权的供给决策、已签名 zone 版本、验证解析器的外部观察。公开 zone 是运行现实；其他记录解释它如何形成、是否正当、应当如何纠正。把四者折叠成一个“DNSSEC 已证明”字段，只会让技术证据替制度背书。

薄的共同账本

按照 Heng Lu 的最小层原则，互联网共同层只需要让参与者区分 validated data、validated absence、insecure delegation 与 bogus evidence。它不需要成为全球名称资格法庭。

决定技术结果的是运行代码：zone cut、DS/DNSKEY 链、NSEC/NSEC3 参数、覆盖区间、Opt-Out、wildcard、TTL、签名窗口与解析器政策。政策文件不能让坏证明变好；好签名也不能让私人政策变成主权命令。

因此，最耐久的表述应保持狭窄：DNSSEC 能在限定时间和规则下，认证某个已签名 zone 没有包含什么。为什么缺席、谁应获得名称，仍是另外的证据与决定。

来源