摘要

  • RFC 5144 把 DCHK 定义为 IRIS 域名注册数据模型的轻量子集。
  • active 与 inactive 描述 DNS 发布状态，不等于是否可由某个申请者注册。
  • reserved 明确表示不能按常规程序注册，即使域名没有出现在 DNS 中。
  • 争议与多种宽限期说明，生命周期不能压缩成一个红绿灯。
  • 创建、删除、续期、恢复、转移与更新可处于 pending 或 prohibited，操作名称不证明完成。
  • actor、scope 与子状态权威说明是谁、在哪个范围内作出判断。
  • lastDatabaseUpdateDateTime 是源数据库时间，不是响应、显示或决策时间。
  • 注册引用只是下一站地址，不会携带下一站的授权与策略批准。
  • IRIS 的 XML 层自身不提供认证或隐私，必须依赖应用传输层。
  • IANA 仍登记 DCHK 标识，但登记存续不能证明生产部署。
  • RFC 5144 仍为 Proposed Standard，其 IDN 字段却引用已过时的 Nameprep。
  • 负责人应分别保存观察、策略、受理、提交、DNS 发布与实际结果的凭据。

三只钟决定一次误判

第一只钟是源状态时间。RFC 5144 的字段明确记录“作为本结果来源的数据库”最后一次实际更新。第二只钟是观察时间：客户端何时收到响应。第三只钟是决策时间：人或自动化何时据此付款、提交命令或撤掉备用域名。

缓存还会增加第四只钟，注册命令日志会增加第五只钟。把这些时间都写成 updated_at，事故发生后就无法判断究竟是复制延迟、策略变化，还是两个申请者之间的竞态。

快速接口尤其容易掩盖这个问题。延迟指标证明服务能迅速送达一份记录，却不证明记录描述的是当前世界。界面刷新动画也只证明前端工作正常。按照 Heng Lu 对现实层的区分，符号被成功搬运，不等于它所代表的运行状态已经同步。

inactive 只回答 DNS 问题

RFC 5144 把 active 定义为通过委派或直接发布而可在 DNS 中使用，把 inactive 定义为在 DNS 中不可用。这条轴是“是否发布”，不是“能否注册”。

同一模型另有 reserved：域名不能通过常规注册程序取得。一个名字完全可以同时没有 DNS 发布、又被策略保留。它也可能处于争议，或在创建、续期、自动续期、转移、删除之后的宽限期。

RFC 3915 描绘了删除后的状态机：赎回期、恢复等待、删除等待，最后才可能清除并重新开放。查询正确并不等于预测正确，因为查询只描述当时的一层事实。

创建、删除、续期、恢复、转移和更新状态还可以带 pending 或 prohibited。若产品只留下“transfer”，就会把“转移尚未完成”显示成“控制权已经转移”。RFC 5731 在 EPP 场景中进一步说明：检查只提供对创建成功的提示，最终条件仍由服务器策略决定；已处理的变更也可能继续等待。DCHK 与 EPP 不是同一接口，但查询、受理和完成显然是不同证据。

每个状态都应带着说话者

DCHK 状态可包含适用日期、服务工单、自然语言说明和子状态。规范不统一定义子状态的值，却要求指出定义该值的权威。actor 可区分注册管理机构、注册服务商与注册服务提供者；scope 则说明上下文或来源。

这些字段防止权力被偷偷放大。注册服务商的局部禁止不是整个注册表的永久禁令；某一范围内的合规也不是全球通行证；一个有工单的等待状态更不是完成凭据。

如果数据管道为了“标准化”而删除这些限定语，得到的并非干净数据，而是一条无法追责的强断言。最小共享记录的价值，在于保留必要协调事实，而不是替所有本地决策发言。

引用不会传递权限

registrationReference 可以把注册表查询结果指向下游的注册商或注册人服务。IRIS 还支持跨注册类型和实例的实体引用、搜索延续，并提醒客户端不要反复跟随同一引用，以免进入循环。

到达下一站只证明路径可走。下一站可能要求登录、资格、付款或另一套策略；它也可能拥有更新的数据。上游不能凭一个 URI 把下游的决定权预先授予用户。

安全连接同样不能越权。RFC 3981 说明 IRIS XML 层自身不提供认证和隐私，而依赖传输机制，并警惕在跟随引用时使用可重放凭据。RFC 5144 要求实现 IRIS-LWZ，XPC 与 BEEP 可选。即使传输认证完全成功，也只证明一次会话的对端，不证明注册资格或对象变更已经落库。

协议登记不是运行证据

IANA 仍保存 dchk1 XML 命名空间与模式、DCHK1 S-NAPTR 标签以及相应 BEEP 配置。RFC 5144 也仍标为 Proposed Standard。唯一已验证勘误只是把 “Straightforward-NAPTR” 的拼写改正。

这些都是可核验的制度记录，却不能回答现在哪些服务器正在运行、查询量多大、状态延迟多久。本文没有这类数据，因此不作部署规模判断。

IDN 依赖还暴露了兼容性边界。RFC 5144 引用 RFC 3491 的 Nameprep；后者已经过时，RFC 5891 定义了 IDNA2008。不能因此声称 RFC 5144 已被正式废止，也不能假定旧的规范化规则自动符合今天的注册策略。RFC 9083 展示了后来的 RDAP JSON 响应模型，但它在本文中只是演进参照，不是形式上的替代证明。

从观察到结果的凭据链

可靠系统先保存标准化查询、目标权威、协议版本和原始响应；再保存源数据库时间、响应时间、缓存时间与决策时间；同时保留全部状态、参与者、范围、处置、工单和子状态权威。

随后另起一条变更链：申请者身份与资格、适用策略与价格、命令提交与受理、人工或第三方等待、注册表最终提交、DNS 委派或直接发布、递归解析与应用结果。

前一层可以触发后一层检查，却不能替代后一层。若一个系统只能显示“可用”，它应至少诚实地写明：谁在何时、基于哪份数据库、针对哪种操作，给出了什么程度的预测。

来源

  1. RFC 5144 HTML
  2. RFC 5144 文本
  3. RFC Editor 记录
  4. IETF Datatracker 记录
  5. 文档历史
  6. RFC 5144 勘误查询
  7. 含已验证勘误的版本
  8. IANA XML 注册表
  9. IANA S-NAPTR 参数
  10. IANA BEEP 参数
  11. RFC 3981：IRIS 核心协议
  12. RFC 3982：IRIS 域名注册类型
  13. RFC 3983：基于 BEEP 的 IRIS
  14. RFC 4992：IRIS XML 分块流水线
  15. RFC 4993：IRIS 轻量 UDP 传输
  16. RFC 3915：EPP 宽限期映射
  17. RFC 5731：EPP 域名映射
  18. RFC 3491：Nameprep
  19. RFC 5891：IDNA2008 协议
  20. RFC 9083：RDAP JSON 响应
  21. Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption
  22. On Reality Layers, Symbolic Power, and Why Clarity Feels So Hostile
  23. Running-Code Primacy