Server Validation Extension for the Extensible Provisioning Protocol (EPP)

This document describes an extension mapping for version 1.0 of the Extensible Provisioning Protocol (EPP). This mapping, an extension to EPP object mappings like the EPP domain name mapping, is used to provide the status of server validations that can be performed synchronously or asynchronously. The result of synchronous validations is included in the EPP response. The result of asynchronous validations is included in a poll message. Scheduled validations that change the status of a typed-validation are included in a poll message. The extension extends the EPP <poll> response in and does not extend the EPP <poll> command. Please refer to for information and examples of the EPP <poll> command.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here. XML is case sensitive. Unless stated otherwise, XML specifications and examples provided in this document MUST be interpreted in the character case presented in order to develop a conforming implementation. In examples, "C:" represents lines sent by a protocol client and "S:" represents lines returned by a protocol server. Indentation and white space in examples are provided only to illustrate element relationships and are not a REQUIRED feature of this protocol. The XML namespace prefix "serverVal" is used for the namespace "urn:ietf:params:xml:ns:epp:serverValidation-0.1", but implementations MUST NOT depend on it and instead employ a proper namespace-aware XML parser and serializer to interpret and output the XML documents.

This extension adds additional elements to EPP object mappings like the EPP domain name mapping. Only those new elements are described here.

The <serverVal:validationData> element is returned in the transform command response for synchronous server validation, in the <info> response, and in the poll message for asynchronous server validation. The <serverVal:validationData> element includes a list of one or more <serverVal:validation> elements with the following child elements: Type of server validation that is up to server policy. Example values include "dns" for 2026202 validation of DNS resolution and "dnssec" for validation of DNSSEC. Status of the server validation with the values of "success" to reflect that the last validation was successful and "failed" to reflect that the last validation failed. OPTIONAL date and time when the server validation was executed. OPTIONAL transform operation executed on the object as defined in that triggered the validation. This element is not included if the server validation was performed asynchronously without a triggering transform operation. OPTIONAL date and time when the server validation was last successful. This element should only be returned when the <serverVal:status> element has the value of "failed" and there was a prior successful validation. OPTIONAL date and time when the server validation first failed. This element should only be returned when the <serverVal:status> element has the value of "failed". OPTIONAL date and time when the server validation last failed. This element should only be returned when the <serverVal:status> element has the value of "success" and there was a prior failed validation. OPTIONAL list of server validation failure reasons when the <serverVal:status> element has the value of "failed". If present, this element contains the server-specific text to help explain the reason for the failure. An OPTIONAL "lang" attribute MAY be present to identify the language if the negotiated value is something other than the default value of "en" (English).

Example <serverVal:validationData> element for a successful "dnssec" server validation that was performed asynchronously without a triggering transform command: success dnssec 2026-01-01T12:22:53.0Z ...]]>

Example <serverVal:validationData> element for a failed "dnssec" server validation that was performed asynchronously without a triggering transform command: dnssec failed 2026-01-03T07:21:33Z 2025-12-12T08:19:44Z Matching DNSKEY not found for DS keyTag 12345 ...]]>

Example <serverVal:validationData> element for a successful synchronous "dns" and "dnssec" server validation returned in a create response: dns success 2026-01-01T12:22:45.0Z create dnssec success 2026-01-01T12:22:53.0Z create ...]]>

An operation consists of any transform operation that triggered the server validation. The <serverVal:operation> element defines the operation. The OPTIONAL "op" attribute is an identifier, represented in the 7-bit US-ASCII character set defined in , that is used to define a sub-operation or the name of a "custom" operation. A server validation can only be performed prior to object being purged. The enumerated list of <serverVal:operation> values is: Create operation as defined in . Delete operation as defined in if the delete operation does not result in an immediate purge of the object. Renew operation as defined in . Transfer operation as defined in that MUST set the "op" attribute with one of the possible transfer type values that include "request", "approve", "cancel", or "reject". Update operation as defined in . Restore operation as defined in that MUST set the "op" attribute with one of the possible restore type values that include "request" or "report". Auto renew operation executed by the server. Auto delete operation executed by the server if the auto delete operation does not result in an immediate purge of the object. Custom operation that MUST set the "op" attribute with the custom operation name. The custom operations supported is up to server policy.

Date and time attribute values MUST be represented in Universal Coordinated Time (UTC) using the Gregorian calendar. The extended date-time form using upper case "T" and "Z" characters defined in MUST be used to represent date-time values, as XML Schema does not support truncated date-time forms or lower case "T" and "Z" characters.

Server Validation Poll Message The EPP <poll> command and response are defined in section 2.9.2.3 of . When a server validation is initially performed asynchronously and when the scheduled server validation status changes, an <info> response with the validation data in is inserted into the poll queue.

Example <poll> command: C: C: C: C: ABC-12345 C: C:]]>

Example <poll> response for a successful "dns" and "dnssec" server validation triggered from a <create> command: S: S: S: S: S: Command completed successfully; ack to dequeue S: S: S: 2026-01-01T12:22:45Z S: domain.example successful create validations S: S: S: S: domain.example S: EXAMPLE1-REP S: ClientX S: 2015-10-15T09:19:55.0Z S: ClientY S: 2026-01-01T14:25:57.0Z S: S: S: S: S: S: dns S: success S: 2026-01-01T12:22:45.0Z S: create S: S: S: dnssec S: success S: 2026-01-01T12:22:53.0Z S: create S: S: S: S: S: ABC-12345 S: 54321-XYZ S: S: S:]]>

