摘要
draft-ietf-dnsop-dry-run-dnssec-01设计了一种过渡状态：支持该机制的解析器验证已签名区域并报告异常；若试运行验证为 bogus，普通客户端收到的仍是未启用该 DS 时的非安全答案。- 草案提出的 NOERROR 报告能证明某个参与解析器完成过一次成功检查，却不能给沉默解析器与其背后的客户端提供分母。RFC 9567 的报告会被缓存抑制，也不认证报告者身份。
- 父区把试运行 DS 换成真实 DS 之前，应保存一份 DNSSEC 转正收据，分别记录解析器样本、客户端探测、父区状态、传输可信度、登记表状态与未知范围。这是 Daniel Kade 的治理建议，不是 IETF 规范要求。
DNSSEC 上线最危险的动作发生在子区之外。父区尚未发布 DS 时，运营者可以检查签名而不建立公开信任链；真实 DS 一旦出现，同一处签名错误就可能在互不受控的递归解析器上变成 SERVFAIL。配置变化只有一条记录，后果却沿着父区、缓存、解析器和客户端分散开来。
DNSOP 正在推进的 dry-run DNSSEC 草案试图在“已经签名”与“正式执行”之间插入一个可观察的台阶。第 01 版发布于 2026 年 6 月 21 日。文件正文以 Standards Track 为目标，Datatracker 也把它列为活跃的工作组 Internet-Draft；但它还不是 RFC，不是已批准标准，更不证明任何具名解析器、注册局或域名已经部署。草案中的 EDE 与 EDNS 代码仍待确定。
它利用 RFC 6840 对未知 DS 摘要算法的处理规则。验证器会忽略自己无法使用的已认证 DS；若没有剩余的可支持认证路径，就把子区视作未签名。草案拟用摘要算法值的最高位映射出一组试运行类型，并要求父区同一 DS RRset 内全部采用试运行值。若把普通 DS 与试运行 DS 混在一起，支持者也会忽略试运行项，继续按普通 DS 验证。
于是，两类解析器面对同一父区状态会形成不同经验。不支持草案的解析器把陌生算法当作未知值，按未签名子区解析，也不会发送试运行报告。支持草案的解析器识别信号，验证子区；成功时可以标记认证数据，失败时则保存 bogus 结果并向监测端报告，却不把通常的 DNSSEC 失败交给普通客户端，而是退回到没有试运行 DS 时可获得的非安全答案。
这种 fail-open 是实验条件，不是较弱版本的 DNSSEC 保护。草案明确说，试运行委派尚不能视为 DNSSEC 已签名；安全章节进一步指出，非安全回退会关闭数据完整性保证，使伪造答案有机会影响区域。它用一段未执行保护的时间换取生产路径的可见性，因此只能是中间态，不能因仪表盘安静而长期保留。
报告把故障显影，却没有立即执行故障
RFC 8914 的扩展 DNS 错误为失败原因提供代码，RFC 9567 则规定如何把错误送往权威服务器所公布的监测代理域。解析器构造一条 DNS 查询，把出错 QNAME、QTYPE 和 EDE 代码编码在报告名称中。
这类证据优于实验室单测，因为它来自真实解析路径：实际验证软件、缓存状态和查询行为都参与其中。一条报告可以支持一个窄而有用的判断——某条报告路径曾在某时观察到某类错误。
它不能证明报告者的制度身份。RFC 9567 并不让解析器向监测代理完成身份认证。TCP 或 DNS Cookie 会提高伪造源地址的难度，却不会把 IP 地址变成经过认证的组织。UDP 报告及其表面来源可能是假的。报告还会暴露解析器自身的配置问题，例如陈旧的信任锚，所以规范建议采用查询名最小化以控制隐私泄露。
报告数量也不是原始事件量。缓存会抑制重复发送；构造后的名称过长便无法发出；监测代理不可达时，观察自然消失。仪表盘看到的是被传输条件、缓存和实现行为共同塑形的样本，而不是失败查询、独立解析器或受影响用户的普查。
NOERROR 只补上“有人在场”这一格
零错误至少有五种解释：区域确实正确；没有支持试运行的解析器来访；支持者没有收到查询；同类报告已被缓存抑制；监测代理不可达。只看错误曲线，无法区分这些情况。
第 01 版因此提出 NOERROR 报告。支持者成功验证试运行区域后，可以用区域顶点构造正向报告，同样借助缓存限制频率。运营者由此知道至少有一个参与者在场，而且它完成过一次成功检查。
这项信号缩小了样本内部的歧义，却没有创造样本外的分母。不支持草案的解析器按设计保持沉默；支持却没有承载相关查询的解析器也不会出现；一份 NOERROR 更不能列出该解析器背后的全部终端、后续路由与缓存状态。NOERROR 与错误报告的比例描述的是可见队列，不是互联网的总体成功率。
草案提到 DMARC 报告、RFC 8509 的根密钥信任锚哨兵和 RFC 8145 的信任锚知识信号。这些先例说明，规模不大但位置关键、时间足够新的观察者群体可以提供很强的运营信号。它们没有证明小样本会自动成为全网代表。
Wet-Run 把接受失败的选择交给特定客户端
普通客户端在试运行中得到回退答案，因此解析器报告并没有检验应用在真实 DNSSEC 拒绝面前会怎样。草案另拟 Wet-Run EDNS 选项：客户端显式加入后，支持它的解析器把试运行验证的真实错误返回给该客户端。解析器必须在缓存答案旁保留普通状态与试运行状态，并在失败响应中回显选项；不支持的解析器会忽略它。
Wet-Run 验证的是一条明确的应用—网络—解析器路径。它不能代表未加入的客户端，也不能由解析器侧的 NOERROR 代替。把两者都压缩成“测试通过”，会同时抹去谁同意承受故障、谁真正参与验证以及哪条路径被覆盖。
否定答案还要单独处理。RFC 8198 允许验证器用已缓存的 NSEC 或 NSEC3 证明主动合成响应，提高效率，却可能遮住权威服务器上损坏的否定证明。草案要求支持者暂停合成，显式查询权威端、比较答案，并用拟议 EDE 代码报告差异。因此，只测成功的正向查询并不足以决定转正。
父区握有转正开关
子区完成签名不等于试运行已经开始。父区必须接受并公布特殊 DS。若父区接口直接接收 DS，子区提交试运行值；若父区从 DNSKEY 生成 DS，就需要额外的模式开关，或依据同时出现的 CDS 推断。CDNSKEY 自身无法携带这项区分，草案建议 CDS 与 CDNSKEY 一并发布。
转正仍然是父区动作：把整组试运行 DS 替换为真实 DS。这里至少有四个不同事实——子区提交请求、父区接受请求、权威数据出现新值、旧缓存退出。只记录“已提交”会把控制面意图误当成互联网已经观察到的状态。
替换发生后，解析器与用户之间的契约改变了。演练期间，bogus 状态触发遥测，普通用户获得非安全答案；真实 DS 生效后，同一错误会被支持对应算法的验证器强制拦截。是否达到阈值不是单纯监控偏好，而是在授权外部解析器从何时开始执行子区的密码学声明。
拟议信号仍需与现行登记表对齐
第 01 版建议用 DS 摘要值的最高有效位，把 128 至 255 标记为 Dry-run DNSSEC。IANA 当前登记表并没有完成这项分配。登记表于 2026 年 1 月 13 日更新，按 RFC 9904 把 128–252 列为 Reserved、253–254 列为 Private Use，255 列为 Unassigned。
若草案继续推进，这两种状态需要显式协调。现状不是 IANA 已拒绝方案的证据：Internet-Draft 写下的 IANA 请求通常要在规范获批后才生效。但在那之前，实验也不能把整段拟议编号描述成公共已分配空间。
RFC 9904 还把“建议使用”和“建议实现”拆成不同登记列。软件具有能力，不等于运营者正在启用；同理，解析器实现试运行、实际查询这个区域、覆盖关键用户路径是三件不同的事。治理记录若只写“支持”，就会再次把能力冒充部署。
一份可追溯的 DNSSEC 转正收据
收据首先应绑定精确制品：签名区域指纹、DNSKEY 集合、拟用试运行 DS、父区请求、父区接受与外部观察到的发布状态。观察窗口、权威节点与缓存边界分别记录，不能只留一枚“完成”时间戳。
其次，收据要说明队列，而不是暗示普查。哪些解析器有独立证据可区分？哪些只有经 TCP 或 Cookie 稍加增强的来源地址？在缓存抑制后收到多少 NOERROR 与错误？涉及哪些名称、查询类型与代码？每个故障如何修正、复测和关闭？隐私聚合可以隐藏个人，却不应删除授权所需的证据结构。
客户端测试另立章节：按网络、解析器和应用类型保存 Wet-Run；比较普通回退；覆盖正向与否定答案；验证 NSEC/NSEC3 显式查询；注明缓存时界以及触达不了的人群。附上当时的 IANA 登记快照，并把实验代码清楚标作未分配。
最后，收据必须写明谁有权要求父区换成真实 DS、他接受了什么最小证据、哪些未知仍然存在、谁负责回滚。提交、接受、观察到发布和变更后验证各有独立时间。
这份收据无法证明每一台解析器。它的价值正是阻止有限样本在决策档案里悄悄改名为“互联网”。边界清楚的证据仍然可以支持行动，只是承担后果的人能够看见自己接受了哪些未知。
来源
会员简报
档案背景详情
使用相应会员等级登录，即可解锁完整简报与来源注释。
仅限 Strategic Circle
Strategic Circle
所有读者均可浏览。加入并登录后可解锁档案简报。
加入 Strategic Circle仅限 Leadership Alliance
Leadership Alliance
符合条件的 IP 资产所有者和管理层可登录查看 Leadership Alliance 简报。
加入 Leadership Alliance