Summary

  • draft-gould-regext-epp-server-validation-00 proposes a common EPP container for synchronous, asynchronous and scheduled server validations, but the validation type is defined by server policy and its date, trigger, transition history and failure reasons are optional.
  • The binary value reports only whether the last validation succeeded or failed. It does not by itself establish what was tested, from which observation point, against which inputs, how long the result remains useful or whether a later poll message was received and acted upon.
  • Operators need a validation-state receipt that binds the verdict to policy version, test definition, vantage, inputs, execution and transition times, trigger, recipient, poll identity, acknowledgement and remediation evidence.

A green indicator answers quickly and governs easily. It can release a workflow, quiet an alert or reassure a customer. Its convenience is also its danger: the label “success” sheds the conditions that made it true.

The first version of the Server Validation Extension for EPP tries to solve a real coordination problem. A registry can validate conditions around a managed object, such as DNS resolution or DNSSEC. Today those results can be exposed in proprietary ways or not at all. The draft defines a structured validationData element that can appear immediately in the response to a transform command, later through a poll message, or on demand in an info response.

That common envelope is valuable. It is not a common validation policy. The type value is explicitly up to server policy. dns and dnssec are examples. The draft gives status only two values: success for the last successful validation and failed for the last failed validation. What counted as DNS resolution, which resolver path was used, which DNSSEC chain and algorithms were accepted, how retries were handled and when a result becomes stale remain outside those two tokens.

The optional clock is the centre of the claim

The draft can carry the time at which validation ran, the transform operation that triggered it, the last previous success, the first failure and the last failure before recovery. Each of those fields is optional. A failure may also include one or more server-specific reasons, and a language tag may accompany them. The structure can tell a rich temporal story, but it does not require every implementation to do so.

That makes omission meaningful. “Success” without a validation date is not equivalent to success observed now. A failed result without lastSuccess cannot say whether the object has always failed or deteriorated yesterday. A recovered result without lastFailed erases the duration and recurrence of the incident. An asynchronous validation without a triggering transform deliberately omits the operation, which is correct—but an operator still needs to know whether it arose from a schedule, a manual intervention or another server policy.

Time is not decorative metadata for DNS. Records, signatures, delegations, resolver caches and network paths change. RFC 4035 specifies DNSSEC validator behaviour, but a typed result in this extension is still produced by a particular server under its own policy. A validation can be accurate for its observation point and obsolete for the decision a registrar is about to make.

The correct reading is therefore “the server's last recorded execution of validation type X returned success,” not “the domain is healthy.” The latter silently adds continuity, comprehensiveness and certification that the schema does not contain.

Synchronous and asynchronous truth have different custody

When validation is synchronous, the result travels with the EPP response that triggered it. The client can preserve the client and server transaction identifiers alongside the result. Its relationship to the operation is relatively direct, even though the validation definition still comes from server policy.

Asynchronous and scheduled results enter the EPP poll queue. RFC 5730 makes that queue sequential and client-specific. A poll request returns the first message with a unique message ID and a queue count. The client must acknowledge receipt; the server then removes the message and makes the next one available.

That acknowledgement is a delivery event. It is not a remediation event. The client may have parsed the failure, failed to route it internally, or acknowledged it before an operator saw it. A scheduled success-to-failure transition may wait behind unrelated messages. Queue pressure may influence other delivery mechanisms. The validation timestamp, queue insertion time, retrieval time and acknowledgement time describe different delays and must not collapse into one “notification time.”

The proposed extension adds validation data to poll responses but does not change the poll command. That is a sensible reuse of EPP. It also means the durability of the signal depends on existing queue discipline. A registrar that acknowledges then discards a message has obeyed the wire protocol and lost the governance record.

The recipient changes the evidence

The security section makes another policy boundary explicit. The server chooses what information to provide to sponsoring and non-sponsoring clients and may disclose failure reasons only to the sponsoring client. This protects operational detail that could help an unauthorised party. It also means two authorised views of the same object may contain different evidence.

A public or non-sponsoring observer might see failed without the server-specific reason. The sponsoring registrar might receive missing-DNSKEY detail. Neither response is necessarily false. They answer different disclosure policies. An audit must therefore record the recipient class; otherwise later comparison can mistake controlled redaction for inconsistent validation.

Reasons themselves should not be mistaken for stable codes. In the current draft they are optional server-specific text. They can be localized and repeated. That helps people troubleshoot, but machines should not infer durable categories by scraping phrases. If operators need interoperable remediation routing, they will need a separately governed reason taxonomy or a documented local mapping with version history.

Every transform can acquire a validation shadow

The draft covers create, renew, transfer, update and deletion that does not immediately purge the object. It also recognizes restore, automatic renewal, automatic deletion and custom operations defined by server policy. A transfer requires a sub-operation such as request, approve, cancel or reject; restore distinguishes request and report. Synchronous data can appear in the transform response even though the extension adds no new elements to the transform request.

This separation prevents the client from dictating what the server claims to have validated. It also gives the server wide discretion over when validations run. One registry may validate DNSSEC after create and on a schedule; another may validate only on update; a third may define a custom check. All can serialize the same success token.

Comparability therefore requires more than schema conformance. A procurement report that counts success across registries without comparing their policies may rank unlike tests. A service-level dashboard that treats missing dates as current may reward the least informative implementation. A compliance programme that equates sponsoring-client detail with public evidence may disclose too much or claim too much.

A validation-state receipt preserves the missing dimensions

I propose a validation-state receipt. It is not part of the draft. It is the minimum evidence bundle needed before a binary state is used to govern another decision.

The first block identifies the test: validation type, server-policy version, normative or local definition, accepted algorithms, retry logic, resolver or network vantage and exact input set. For DNSSEC, that may include the chain and trust-anchor context without publishing secrets or a reusable attack path.

The second block identifies time and cause: execution time, triggering transform and sub-operation, or scheduled/manual origin. It records last success, first failure and last failure when available, and marks absent fields as unknown rather than converting them to “never.”

The third block records custody: object, sponsoring status of the recipient, poll message ID and count, queue date, retrieval time, acknowledgement time and internal handoff. If reasons were withheld, it says so. If text was localized, the original token and language remain available.

The final block separates receipt from remedy. It records the ticket, operator decision, subsequent validation and closure evidence. A poll acknowledgement ends the queue item; only this later evidence can show that the condition ended.

The current document is an individual Internet-Draft dated 19 July 2026. Datatracker says it has no formal IETF standing, no stream and no intended RFC status, while its header says Standards Track. The draft requests future IANA namespace and extension-registry entries, but those requests do not make them present facts. Its ideas deserve examination without being promoted to deployed consensus.

Sources