摘要

  • DNS DELEG 的 RDAP 扩展修订 05 删除了 priority 和 target，把结构名称改为 DelegInfos，并按照 DELEG-11 重写示例。
  • 它列为规范性依赖的 EPP 供应草案，仍在自称完整的 XML 模式中定义 priority 与 target 属性。
  • RDAP 草案要求返回 dnsDeleg 一致性标识，但对 JSON 键值集合的完整说明依然标记为 TBD。
  • 现有资料没有证明任何部署故障；能够成立的结论更窄：三份演进中的文本还没有给出一条可测试的 EPP—DNS—RDAP 往返路径。

先移动的是读取侧

I-D 公告显示，draft-albanna-regext-rdap-deleg-05 于 2026 年 9 月 4 日发布。它想做的事情并不复杂：让域名的 RDAP 响应能够携带正在设计中的 DNS DELEG 委派信息。

修订记录把关键变化写得很直接。05 版称，它删除了列表对象中的 priority 和 target，把 delegInfo 更名为 DelegInfos，并将示例改为以 draft-ietf-deleg-11 为准。DELEG-11也明确说明：虽然格式借鉴 SVCB，但 DELEG 不包含 SvcPriority 和 TargetName，其载荷只是 DelegInfo 键值对的列表。

DELEG-11 当前给出四个名称服务器信息键：server-ipv4、server-ipv6、server-name 和 include-delegparam，另有 mandatory 元数据键。它还建议建立独立的 IANA 登记表，为今后的键记录编号、名称、含义、稳定参考和变更控制者。这是一种受约束的可扩展性，而不是允许每个实现自行发明字段。

RDAP 配套草案现在已经在文字和示例里跟上了这次删除。这是读取侧：注册数据客户端在 JSON 响应中看到的模型。

被引用的写入侧仍使用旧形状

同一份 RDAP 草案说，它的数据定义同时依据 DELEG 与 DELEG 的 EPP 映射。EPP 是赞助客户端管理注册局域名对象所使用的协议体系；RFC 5731提供既有域名映射，新的 EPP 草案再为 create、update 和 info 命令增加 DELEG 元素。

问题出现在 EPP DELEG 修订 02的正式语法中。该章节称自己是可供自动验证的完整 XML 模式，但其中的 delegType 仍有无符号短整数 priority 属性与 target 属性；参数容器还用 processContents="skip" 接受任意属性。它日期为 7 月 21 日，比 DELEG-11 早两天，尚未吸收 RDAP 修订 05 所采用的新模型。

这并不能证明任何注册商实际发送这些字段、注册局保存了它们，或者 RDAP 服务器正在丢弃它们。两份配套文本都是个人 Internet-Draft，本次研究也没有生产链路记录。能够直接观察到的是：按当前 EPP 模式通过验证的写入内容，可以带有 DELEG-11 明确说不存在、RDAP 修订 05 又主动删除的字段。

三份文件还没有规定桥接器必须怎样处理这种差异：拒绝、忽略、放进私有参数，还是迁移为另一种结构？读者可以猜，但无法从规范中复现唯一答案。

dnsDeleg 只标识扩展，不记录转换履历

修订 05 要求，含有这类数据的响应必须在 rdapConformance 中加入 dnsDeleg。RFC 9083把这些字符串定义为构造 RDAP 响应时采用的规范标识，帮助客户端识别自定义 JSON。它们不是单个数值的来源证明，也不能证明写入表示经历转换后仍然完整。

这一局限在当前版本尤为重要，因为响应规范在“完整的 DelegInfos 键值说明”处仍保留 TBD，并说未来可能引用 DELEG、EPP 映射或两者。示例展示了输出的大致样子，却没有给出规范性的转换表。

研究冻结时，实时的 IANA RDAP Extensions 登记表还没有 dnsDeleg。草案请求以 “Any” 为适用运营者，并以自身为发布规范来登记。这里的缺席不是 IANA 拒绝，只是一个拟议标识尚未成为登记项的时点状态。

REGEXT 已另有一份 RDAP 版本化草案，提出机器可读的扩展版本、前驱与后继关系、弃用信息和迁移策略。RDAP DELEG 修订 05 目前既未采用这套机制，也没有声明生成载荷时使用的模式身份。

三份文件的程序地位不同

Datatracker把 RDAP 文本列为没有 RFC stream、没有负责 Area Director 的个人草案。EPP 映射也是没有 RFC stream 的个人草案。任何人都可以提交此类文件，发布不等于 IETF 背书。

DELEG-11 的程序地位更强：它是 DELEG 工作组文件，处在 Working Group Last Call。但它仍是草案，所请求的 DNS RR 编号和新的 Delegation Information 登记表仍含待分配或拟议状态。不能把三个不同阶段压缩成“完整协议栈已经完成”。

同样，也不应把当前差异夸大为事件。最可能的解释只是三份草案更新时间不同造成的依赖滞后。正因为修复成本还低，才应在实现把编辑历史变成不兼容状态之前，把这条接缝写清楚。

缺失的是可执行的数据保管图

完整契约至少要回答四个问题：每个字段由哪个修订版本定义？EPP 输入怎样成为权威 DNS 数据？该 DNS 状态怎样变成 RDAP JSON？在哪一条边上允许有意丢失哪些信息？

在这些答案尚未具备规范性和可测试性之前，dnsDeleg 只能说明扩展存在，不能说明是哪条路径生成了它。公开查询可以忠实于自己的数据库，却仍让读者无法区分注册局意图、权威 DNS 观测与本地投影策略。谁控制转换，谁就控制最终可见的陈述；这正是治理边界。