摘要

  • DNSOP 于 9 月 2 日启动 draft-farrokhi-dnsop-ede-nta-01 工作组采纳征集，9 月 16 日结束。当前文件仍是个人 Internet-Draft，尚无采纳结论，也不是 RFC。
  • EDE 33 表明生成响应时存在一项覆盖该名称的 NTA。草案明确允许解析器在 NTA 并未实质影响响应内容时也携带该代码。
  • 运营者可另存一份受隐私约束的“效果记录”，把 EDE 来源、链路保护状态和同期无 NTA 验证结果连接起来；若未做反事实测试，就应直接记录“未测量”。

编号已分配，程序仍未结束

DNSOP 的采纳征集提出一个有限问题：工作组是否愿意接手这份关于负信任锚响应内披露的文件。征集从 9 月 2 日持续到 16 日。Datatracker目前仍标示 Call For Adoption By WG Issued。01 版的预期状态是 Informational，但它还是个人草案，并没有成为 RFC 或 IETF 已完成的决定。

另一条轨道已经前进。IANA DNS 参数注册表把扩展 DNS 错误码 33 列为 Negative Trust Anchor。这个公共编号使实现不必各自占用不同的数值。它没有替主席宣布征集结果，也没有冻结草案文字，更没有证明哪些解析器已经部署。

协议治理经常同时保留这些状态。IANA 管编号，工作组决定是否负责文件，RFC 出版是后续状态，实际运行又由实现和运营者决定。把它们写成一条“标准已经生效”的新闻，会丢掉真正的责任边界。

NTA 改的是本地验证路径

RFC 7646把 NTA 定义为验证型递归解析器的本地行为。解析器从选定名称处停止普通 DNSSEC 认证链，把覆盖范围内的响应当作未签名数据处理。它不会修复权威区，不会更改父区委派，也不会因此获得该域名的数据控制权。

这种例外之所以能恢复可达性，是因为解析器暂停了一项安全拒绝。RFC 因而规定它不能自动启用。受过训练的技术人员应辨别更像配置错误还是攻击，排除故意损坏的测试域，并合理尝试联系区域运营者。范围要窄，验证要周期性重试，配置要自动到期，期限不应超过一周；验证恢复后应尽快移除 NTA，并清理其节点以下缓存。

这些字段属于启用、审批、到期与移除的生命周期。BTW 既有文章已经讨论这一层。本文不再制作同一张台账，而是追问下一层：客户端从一条带有 33 的响应中究竟知道了什么。

“被覆盖”与“被改变”是两个命题

草案 01 版说，一项或多项 EDE 33 表示响应生成时有覆盖该名称的 NTA 生效。这个选项仅供诊断，不改变 AD 位处理；纯权威服务器也不应发送它来暗示自己执行了验证例外。

草案建议应用 NTA 的运营者在受影响响应中返回 EDE 33。紧接着，它允许解析器在 NTA 生效期间把该代码加入任何响应，无论 NTA 是否对内容产生实质影响。

例如，同一项 NTA 下有两个查询。第一个名称在普通验证中会失败，只有暂停验证才能返回数据；第二个名称即使不启用 NTA 也能验证成功。两条响应都可能显示 33。前者的结果受例外改变，后者只是处在同一环境里。代码没有保存另一条验证路径的结果。

这项选择有合理性。如果每个响应都必须同步跑一遍“有 NTA”和“无 NTA”验证才能披露，简单诊断会变成昂贵的双轨系统。草案把存在状态说清楚，同时把因果判断留给另一个证据面。

d 和 t 也不是完整证明

EDE 的 EXTRA-TEXT 可以承载配置名称、原因、参考链接或预计时长。结合结构化错误机制，草案为这类响应使用 d 表示 NTA 配置所在域名，用 t 表示它可能保持到的估计时间。

这些内容都是有限的。d 可以说明覆盖点，仍不能说明这条响应是否依赖例外。t 是预期，不是实际移除事件。人类可读的原因不是审批人及其授权证明。若多项 NTA 同时适用，响应可以携带多个 33；届时每项都要有文本，但候选清单仍没有回答哪一项改变了结果。

RFC 8914还划出传输边界。EDE 是补充诊断，不得改变 DNS 协议处理；普通情况下它没有内建认证。转发器可以删除、转送或重新生成 EDE，最好在 EXTRA-TEXT 标注来源，因为客户端看到的最后一跳可能看起来像原始发言者。

因此，严谨表述应是：“应答系统声称，生成此响应时有 NTA 覆盖它。”这不等于权威区确有配置错误，不等于启用决定正确，不等于响应因它改变，也不等于 NTA 现在仍在。没有 33 也不是反证，因为发送只是 SHOULD，中间设备还可能丢弃选项。

自动修复改写了演示现场

采纳讨论提供了一个恰好说明问题的现场。01 版用一条故意伪造的子区安全委派来展示 EDE 33。共同作者 Joe Abley 在 9 月 2 日回复中主动提醒，Cloudflare 的默认自动化不断修复委派或移除区切点，所以当时的线上配置已不再符合草案想展示的状态；作者会修正示例。

这不能被写成服务中断、解析器事故或永久性草案错误。它只证明一件事：说明文字与运行环境有不同的更新时间。静态版本仍在，自动化却把原来的反事实条件修走了。若只看 NTA 存在信号，就无法重建当时关闭 NTA 后会发生什么。

更早的实现讨论也展示过一条真实 EDE 33 响应。仅凭响应，观察者不知道 NTA 配置在查询名称、上级节点还是多处，也不知道不用它是否照样验证成功。信号在自身范围内真实，超出范围就保持沉默。

把效果留在另一个受控记录中

不应为了填补空白，把客户端地址、查询历史、内部工单和敏感故障细节塞进 EXTRA-TEXT。更小的做法是一份独立的 NTA 效果记录。这是 Daniel Kade 的编辑建议，不是 IETF、IANA 或运营者的要求。

对抽样响应或一次事故观察，它可以连接：时间与响应指纹；发出 EDE 的解析器或转发器角色；来源归属；观测链路是否受保护；收到的 33 以及 d、t；AD 状态；在隔离测试路径关闭 NTA 后的同期验证结果，或者带理由的“未测量”；返回数据或结果是否不同；以及指向独立审批和到期记录的引用。

它不要求复制每一条用户查询。运营者可以抽样、在安全环境重现，也可以保留反事实缺失。公共报告只需发布效果类别的汇总，具体域名和用户证据可按风险受控保存。“不知道”比把共同出现写成因果更可靠。

Heng Lu 的 The Policy Mirror要求把参与者、规则和证据分开。这里，IANA 管代码索引，IETF 流程管文档状态，解析器运营者管 NTA，一条具体链路传递诊断。Running Code Primary进一步要求让真实系统的观测约束制度表达，而不是让草案意图代替运行结果。

EDE 33 的价值不是解释一切，而是诚实显示一个过去隐形的例外。它能证明“有”，不能单独证明“改变了”。

来源

  1. DNSOP 工作组采纳征集
  2. IETF Datatracker 当前记录
  3. DNS 响应中的 NTA 披露草案 01 版
  4. Datatracker 文档历史
  5. Joe Abley 对示例状态的说明
  6. 实现边界讨论
  7. RFC 7646 — DNSSEC Negative Trust Anchors
  8. RFC 8914 — Extended DNS Errors
  9. IANA DNS 参数
  10. DNSOP 工作组记录
  11. Heng Lu — The Policy Mirror
  12. Heng Lu — Running Code Primary