摘要

  • DNSOP 于 2026 年 8 月 24 日启动 draft-ietf-dnsop-integration-04 的工作组最后征求意见，预定 9 月 7 日结束。当前留存的 Datatracker 状态仍为 In WG Last Call，不能写成已获通过或已成为 RFC。
  • 草案关注的不只是首次证明域名控制权，还包括域名到期、DNSSEC 状态变化、预期记录被删除以及应用如何重新同步。
  • 本文提出四步验收表：建立、更新、删除、转移或重新注册。每一步都应公布触发条件、核验者、应用结果和旧状态允许保留的最长时间。
  • AT Protocol 的 handle 通过双向核验和周期性重查获得失效状态；草案中的 ENS 示例则显示，若该路径不接收 NSEC 否定证明，删除 DNS 记录本身不会抹去较早的链上肯定声明。
  • 四步验收表是 Daniel Kade 的分析建议，不是 IETF 已采纳的规范文字；它要求不同架构证明自己的状态变化，而非使用同一种实现。

9 月 7 日只是流程节点

DNSOP 工作组邮件显示，主席在 8 月 24 日启动最后征求意见，要求参与者说明支持或反对，并把 9 月 7 日列为结束日期。9 月 6 日的提醒再次说明次日截止。可以确认的是征求意见走到预定节点，不能由此推定工作组已经形成大致共识。

IETF Datatracker把第 04 版列为拟采用 Informational 状态的 Internet-Draft。工作组栏仍写着 In WG Last Call，IESG 栏只是 I-D Exists。它不是 RFC，也没有证据表明一定进入某个下一阶段。

这一区分正好对应草案的主题：一个系统在某个时点曾经确认过事实，不等于那个事实在随后每个时点都成立。新闻也应保存状态边界，不能把截止日期当成审批结果。

域名接入是一套状态机

应用界面最容易展示的是“建立”。用户添加 TXT 记录，服务读取记录，域名与账户或地址绑定。第 04 版草案把视线移向建立之后。

草案列出的生命周期事件包括到期、DNSSEC 状态改变，以及原本预期的资源记录被移除。域名的控制者或状态可能因此改变，应用需要避免让早先的注册人继续保有应用内控制。草案还要求建立时核验当前注册人或被授权者，避免用硬编码的偏好 TLD 清单破坏完整性，并记录怎样与全球 DNS 重新同步。

重查频率并非越高越好。频繁查询有成本，可能触发限流；DNS 短时故障、劫持或配置错误也可能造成错误判断。因此，实现者必然要选择缓存、刷新和恢复策略。治理问题不是消灭取舍，而是公开取舍。

本文据此提出一份最小验收表：

状态变化 必须回答的问题 可观察结果
建立 谁证明当前拥有域名控制权或有效授权？ 应用接受或拒绝新绑定。
更新 哪一条更新的声明替换旧声明？ 目标地址或身份标识随之改变。
删除 “不存在”如何成为应用可用的证据，多久生效？ 绑定变为无效、空值或明确过期。
转移或重新注册 新注册人怎样排除旧绑定？ 前任的应用权限终止，新控制者重新证明。

每一行还应标明触发者、核验机制、缓存或刷新规则、最长滞留时间，以及自动流程失败时的人工恢复入口。这不是 DNSOP 草案中的表格，而是把其中生命周期、控制、完整性和同步要求转换为可复现测试。

AT Protocol 让“不再成立”成为一种状态

AT Protocol 把较稳定的 DID 与可变的域名 handle 分开。其 handle 规范要求双向确认：handle 解析后要得到 DID，DID 文档也要反向指向同一 handle。否则，任何人都可能单方面给第三方账户制造一个看似相关的别名。

规范还定义了失败结果：已知 handle 一旦确认无法再解析，就应标为无效。服务可以缓存解析结果，但应周期性重新解析。DNS 记录变化不一定主动通知每个应用，因此应用靠下一次查询发现消失。

这并不等于“立即失效”。缓存较长，查询成本较低，错误展示保留更久；重查较勤，窗口缩短，却增加负载，也更容易把短时 DNS 故障当成真实移除。重要的是，系统承认否定结果，并有一条到达该结果的路径。

AT Protocol 的文档还明确说其 handle 解析不强制 DNSSEC。由此可见，DNSOP 草案并非要求所有集成采用 DNSSEC。共同要求是证明控制、解释变化，具体办法可以不同。

ENS 示例暴露“只能写入新肯定”的缺口

ENS 示例采用另一种路径：把 DNSSEC 肯定证明提交到链上；更新的肯定证明可以覆盖旧证明；域名换手后，新注册人也能为自己的记录提交新证明，重新建立集成。

困难发生在没有新肯定记录时。草案指出，所述 ENS 路径目前不支持 NSEC 否定证明，因此无法在链上证明记录已经不存在或被移除。旧的肯定声明会继续保留，直到更新的肯定证明替换它。仅仅删除底层 DNS 记录，或让域名失效，并不会自动向链上状态传递撤销。

这个问题并非第 04 版刚刚加入。第 03 版已经包含相同限制，03 与 04 的对照也不支持“最新修订才发现”的说法。第 04 版变更记录称其更新了完整性文字。

ENS 的域名导入说明给出了操作者视角：新域名所有者可更改 _ens TXT，并使用刷新操作让 ENS 读取新记录。这能提交一个新的肯定状态，却不能证明“只要 TXT 被删，旧状态就自动消失”。

外推必须克制。这里描述的是一种具体导入路径，不代表所有 ENS 记录、所有 DNSSEC 使用者或所有 DNS 集成都有同样限制。它的普遍意义在于提出检查问题：能吃进肯定证明的系统，是否也能消化“证明已经不存在”这件事？

删除测试实际测量风险由谁承担

建立绑定能带来新用户，适合做产品演示；删除不会增加增长数字，却需要查询、核验、改写状态、客服处理，有时还涉及链上交易。即使没有恶意，组织也容易把资源投入入口，把出口留成“稍后同步”。

旧状态的危害取决于用途。过期显示名可能误导读者，过期路由目标可能让流量走错地方；如果域名绑定被用作付款地址、管理权限或身份凭据，DNS 依据消失后仍保留的状态就可能延续实质控制。

域名到期也不能被描述成一个统一的瞬间。ICANN 的 gTLD 生命周期列出多个阶段，各类域名政策也可能不同。应用需要公布的是：它认定哪些 DNS 或注册事件足以改变应用状态，改变需要多久。

恒璐所主张的最小初始规范、未来本地决策与自愿采用适合处理这类差异。四种状态变化可作为共同底线；解析器、证明系统、缓存时长和恢复流程由各应用选择。

“运行中的代码优先”则规定了证据标准。“DNS 已验证”只是标签；依次执行写入、修改、删除和换手，观察应用输出，才知道控制权究竟在哪里停留。

资料来源

  1. DNSOP 工作组最后征求意见通知
  2. DNSOP 截止日前提醒
  3. IETF Datatracker 文档页
  4. IETF 文档状态历史
  5. DNS 集成草案第 04 版
  6. DNS 集成草案第 03 版
  7. 第 03 与 04 版官方对照
  8. DNSSEC 协议修改，RFC 4035
  9. AT Protocol handle 规范
  10. AT Protocol 仓库同步规范
  11. ENS 链上 DNS 导入说明
  12. ICANN gTLD 生命周期
  13. 恒璐：最小初始规范与本地化的未来决策
  14. 恒璐：运行中的代码优先