摘要

  • draft-hoffman-duj-06 定义了由人从服务方复制、再粘贴到 DNS 运营者界面的 DUJS 或 DUJ64 动作包；它明确不是自动更新协议，也不提供密码学保护。
  • 格式正确与整包原子提交只能证明有限事实。账户到区域的权限、本地政策、权威服务加载、递归缓存收敛以及下游验证结果仍是不同的证据节点。

能解析动作，不能解析授权

DNS 控制台收到一个合法的 I-JSON 数组。第一个值是 DUJS，第二个值包含三项按顺序排列的动作。所有 FQDN、记录类型与 Rdata 都符合语法；删除项找到了精确旧值，增加项也没有重复。解析器没有任何疑问。

它仍不知道这项变更是否该发生。

提交账户也许属于外包团队，只能维护父区的一部分。动作中的名字也许已经落入子区切割之后。给出字符串的服务也许是真实服务，也许是被劫持的会话，甚至可能只是从工单中转贴的一段旧内容。格式能够描述意图，却不能自己取得决定权。

DUJ 的价值正在于没有掩盖这一点。修订版 06 针对当前常见流程：服务方用自然语言要求用户添加或删除 DNS 记录，用户再到 DNS 运营商界面操作。DUJ 只把这段人工交接变得精确和可预测，并明确限定为复制粘贴场景。设计自动协议的人不应复用它。

这是最小规格与本地决定的清晰分工。

为什么格式被刻意做得很薄

一个 DUJ 值只有两层核心结构。第一项必须是 DUJS 或 DUJ64；第二项必须是非空更新数组。数组中的每个动作模板只有两个值：精确的 add 或 delete，以及 RFC 1035 区域文件格式的记录数据。

草案选择数组而不是可扩展对象，是为了阻止旁路说服字段。服务方不能附加“紧急安全更新”“账户必须验证”之类的键，再让标签替代对真实记录的审查。格式也不打算静默扩展；未来若要改变语义，应更换开头的版本标识。

DUJS 允许人看到相对可读的记录数据，但排除了注释、指令和内嵌换行。DUJ64 则用 Base64 携带同一数据，适合避开引号和转义在复制过程中被破坏的问题，但内容对普通用户有意不可读。用户仍可看到这是增加还是删除，却未必能理解最终 DNS 效果。

Base64 不是加密，I-JSON 不是签名，类型注册也不是权限。它们解决表示与互操作问题，不负责颁发授权。

人处在中间，不代表两段会话已经绑定

字符串先从服务方到用户，再从用户到 DNS 运营者。草案对两段链路分别作出边界说明：来源真实性与完整性，只能达到用户连接服务方的强度，以及用户连接 DNS 运营者的强度。

这中间没有自动形成端到端委托。DNS 运营者能确认当前账户，却未必知道原始服务、展示会话和中间传输是否一致。服务方也无法从“已展示字符串”推断运营者已经接受，更不能推断权威 DNS 已加载结果。

因此，产品至少要保存四个不同记录：服务展示的来源与精确字节、提交账户的身份、账户对每个目标区域的权限、运营者对整套动作的本地政策决定。把它们压成一个“验证成功”状态，会让事后调查失去因果链。

原子性只回答整包是否一起提交

更新数组是有序的。运营者必须先确认整个 DUJ 能够原子应用；任何一项阻止整包提交时，不得先执行其中一部分。这能避免先删除旧验证记录，却因为后续错误无法安装新值的半完成状态。

原子性并不评价整包好坏。攻击者可以构造逻辑一致的整包，过期工单也可以完整执行，针对错误客户的记录同样可以一次性落地。事务完整性保护动作之间的关系，不替动作制造合法性。

草案所以保留了运营者的明确裁量。运营者必须验证用户有权修改 FQDN 所在区域；必须识别区域切割可能使名字超出控制范围；可以根据本地政策拒绝以 RFC 3597 形式表示的未知类型；也可以因为“先加后删同一记录”等理由拒绝任何 DUJ，并应向界面用户说明原因。

共享格式描述要做什么。实际是否做，仍由承担运行责任的一方决定。

重试与跳过需要可审计回执

重复提交不会总产生相同的表面结果。若精确记录已经存在，运营者可以跳过增加；若精确记录已经不存在，也可以跳过删除。处理条款同时要求核查存在或不存在，并建议告知用户每一项实际完成的变更。

所以“已接受”不足以作为回执。可审计回执应绑定整包哈希、认证账户、目标区域、授权依据、本地政策判断、变更前后 RRset、被跳过的动作、原子事务标识和时间。这个细化回执是本文提出的运行建议，不是修订版 06 已有的规范要求。

提交之后还要跨过发布边界。后台事务成功，不代表全部权威服务器已经加载；辅助服务器可能滞后；递归解析器可能在 TTL 到期前继续返回旧值；证书、邮件或社交平台服务可能从另一个解析视图查询。真正需要下游结果时，应分别记录权威观测、必要的递归视图和下游服务自己的判断。

一个绿色状态不该同时冒充授权、提交、发布和业务完成。

文档状态不能被修订号放大

修订版 06 于 2026 年 9 月 26 日上传，2027 年 3 月 30 日到期。Datatracker 将其列为活跃的个人 Internet-Draft，没有 RFC stream，也没有 IETF 标准流程中的正式地位。文本写有 Standards Track 意向，但这不等于工作组采纳、IETF 共识、IESG 批准或 RFC 发布。

冻结的 05 到 06 差异只更新修订号、日期与到期日，没有新机制。来源也没有证明任何实现、部署、互操作、性能、事故、攻击或商业结果。本文讨论的是草案所描述的控制边界，不是市场事实。

来源