摘要

  • RFC 9824 可以为不存在的名称返回 NOERROR 报头、空 Answer 区，以及带有 NXNAME 的签名 NSEC/NSEC3 证明。被认证的“不存在”断言位于正文，DNS 报头本身不受密码学保护。
  • 可选的 EDNS Compact Answers OK（CO）标志可以恢复 NXDOMAIN，但它逐跳生效。递归服务器必须把 CO 能力和缓存证据一起保存，并按下游查询者的能力决定呈现方式。
  • 紧凑回答相对其他在线签名否定形式减少证明材料和签名工作，却无法进行激进负缓存合成。验证、呈现、缓存、签名负载与应用效果必须分别留证。

变短的回答没有让工作消失

开篇是一个构造场景，不是已报道事件。它刻意从容量而非语义切入，因为技术迁移最容易把“每次回答更省”误写成“整个系统更省”。只有沿着查询实际走过的路径，才知道成本落在了哪里。

RFC 9824 定义 DNSSEC 的 Compact Denial of Existence。传统否定证明通常需要说明两件事：精确名称不存在，通配符也不能合成答案。在线签名模式下，这可能需要最多两个已签名 NSEC，或三个已签名 NSEC3。

紧凑回答换了一种表述。对于不存在且不匹配通配符的名称，权威服务器构造一个外形像 NODATA 的回答：报头 RCODE 为 NOERROR，Answer 区为空，一个匹配 QNAME 的最小覆盖 NSEC 或 NSEC3 位于 Authority 区并被签名。证明在逻辑上声称该名称存在，只是没有被询问的 RR 类型，因此只需一份否定材料。

RFC Editor 信息页与 IETF Datatracker把 RFC 9824 记为 2025 年 9 月发布的 Proposed Standard，并说明它更新 RFC 4034 与 RFC 4035。文档历史、引用来源和后续引用提供公开过程背景。这些记录不能证明任何具名产品或运营商已经实施。

NXNAME 让“空”变成可验证的断言

空 Answer 区并不等于名称不存在。名称可能存在，只是没有所询问的类型；也可能是 empty non-terminal——自身没有 RRset，但因存在后代名称而真实存在。单看稀疏的类型位图，无法把这些情况与不存在区分开。

RFC 9824 因而定义值为 128 的合成 Meta-TYPE NXNAME。在 NSEC 紧凑回答中，不存在名称的位图包含 RRSIG、NSEC 和 NXNAME；在 NSEC3 形式中，NXNAME 是唯一位。empty non-terminal 不带这个标记。决定性证据由“什么都没看到”变成“签名材料明确说不存在”。

IANA DNS Parameters 登记 NXNAME、CO 标志和 EDE 30。注册让实现共享编号，却不证明启用、验证、策略或结果。

NXNAME 也不是可供普通查询的区数据。它只应出现在紧凑否定证明的 NSEC/NSEC3 位图中。若 QTYPE 明确请求 NXNAME，服务器必须返回 FORMERR，可以附加 EDE 30 Invalid Query Type；递归服务器不得向上游转发，也不得发起迭代解析。RFC 8914 提供扩展 DNS 错误框架，RFC 9824 规定这一具体用途。

未受保护的报头不能推翻签名正文

RFC 9824 直接指出：DNS 报头没有密码学保护，因此 RCODE 无法被认证；从正文的签名数据推断状态更安全。这句话建立的不是 UI 偏好，而是证据等级。

很多安全工具和应用库仍主要消费 RCODE。它们看到 NOERROR，可能把回答归类为 NODATA；DNSSEC 验证器检查 RRSIG 与 NXNAME 后，却能认定名称不存在。两者都应记录观察点，不能让更容易建索引的字段自动取得更高权威。

RFC 4034 定义 NSEC、RRSIG 等 DNSSEC 记录，RFC 4035 规定协议处理与认证否定。RFC 9824 为动态紧凑形式加入例外。RFC 9364 给出 DNSSEC 概览，RFC 9499 固定 DNS 术语。任何一个规范都没有把未验证的 RCODE 快照变成签名事实。

最小收据应包含查询名称与类型、DO/CO 状态、收到的 RCODE、NSEC/NSEC3 形式、NXNAME 是否存在、公开算法和密钥标识、验证结果、软件版本、时间与证明指纹。私钥绝不能进入收据。

恢复 NXDOMAIN 是逐跳呈现决定

RFC 9824 要求在可行时尽量保留 NXDOMAIN。对 DNSSEC 交换，它定义可选但推荐的 EDNS Compact Answers OK 标志。递归服务器在查询中设置 CO，表示愿意接受带签名 NXNAME 且 RCODE 恢复为 NXDOMAIN 的紧凑回答；同时实现两项能力的权威服务器可以在响应中设置 CO 并给出该代码。

RFC 6891 所定义的 EDNS 信号逐跳生效。递归服务器必须把上游 CO 状态和相应缓存数据绑定。若下游 DNSSEC 查询者没有设置 CO，它需要把 NXNAME 回答的 RCODE 改回 NOERROR。

两个下游看到的签名证明没有变化，变化的是本地兼容策略。若缓存只保存 RRset 而遗失 CO，就失去了复现呈现决定的依据；若遥测只保存最后的 RCODE，就无法证明递归端是否验证过 NXNAME。

最小覆盖同时取消了更大范围的缓存权力

RFC 4470 是最小覆盖 NSEC 与在线签名的前置规范，RFC 5155 定义 NSEC3。RFC 9824 的紧凑形式相对更大的动态证明减少响应大小和在线签名次数，并限制有用的区枚举。

但它无法实现 RFC 8020 和 RFC 8198 所描述的 NXDOMAIN 或通配符合成。最小覆盖证明不能授权递归缓存替更大名称范围发言。伪随机子域名查询于是更可能继续到达权威服务器。

在线签名还意味着可从互联网抵达的权威基础设施需要接触私有签名能力，并为每份动态证明消耗计算。紧凑形式减少相对工作，不等同于预计算签名。RFC 9824 明确保留传统在线或预计算方式，供不需要其体积与计算优势的部署选择。

应用结果需要最后一个独立证人

地址查询库收到 AAAA 的 NODATA 外形回答后，可能继续查询 A；普通 NXDOMAIN 本可抑制第二次查询。stub 可能不请求 DNSSEC，安全工具可能忽略位图，递归服务器也可能按 CO 能力改变报头。因此验证正确并不自动等于应用行为符合预期。

运行代码优先要求按执行顺序观察：权威生成、签名、验证、NXNAME 解释、缓存写入、CO 判断、下游 RCODE、追加查询和应用结果。现实层次方法则防止任何一层冒充全部：NOERROR 不能推翻签名不存在，签名不存在也不能证明应用已经停止查询或正确呈现错误。

来源

  1. IETF Datatracker：RFC 9824
  2. RFC 9824 文档历史
  3. 引用 RFC 9824 的文档
  4. RFC 9824 引用资料
  5. Heng Lu：Minimum Initial Specification
  6. Heng Lu：Reality Layers
  7. Heng Lu：Running-Code Primacy
  8. IANA DNS Parameters
  9. RFC 9824 勘误
  10. RFC Editor 信息页
  11. RFC 4034
  12. RFC 4035
  13. RFC 4470
  14. RFC 5155
  15. RFC 6891
  16. RFC 8020
  17. RFC 8198
  18. RFC 8914
  19. RFC 9364
  20. RFC 9499
  21. RFC 9824