摘要

  • RFC 8914 把 Extended DNS Error 放入 EDNS option 15：16 位 INFO-CODE 加可选 UTF-8 EXTRA-TEXT。它补充基础 RCODE，不取代 RCODE；接收方必须继续处理基础结果，也不必按 EDE 行动。
  • EDE 是一名解析参与者对自身观察的声明，不是端到端因果证明。转发器可以丢弃或重建它，UDP 空间不足时应先丢 EDE，未受保护的 DNS 交易还允许路径上的参与者更改它。
  • 安全使用的核心不是“认识代码”，而是保存诊断来自哪一跳、原始字节、RCODE、DNSSEC 轨迹、cache 与 upstream 状态、重试路径以及独立证据。任何自动降级都必须拥有比一个标签更高的证明门槛。

三个解析器，三个看似确定的答案

一次签名域名故障从用户端看只有 SERVFAIL。终端的本地解析器给出 EDE 6 “DNSSEC Bogus”；企业转发器记下 EDE 22 “No Reachable Authority”；公共递归服务则返回 EDE 23 “Network Error”。值班人员面对的不是三份真相，而是三个观测面。

本地解析器可能确实验证到了错误签名，也可能从上游继承了结论。企业转发器可能只有一次短暂超时。公共递归服务也许从另一个 anycast 节点成功访问 authority，却在自己的链路上失败。EDE 使每个观察更可读，但协议没有给其中任何一方颁发“根因裁判”资格。

这一区别决定了运营动作的安全边界。标签足以帮助分流 ticket、挑选 packet capture、联系适当团队；它不足以独自证明 authoritative operator 配错 DNSSEC、网络运营商阻断了流量，或客户端应切换到一个验证更弱的 resolver。

线上的格式很小，语义空间很大

RFC 8914 规定 EDE 使用 EDNS option code 15。option data 的前两个 octet 是 INFO-CODE，后面可带 UTF-8 EXTRA-TEXT。文本面向人类诊断，不应由程序解析成控制信号。一个响应可以带多个 EDE，也可以在 NOERROR 等任何 RCODE 上携带它们。

这种设计保留了扩展空间，也保留了基础 DNS 的决定权。客户端必须照常处理 RCODE；EDE 只能提供额外背景。接收端接受 option，并不意味着必须展示、记录，更不意味着按它改变安全策略。

IANA registry 提供共享词汇。RFC 8914 最初定义 0 至 24，包括 DNSSEC、缓存陈旧、策略禁止、过滤、网络和 authority 可达性等类别。注册表后来继续增加代码，并划分公开注册与私用范围。代码进入注册表，只说明号码与含义可以互操作，不证明某次发送方分类正确，也不证明所引用的机制具有同等成熟度。

来源链会在 forwarder 处断开

EDE 最容易被误读的地方，是界面只展示最后一个标签。实际部署往往是 stub、企业 forwarder、过滤层、递归 resolver、authoritative server 串联。RFC 8914 允许中间方丢弃收到的 EDE，或根据自己的处理创建新的 EDE；如果转发上游信息，文本应说明来源。

因此，“由 resolver 返回”仍不够精确。要问的是哪一个进程、哪一个 endpoint、哪一版软件、哪一次查询、哪一条上游路径、它是观察到还是继承了这项判断。若中间方重建 EDE 却不保留来源，调查者得到的是去掉 provenance 的结论。

传输保护只能缩小篡改面，不能替发送方担保诚实。普通 UDP/TCP DNS 中，路径上的参与者可能修改 option。受认证或加密的 hop 能证明这段会话中的对端，却不能证明对端对远端 authority 的归因正确。hop authentication 与 causal authority 是不同的问题。

当包太大，说明可能先消失

EDNS 由 RFC 6891 提供扩展 option 机制，但 UDP payload 仍有预算。RFC 8914 要求，当响应超出允许大小时，应先删除 EXTRA-TEXT，再删除整个 EDE，仍放不下才按 DNS 规则设置 TC。于是故障解释可能在拥塞、大响应或中间盒路径上消失，而基础 RCODE 保留下来。

这意味着 EDE 缺席不能证明发送方没有诊断，presence 也不能证明所有观察者看到同样内容。生产 canary 必须覆盖无 EDE、一个或多个 EDE、次序变化、未知代码、私用代码、空文本、过长文本、无效 UTF-8、UDP 删除、TC 后 TCP 重试，以及 forwarder 的保留、丢弃和重建行为。

EXTRA-TEXT 是证据，也是泄漏面

自由文本可以把“Blocked”解释成具体 policy，也可能意外写入账户号、内部 blocklist、客户名称、后端地址或尚未公开的安全判断。RFC 8914 明确指出隐私风险。显示层还要把控制字符、双向文本与无效编码当作不可信输入处理。

正确策略不是完全舍弃文本，而是分层保存：受控证据库保留原始 bytes 和严格访问记录；分析面使用安全解码版本；公开 dashboard 只显示经过最小披露处理的内容。保留期应与诊断价值相匹配，而不是因为文本“只是日志”便无限留存。

具体实现已经把 EDE 连接到真实 policy

Unbound 可启用 EDE、在 serve-expired 场景发出相应解释，并支持 RFC 9567 DNS Error Reporting。BIND 的 Response Policy Zone 可以把 forged、blocked、censored、filtered 或 prohibited 等 EDE 代码附着到 policy 结果。PowerDNS Recursor 也能发送 extended resolution errors，并为 Negative Trust Anchor 给出诊断信息。

这些能力证明 EDE 已进入 running code，也说明标签由本地决策产生。相同 wire code 在不同产品、版本、配置与 policy rule 中可能由不同证据触发。审计不能停在 RFC 名称，必须回到触发该代码的具体规则与运行版本。

RFC 8767 的 stale answer 进一步说明“解释”与“许可”需要分开。EDE 可以告诉客户端答案为何陈旧，但是否 serve stale、允许多旧、何时停止，仍是 resolver 的受限 policy。EDE 不应被倒过来当作允许陈旧数据的授权。

RESINFO 与 Report-Channel 扩大了可见性，也扩大了责任

RFC 9606 允许 resolver 通过 RESINFO 的 exterr 属性声明支持哪些 EDE code。这个声明便于能力发现，但如果 resolver 版本、anycast 节点或配置不一致，它也会制造错误的能力印象。选择如何使用这些信息仍是客户端本地决定。

RFC 9567 则把 QTYPE、QNAME 与 EDE 编入新的报告查询，让 authoritative operator 看到 validator 发现的问题。报告可以缩短修复时间，也可能形成递归通知、流量放大与隐私泄漏。规范因此要求限制成本和深度；报告通道本身没有相互认证。TCP 或 DNS Cookies 能提高来源可信度，却不能把报告内容变成已证明根因。

最小共同层应保持薄：共享 option、code registry 与基本处理规则。是否展示、保留多久、触发何种调查、是否发报告、怎样交叉验证，都应由本地运营者根据风险决定，并由 packet-level canary 证明实际部署行为。

资料来源