摘要

  • RFC 9567 允许权威服务器在应答中主动携带 EDNS Report-Channel，公布一个错误报告代理。支持该机制的验证解析器随后把自己的 Extended DNS Error 观察写入一条独立 TXT 查询；原应答不会因此被修改或纠正。
  • 这条反馈有意保持有限：报告解析器与监测代理之间没有端到端认证，缓存会抑制重复，超长名称必须放弃，而 TCP 或 DNS Cookie 只能提高源地址可信度，不能证明诊断为真。

设想一台权威服务器仍在正常接收查询、正常发出 RRset，但其中一份 RRSIG 已经过期。服务器侧的请求量和成功发送率都可能没有异常。真正的失败发生在验证解析器完成链路检查之后。错误最清楚的观察者，恰好不是最有能力修复区域的人。

RFC 9567 没有建立一个中央告警平台，而是借用 DNS 自己打开返回路径。权威应答可以主动携带 EDNS 选项 18，并用完全限定域名指出监测代理。查询方无须预先请求这个选项，解析器也不得在查询中发送它。权威方拥有的是“把信号送到哪里”的选择，不是“必须报告什么”的命令权。

支持并启用报告的解析器若把失败归为某个 Extended DNS Error，就会新建一笔 DNS 事务。例如，对 broken.test 的 A 查询出现 EDE 7，可变成 _er.1.broken.test.7._er.a01.agent-domain.example，查询类型为 TXT。失败名称、原 QTYPE 与诊断码都在新的 QNAME 里。

因此，报告不是在原失败应答上补一段说明，也不会改变原 RCODE 的处理。它是送往另一个权威域的普通查询。RFC 9567 对 TXT 的 RDATA 不赋予业务含义；正面应答的主要价值，是让查询闭合并通过 TTL 抑制同一解析器的重复发送。

四个角色，四种不能互相代行的权力

原权威运营者决定是否公布代理域以及选择哪个域。验证解析器执行校验、选择 EDE 码，并依照自身策略决定是否报告。监测代理接收查询、评估来源、合并观察。区域运营者才有权修改签名、委派或数据。共享一个线格式，不会把这些权限熔成一个角色。

IANA DNS 参数注册表 证明选项 18 的名字是 Report-Channel，也为 TXT 用途登记了 _er。注册解决代码点与命名冲突，却不能证明某个实现支持、某个配置启用、某条报告抵达，更不能证明接收者判断正确。

EDE 也只是受限词汇。RFC 8914 明确，扩展错误信息不改变 RCODE 处理。RFC 9567 不规定什么一定算错误，也不要求每台解析器实现每个代码。代理收到的事实只能表述为：“这台解析器的处理过程把这个名称和类型归入该代码。”它不是全网故障宣判。

DNSSEC 验证规则 有时能让代理复现过期签名或 DS/DNSKEY 断裂，但解析器自己的旧信任锚也会制造失败。RFC 9567 特别指出，报告可能泄露解析器的本地配置错误。代理第一步应从独立视角重建验证链，而不是立即改区。

QNAME 是一只受尺寸约束的事故信封

报告名称依次放入 _er、十进制 QTYPE、失败名称的各标签、十进制 EDE 码、第二个 _er 与代理域。普通 RCODE 和 DNS 类别不在其中。第一个标记帮助代理确认收到完整报告，而不是 QNAME 最小化途中出现的前缀；第二个标记把事故内容和返回地址分开。

DNS 名称的 255 字节上限构成硬边界。生成后的 QNAME 若超限，解析器不得发送。解析代理域本身也可能失败并触发新的报告，所以解析器必须设置开销或递归深度上限。允许一条反馈丢失，胜过让一个故障制造无限报告。

代理域不得位于被报告域之下，否则原故障可能连返回路径一起切断。代理名称越短，原失败名称可用的空间越多。这不是命名美学，而是可达性和故障隔离。

证明地址可回访，不等于证明诊断正确

RFC 9567 没有在报告解析器与代理之间建立身份认证。UDP 源地址可以伪造，真实可达的解析器也可能判断错误。解析器应使用 DNS Cookie、DNS over TCP 或其他面向连接的传输。代理收到没有 Cookie 的 UDP 查询时，应设置 TC，要求对方用 TCP 重试。

这些手段只能回答狭窄问题：发送方是否足以在该地址完成一次更难伪造的往返。它们不能确认运营机构、客户身份、信任锚状态或 EDE 根因。已知大型解析器的地址可以获得更高来源等级，但不能凭一次查询获得修改生产 DNS 的权力。

因此自动化必须分层。无 Cookie 的 UDP 可以建立观察；完成 Cookie 或 TCP 往返的报告可以提高优先级；多个独立高可信解析器加上干净视角复现，才足以建立事故。修改区域仍需区域所有者的授权与回滚控制。

缓存既保护接收者，也制造沉默

代理应返回正面的 TXT 应答。TTL 让同一解析器不必为同一编码名称持续报告，这能限制额外开销，却也意味着报告条数不能换算成受影响用户或尝试次数。

NXDOMAIN 尤其危险。RFC 8020 允许把名称不存在扩展到其下层，而 RFC 2308 会缓存这项否定。一条错误 NXDOMAIN 就可能压住许多不同报告。RFC 9567 因而要求代理不得对监测范围返回 NXDOMAIN；通配正面记录是一种办法。

若代理域签名，RFC 8198 还允许解析器依据已验证的 NSEC 或 NSEC3 在本地合成否定应答，后续报告甚至不会出网。RFC 9567 提到，可让代理域不签名以避免这项额外负担，但解析器仍必须按正常规则验证应答，不能把真正已签名的受害域误降级为不安全域。

所以“没有新报告”存在多种解释：故障修好、TTL 尚未到期、否定被合成、代理不可达、解析器停止支持，或防滥用系统丢弃了流量。恢复必须用独立验证结果证明，不能用沉默证明。

返回通道也可能被反向利用

报告 QNAME 会向代理披露失败名称、类型与 EDE 码，也可能披露解析器自身的旧信任锚。QNAME 最小化能减少中间权威看到的信息，但最终代理必然得到完整事故名称。

攻击者还可以故意部署破损区域，把代理域指向受害者。开放解析器或全球分布式测量会把额外查询送向该目标。大量伪报告也能掩盖真实故障。代理需要速率限制、来源分级、代理与原区域的关系检查，以及独立验证数据。

TXT 应答内容同样不能被信任。RFC 9567 没有定义它，日志系统若照单全收就会承接恶意字符串。安全的代理可以返回固定值，只解析有界的 QNAME 字段。报告在查询中，而不是在远端返回的一段指令中。

Heng Lu 对运行代码优先、最小共同规范与本地决定以及现实层次的区分，正好适用于这条链。规范定义地址和语法；权威方公布；解析器观察；网络投递；代理判断；区域方修复；用户最终能否验证，是另一项事实。

完整审计要分别保留原应答、DNSSEC 状态、代理域、生成的报告名、放弃原因、传输与 Cookie、代理应答和 TTL、独立复现、修改记录与修改后验证。新的查询可以成为有用反馈，但不能冒充最终裁决。