Example <poll> response for mixed scheduled server validations, with a "dns" success and a "dnssec" failed validation: S: S: S: S: S: Command completed successfully; ack to dequeue S: S: S: 2026-01-01T12:22:45Z S: domain.example mixed server validations S: S: S: S: domain.example S: EXAMPLE1-REP S: ClientX S: 2015-10-15T09:19:55.0Z S: ClientY S: 2026-01-01T14:25:57.0Z S: S: S: S: S: S: dns S: success S: 2026-01-01T12:22:45Z S: 2025-12-30T11:11:34Z S: S: S: S: dnssec S: failed S: 2026-01-01T12:22:53Z S: S: Matching DNSKEY not found for DS keyTag 12345 S: S: S: Insecure DNSKEY algorithm for DS keyTag 54321 S: S: S: S: S: S: ABC-12345 S: 54321-XYZ S: S: S:]]>

A detailed description of the EPP syntax and semantics can be found in the EPP core protocol specification .

EPP provides three commands to retrieve object information: <check> to determine if an object is known to the server, <info> to retrieve detailed information associated with an object, and <transfer> to retrieve object transfer status information.

This extension does not add any elements to the EPP <check> command or <check> response described in the .

This extension defines additional elements to extend the EPP <info> command and response to be used in conjunction with . The EPP <info> command is extended with an empty <serverVal:validationInfo> element to indicate the desire for the server validation information to be included in the extension to the <info> response.

Example <info> domain command with the <serverVal:validationInfo> extension to retrieve the server validation information.: C: C: C: C: C: domain.example C: C: C: C: C: C: ABC-12345 C: C:]]> If the query was successful, the server replies with the <serverVal:validationData> element, defined in , along with the regular EPP <resData>.

Example <info> domain response using the <serverVal:validationInfo> extension with a successful "dnssec" server validation: S: S: S: S: Command completed successfully S: S: S: S: domain.example S: EXAMPLE1-REP S: ClientX S: 2015-10-15T09:19:55.0Z S: ClientY S: 2026-01-01T14:25:57.0Z S: S: S: S: S: S: dnssec S: success S: 2026-01-01T12:22:53.0Z S: S: S: S: S: ABC-12345 S: 54321-XYZ S: S: S:]]>

Example <info> domain response using the <serverVal:validationInfo> extension with a failed "dnssec" server validation: S: S: S: S: Command completed successfully S: S: S: S: domain.example S: EXAMPLE1-REP S: ClientX S: 2015-10-15T09:19:55Z S: ClientY S: 2026-01-01T14:25:57Z S: S: S: S: S: S: dnssec S: failed S: 2026-01-03T07:21:33Z S: 2025-12-11T07:20:00Z S: S: 2025-12-12T08:19:44Z S: S: S: Matching DNSKEY not found for DS keyTag 12345 S: S: S: S: S: S: ABC-12345 S: 54321-XYZ S: S: S:]]>

This extension does not add any elements to the EPP <transfer> query command or <transfer> response described in the .

EPP provides five commands to transform objects: <create> to create an instance of an object, <delete> to delete an instance of an object, <renew> to extend the validity period of an object, <transfer> to manage object sponsorship changes, and <update> to change information associated with an object.

This extension does not add any elements to the EPP <create> command. This extension does define additional elements to the EPP <create> response with the <serverVal:validationData> element when the server validation is executed synchronously in the EPP <create> command.

This extension does not add any elements to the EPP <delete> command. This extension does define additional elements to the EPP <delete> response with the <serverVal:validationData> element when the server validation is executed synchronously in the EPP <delete> command.

This extension does not add any elements to the EPP <renew> command. This extension does define additional elements to the EPP <renew> response with the <serverVal:validationData> element when the server validation is executed synchronously in the EPP <renew> command.

This extension does not add any elements to the EPP <transfer> command. This extension does define additional elements to the EPP <transfer> response with the <serverVal:validationData> element when the server validation is executed synchronously in the EPP <transfer> command.

This extension does not add any elements to the EPP <update> command. This extension does define additional elements to the EPP <update> response with the <serverVal:validationData> element when the server validation is executed synchronously in the EPP <update> command.

One schema is presented here that is the EPP Server Validation Extension schema. The formal syntax presented here is a complete schema representation of the object mapping suitable for automated validation of EPP XML instances. The BEGIN and END tags are not part of the schema; they are used to note the beginning and ending of the schema for URI registration purposes.

Extensible Provisioning Protocol v1.0 Server Validation Mapping Schema. END]]>

This document uses URNs to describe XML namespaces and XML schemas conforming to a registry mechanism described in . The following URI assignment is requested of IANA: Registration request for the serverValidation namespace: URI: urn:ietf:params:xml:ns:epp:serverValidation-0.1 Registrant Contact: IESG XML: None. Namespace URIs do not represent an XML specification. Registration request for the serverValidation XML schema: URI: urn:ietf:params:xml:schema:epp:serverValidation-0.1 Registrant Contact: IESG XML: See the "Formal Syntax" section of this document.

The EPP extension described in this document should be registered by the IANA in the EPP Extension Registry described in . The details of the registration are as follows: Name of Extension: "Server Validation Extension for the Extensible Provisioning Protocol (EPP)" Document status: Standards Track Reference: (insert reference to RFC version of this document) Registrant Name and Email Address: IESG, <iesg@ietf.org> TLDs: Any IPR Disclosure: None Status: Active Notes: None

The mapping extensions described in this document do not provide any security services beyond those described by EPP and protocol layers used by EPP. This document provides validation information that may be related to security, such as validating DNSSEC with the DNSSEC chain, algorithms, and signatures. What validation information to provide to the sponsoring and non-sponsoring client is a consideration that is up to server policy, where a server may only provide the validation failure reasons to the sponsoring client.