摘要

  • draft-gould-regext-epp-server-validation-00 为同步、异步和定期服务器验证提供共同容器，但验证类型由服务器政策决定。
  • success 只表示最后一次验证成功；执行日期、触发操作、状态转换和失败原因均可省略。
  • “验证状态回执”应绑定定义、政策版本、观测位置、输入、时间、收件方、轮询消息、确认与整改证据。

注册局可以验证 DNS 能否解析、DNSSEC 是否通过，并把结果放进变更命令响应、info 响应或稍后的 poll 消息。定期验证发生状态变化时也会入队。这为原本各自为政的信号提供了统一形状。

形状统一不代表标准统一。草案明确说 type 由服务器政策决定，dns 与 dnssec 只是例子。解析器、网络位置、算法政策、重试和输入集合都可能不同。两家注册局同时写出 success，不等于完成了同一项测试。

可选时间决定证据上限

执行日期、触发操作、上次成功、首次失败、恢复前最后失败均为可选；失败原因也是可选的服务器自定义文本，可重复并附语言。缺失字段只能解释为未知。没有 lastFailed 不能推导“从未失败”，没有 lastSuccess 不能推导“一直失败”，没有日期更不能把成功当作当前状态。

DNS 记录、签名、委派、缓存和路径都会变化。严谨说法是“该服务器最后一次执行 X 类型验证时成功”，而不是“域名健康”。后一句擅自加入了持续性、完整性与认证权威。

确认轮询消息不等于问题已解决

RFC 5730 的队列按客户端保存消息。轮询返回第一条消息、唯一标识与队列计数；客户端确认收到后，服务器将其出队。确认只证明交付，不证明人已阅读、工单已建立或配置已修复。

一次计划性失败可能排在其他消息之后，也可能被自动系统确认后丢在内部路由中。验证时间、入队时间、取回时间、确认时间与升级时间是五个不同事实。把它们合并成“通知时间”会掩盖责任。

证据还随收件方变化。安全部分允许服务器决定向主办和非主办客户端披露多少内容，也可只给主办方失败原因。不同视图可能都真实，但审计必须记下收件方身份与披露规则。

回执先于出队

本文提出的回执先记录验证类型定义、服务器政策版本、观测位置、参数、输入和执行时刻。再记录触发变更或计划来源、可见转换历史，并把缺失值保留为未知。

随后保存对象、收件方类别、消息 ID、队列日期、取回与确认时刻、内部转交。最后另行记录工单、处置、新验证与关闭。自由文本可帮助工程师，却不能被偷偷当作跨注册局稳定错误码。

当前文本是 2026 年 7 月 19 日的个人 Internet-Draft。Datatracker 明确说它没有 IETF 正式地位，也未列 RFC 流或预期状态，页眉却写 Standards Track。IANA 登记是未来请求，不是当前事实；没有来源证明生产部署。

来源