.[41][42]
Every command and response includes transaction identifiers for tracking: the client transaction ID (), provided by the client within the element, and the server transaction ID (), echoed back by the server in the response's element; these are mandatory to ensure reliable communication.[42]
Commands apply to specific object types—domains, hosts, and contacts—through dedicated mappings that define the parameters and semantics for each category, allowing uniform operation across different registry objects while maintaining protocol consistency.[43]
Object Mappings and Operations
The Extensible Provisioning Protocol (EPP) defines mappings for core objects—domains, hosts, and contacts—that enable the provisioning and management of Internet resources in a shared central repository. These mappings specify the XML-based structure of each object and the operations supported on them, ensuring standardized interactions between clients and servers. The domain mapping handles Internet domain names, the host mapping manages IP address associations for nameservers, and the contact mapping provisions individual or organizational social information.[1][4][44][2]
Domain Object
The domain object represents an Internet domain name stored in a registry and includes attributes such as the domain name itself, a registrant (referencing a contact object ID), status descriptors (e.g., "ok" for active or "pendingTransfer" for transfers in progress), nameservers (list of host object references), subordinate hosts, and client identifiers for sponsoring, creating, and updating entities.[45] Operations on domain objects include creation, which requires specifying a registration period (1 to 99 units of years or months) and optional nameservers; querying via the command to retrieve details, optionally filtered by authorization information; updating to add, remove, or change elements like status, nameservers, or registrant contacts; deletion, which verifies no subordinate hosts exist; renewal to extend the registration period by providing the current expiry date; and transfer, which initiates or approves a change in sponsorship using a period and authorization code.[46] For example, creating a domain might involve XML elements like <domain:create><domain:name>[example.com](/page/Example.com)</domain:name><domain:period unit="y">2</domain:period><domain:ns><domain:hostObj>ns1.[example.com](/page/Example.com)</domain:hostObj></domain:ns></domain:create>.[47]
Host Object
The host object encapsulates an Internet host name, typically used for nameserver delegation, with attributes including the fully qualified host name (conforming to RFC 952 and RFC 1123), IP addresses (IPv4 per RFC 791 or IPv6 per RFC 4291), status (e.g., "ok" or "clientDeleteProhibited"), and client identifiers.[48] Supported operations encompass creation with the host name and optional IP addresses for glue records; querying to obtain host details; updating to add, remove, or modify addresses, status, or even rename the host; and deletion, permitted only if the host is not associated with any domain.[49] Hosts serve as nameservers in domain delegations, distinguishing between external hosts (outside the domain) and internal subordinate hosts (within it), where IP addresses are mandatory only for delegation purposes.[50] An example update might add an IPv4 address via <host:update><host:add><host:addr ip="v4">192.0.2.1</host:addr></host:add></host:update>.[51]
The contact object stores social information for individuals or organizations, featuring a server-unique ID, name, optional organization, postal address (street, city, state/province, code, country in international or localized formats), email (per RFC 5322), voice and fax numbers (per ITU E.164), status (e.g., "linked" indicating association with a domain or "ok"), and disclosure preferences for privacy.[52] Operations include creation, mandating all contact details like name and address; querying with optional authorization info to fetch the full object; updating to modify any element, including status or adding privacy redactions; and deletion, allowed only if unlinked from other objects.[53] Privacy is managed through the element, which can redact fields like email or address from public WHOIS queries while keeping them server-available.[54] For instance, a create command might specify <contact:create><contact:postalInfo type="int"><contact:addr><contact:street>123 Example St</contact:street></contact:addr></contact:postalInfo><contact:email>[email protected]</contact:email></contact:create>.[55]
These object mappings are formally defined in RFC 5731 for domains, RFC 5732 for hosts, and RFC 5733 for contacts, with interdependencies ensuring domains reference valid contact objects as registrants and host objects as nameservers, while hosts and contacts can be subordinate to domains—preventing deletions if linkages persist.[45][50][56] Operations utilize EPP's general command framework, such as and , tailored to each object's schema.[1]
Practical Usage
Session Management
The Extensible Provisioning Protocol (EPP) establishes client-server sessions through the <login> command, which must be the first command sent after establishing a transport-layer connection, such as TCP on port 700.[57][58] This command includes a client identifier (<clID>, 3 to 16 characters) and a case-sensitive password (<pw>, 6 to 16 characters), both established out-of-band, along with optional elements for password updates (<newPW>), protocol version and language negotiation (<options>), and supported services (<svcs>).[57] The <svcs> element declares object namespaces (<objURI>) and extensions (<svcExtension>) that the client intends to use, enabling namespace negotiation to align capabilities between client and server.[57][59]
Upon connection establishment, the server automatically sends an EPP greeting (<greeting>) containing its identifier (<svID>), current date and time (<svDate>), a services menu (<svcMenu>) listing supported protocol versions, languages, object namespaces, and extensions, as well as data collection policies (<dcp>).[42][58] Clients can explicitly request this greeting at any time using an empty <hello/> element to verify server status or retrieve updated information.[60] Successful authentication via <login> results in a server response with result code 1000, confirming the session and any negotiated parameters; failed attempts may lead to connection closure after multiple tries, per server policy.[57][61]
Sessions are maintained as persistent, single TCP connections that support pipelining of multiple EPP commands in a stream, allowing efficient processing without waiting for individual responses, provided the transport layer permits it.[62][58] Asynchronous notifications, such as pending domain transfer approvals, are handled via the <poll> command, where clients use op="req" to retrieve queued messages and op="ack" with a message ID to acknowledge them, ensuring reliable delivery without blocking the session.[63] Servers enforce inactivity timeouts, closing idle connections after a server-defined period to manage resources.[58]
To terminate a session, clients issue an empty <logout/> command, which the server acknowledges with result code 1500 before closing the underlying TCP connection.[64][58] Servers may also unilaterally end sessions due to prolonged inactivity, excessive longevity, or policy violations, returning an appropriate result code.[64]
EPP supports enhanced security through mutual authentication using client certificates over TLS, which supplements the primary credential-based login and protects the plaintext password in transit.[65][61] This combination ensures secure session establishment while allowing flexible namespace negotiation for protocol extensions during login.[59]
Example Transactions
The Extensible Provisioning Protocol (EPP) uses XML-formatted commands and responses to manage domain objects, with each transaction encapsulated in an <epp> root element. Common transactions illustrate the protocol's structure, including the <command> for client requests and <response> from the server, which includes result codes, data, and transaction identifiers. These examples focus on domain name mappings as defined in the EPP domain specification.[66]
Domain Creation
A domain creation transaction uses the <create> command to register a new domain object, specifying attributes such as the domain name, registration period, nameservers, and registrant contact. The command includes authorization information for security. The server responds with success (result code 1000) and creation details, including the creation date and calculated expiration date based on the period. For instance, creating "example.com" for a 1-year period on November 14, 2025, would yield an expiration of November 14, 2026.[66]
Command Example:
xml
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
<command>
<create>
<domain:create xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"
xmlns:contact="urn:ietf:params:xml:ns:contact-1.0">
<domain:name>[example.com](/page/Example.com)</domain:name>
<domain:period unit="y">1</domain:period>
<domain:ns>
<domain:hostObj>ns1.example.net</domain:hostObj>
<domain:hostObj>ns2.example.net</domain:hostObj>
</domain:ns>
<domain:registrant>jd1234</domain:registrant>
<domain:contact type="admin">sh8013</domain:contact>
<domain:contact type="tech">sh8013</domain:contact>
<domain:authInfo>
<domain:pw>2fooBAR</domain:pw>
</domain:authInfo>
</domain:create>
</create>
<clTRID>ABC-12345</clTRID>
</command>
</epp>
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
<command>
<create>
<domain:create xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"
xmlns:contact="urn:ietf:params:xml:ns:contact-1.0">
<domain:name>[example.com](/page/Example.com)</domain:name>
<domain:period unit="y">1</domain:period>
<domain:ns>
<domain:hostObj>ns1.example.net</domain:hostObj>
<domain:hostObj>ns2.example.net</domain:hostObj>
</domain:ns>
<domain:registrant>jd1234</domain:registrant>
<domain:contact type="admin">sh8013</domain:contact>
<domain:contact type="tech">sh8013</domain:contact>
<domain:authInfo>
<domain:pw>2fooBAR</domain:pw>
</domain:authInfo>
</domain:create>
</create>
<clTRID>ABC-12345</clTRID>
</command>
</epp>
Response Example:
xml
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
<response>
<result code="1000">
<msg>Command completed successfully</msg>
</result>
<resData>
<domain:creData xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
<domain:name>[example.com](/page/Example.com)</domain:name>
<domain:crDate>2025-11-14T00:00:00.0Z</domain:crDate>
<domain:exDate>2026-11-14T00:00:00.0Z</domain:exDate>
</domain:creData>
</resData>
<trID>
<clTRID>ABC-12345</clTRID>
<svTRID>54321-XYZ</svTRID>
</trID>
</response>
</epp>
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
<response>
<result code="1000">
<msg>Command completed successfully</msg>
</result>
<resData>
<domain:creData xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
<domain:name>[example.com](/page/Example.com)</domain:name>
<domain:crDate>2025-11-14T00:00:00.0Z</domain:crDate>
<domain:exDate>2026-11-14T00:00:00.0Z</domain:exDate>
</domain:creData>
</resData>
<trID>
<clTRID>ABC-12345</clTRID>
<svTRID>54321-XYZ</svTRID>
</trID>
</response>
</epp>
[66]
Transfer Query
To query the transfer status of a domain, the <transfer> command with op="query" is used, including the domain name and authorization code (password) to verify the requester's rights. The response provides the transfer status (e.g., pending), requesting and acting client identifiers, relevant dates, and the domain's expiration date. This allows clients to monitor ongoing transfers without initiating a new one.[66]
Command Example:
xml
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
<command>
<transfer op="query">
<domain:transfer xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
<domain:name>[example.com](/page/Example.com)</domain:name>
<domain:authInfo>
<domain:pw>2fooBAR</domain:pw>
</domain:authInfo>
</domain:transfer>
</transfer>
<clTRID>ABC-12346</clTRID>
</command>
</epp>
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
<command>
<transfer op="query">
<domain:transfer xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
<domain:name>[example.com](/page/Example.com)</domain:name>
<domain:authInfo>
<domain:pw>2fooBAR</domain:pw>
</domain:authInfo>
</domain:transfer>
</transfer>
<clTRID>ABC-12346</clTRID>
</command>
</epp>
Response Example:
xml
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
<response>
<result code="1000">
<msg>Command completed successfully</msg>
</result>
<resData>
<domain:trnData xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
<domain:name>[example.com](/page/Example.com)</domain:name>
<domain:trStatus>pending</domain:trStatus>
<domain:reID>ClientX</domain:reID>
<domain:reDate>2025-06-06T22:00:00.0Z</domain:reDate>
<domain:acID>ClientY</domain:acID>
<domain:acDate>2025-06-11T22:00:00.0Z</domain:acDate>
<domain:exDate>2026-09-08T22:00:00.0Z</domain:exDate>
</domain:trnData>
</resData>
<trID>
<clTRID>ABC-12346</clTRID>
<svTRID>54322-XYZ</svTRID>
</trID>
</response>
</epp>
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
<response>
<result code="1000">
<msg>Command completed successfully</msg>
</result>
<resData>
<domain:trnData xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
<domain:name>[example.com](/page/Example.com)</domain:name>
<domain:trStatus>pending</domain:trStatus>
<domain:reID>ClientX</domain:reID>
<domain:reDate>2025-06-06T22:00:00.0Z</domain:reDate>
<domain:acID>ClientY</domain:acID>
<domain:acDate>2025-06-11T22:00:00.0Z</domain:acDate>
<domain:exDate>2026-09-08T22:00:00.0Z</domain:exDate>
</domain:trnData>
</resData>
<trID>
<clTRID>ABC-12346</clTRID>
<svTRID>54322-XYZ</svTRID>
</trID>
</response>
</epp>
[66]
Update
The <update> command modifies an existing domain object by adding, removing, or changing elements such as statuses, nameservers, or contacts. It uses <add>, <rem>, and <chg> sub-elements to specify the changes precisely. The server responds with a success code but no result data unless an extension requires it, confirming the update without returning the full object state. For example, adding a "clientHold" status prevents DNS resolution due to issues like overdue payments.[66]
Command Example:
xml
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
<command>
<update>
<domain:update xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
<domain:name>example.com</domain:name>
<domain:add>
<domain:status s="clientHold" lang="en">Payment overdue.</domain:status>
</domain:add>
</domain:update>
</update>
<clTRID>ABC-12347</clTRID>
</command>
</epp>
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
<command>
<update>
<domain:update xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
<domain:name>example.com</domain:name>
<domain:add>
<domain:status s="clientHold" lang="en">Payment overdue.</domain:status>
</domain:add>
</domain:update>
</update>
<clTRID>ABC-12347</clTRID>
</command>
</epp>
Response Example:
xml
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
<response>
<result code="1000">
<msg>Command completed successfully</msg>
</result>
<trID>
<clTRID>ABC-12347</clTRID>
<svTRID>54323-XYZ</svTRID>
</trID>
</response>
</epp>
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
<response>
<result code="1000">
<msg>Command completed successfully</msg>
</result>
<trID>
<clTRID>ABC-12347</clTRID>
<svTRID>54323-XYZ</svTRID>
</trID>
</response>
</epp>
[66]
Error Handling
EPP transactions include robust error responses when commands fail validation, such as missing required parameters, which returns result code 2003. The response structure identifies the error code, a descriptive message, and optionally the specific invalid or missing element via a <value> tag, allowing clients to correct and retry. This ensures protocol compliance without exposing sensitive server details.[67]
Response Snippet Example (for code 2003):
xml
<response>
<result code="2003">
<msg lang="en">Required parameter missing</msg>
<value xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
<domain:name/>
</value>
</result>
<trID>
<clTRID>ABC-12348</clTRID>
<svTRID>54324-XYZ</svTRID>
</trID>
</response>
<response>
<result code="2003">
<msg lang="en">Required parameter missing</msg>
<value xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
<domain:name/>
</value>
</result>
<trID>
<clTRID>ABC-12348</clTRID>
<svTRID>54324-XYZ</svTRID>
</trID>
</response>
[67]
Extensions
Standardized Extensions
The Extensible Provisioning Protocol (EPP) supports a range of standardized extensions defined by the Internet Engineering Task Force (IETF) to address specific requirements beyond the core protocol, such as domain security, internationalized naming, grace period management, and enhanced transfer security. These extensions are integrated into EPP's XML-based structure, allowing clients and servers to negotiate their use during session establishment while maintaining compatibility with the base protocol. They enable more robust provisioning of domain-related objects, including delegation signer (DS) records for DNS security and additional status values for lifecycle management.[67]
One foundational standardized extension is the Domain Name System (DNS) Security Extensions (DNSSEC) mapping, which facilitates the provisioning and management of DNSSEC key data associated with domain names. This extension supports two primary interfaces: the DS Data Interface, where clients directly provide delegation signer (DS) records, and the Key Data Interface, where servers derive DS records from provided public key data. Key elements include <secDNS:dsData> for DS records (with attributes like key tag, algorithm, digest type, and digest value) and <secDNS:keyData> for key pairs (including flags, protocol, algorithm, and public key). In the <create> command, clients can include <secDNS:create> to associate initial DNSSEC data with a new domain, such as a DS record example: <secDNS:dsData><keyTag>12345</keyTag><alg>3</alg><digestType>1</digestType><digest>49FD46E6C4B45C55D4AC</digest></secDNS:dsData>. Updates via <secDNS:update> allow adding, removing, or changing records, with an optional maxSigLife element to specify signature validity periods in seconds and an urgent attribute for priority processing.[68]
Support for internationalized domain names (IDNs) is standardized within the EPP domain name mapping, requiring domain names to be represented in Punycode (ASCII-compatible encoding) as per IDNA specifications, ensuring seamless handling of non-ASCII scripts without a separate extension namespace. This core integration allows EPP clients to provision IDNs by submitting Punycode-encoded labels in commands like <create> and <update>, with the protocol validating them against host name rules from RFC 952 and RFC 1123. For example, an IDN like "café.example" is transmitted as "xn--caf-dma.example", preserving backward compatibility with ASCII-only systems.[66]
The Domain Registry Grace Period (RGP) extension introduces mechanisms to manage domain names under grace period policies, particularly for deletions and restorations. It defines new status values such as pendingDelete (indicating a deletion request is pending), redemptionPeriod (a post-deletion phase where restoration is possible), and pendingRestore (during the restoration process). Upon deletion, a domain transitions to pendingDelete and enters the redemption grace period, allowing registrars to reverse the action via an <update> command that includes a restore report; successful restoration returns the domain to ok status, while failure leads to purging after the pending delete period. This extension ensures compliance with registry policies by extending the core domain status framework.[69]
More recent standardized extensions address evolving needs in security and internationalization. The secure authorization information for transfer extension enhances transfer operations by replacing long, static authorization passwords with short-lived, high-entropy random values (at least 128 bits, such as 20 printable ASCII characters), which are hashed (e.g., using SHA-256 with a salt) for storage and automatically expire after a registrar-defined time-to-live (TTL). These values are generated securely and used only during the transfer process, transmitted over encrypted channels to prevent interception.[70]
The unhandled namespaces extension provides a way for EPP servers to convey information from unsupported namespace URIs without failing the entire response, using an <extValue> element to relocate data from <resData> or <extension> sections. This maintains forward compatibility by converting responses to a generic EPP format, with support signaled via the namespace urn:ietf:params:xml:ns:epp:unhandled-namespaces-1.0 in the server greeting and client login. It applies to object-level extensions, command-response extensions, and poll messages, ensuring clients can process partial data.[71]
For internationalized email support, the additional email address extension allows EPP contact objects to include a secondary email field that can be either ASCII or an internationalized address per SMTPUTF8 standards, using the <addlEmail:addlEmail> element with an optional primary attribute. Clients provision this via <create> and <update> commands, retrieve it through <info>, and apply disclosure rules from the primary email; the extension is negotiated using the namespace urn:ietf:params:xml:ns:epp:addlEmail-1.0. This addresses limitations in the core EPP contact mapping, which previously supported only ASCII emails.[72]
The DNS Time-to-Live (TTL) values extension, specified in RFC 9803 (June 2025), enables clients to provision and manage TTL values for DNS resource records associated with domain and host objects. It introduces elements like <ttl:create> and <ttl:info> to set and query TTLs, supporting defaults and updates to optimize DNS query performance and caching.[10]
The strict bundling extension (RFC 9095, July 2025) supports the registration of variant domain names as a single bundled unit, particularly for internationalized domain names (IDNs), to prevent fragmentation and ensure consistent management of related labels across scripts. Registries use this to enforce policies requiring simultaneous provisioning of variants.[73]
All standardized extensions are declared during session initiation through the <login> command's <svcs> element, where clients specify supported namespace URIs in <svcExtension><extURI> to match those announced by the server in the initial <greeting>. This negotiation ensures only compatible extensions are used, with servers required to support core EPP commands regardless of extension availability, providing inherent backward compatibility for clients lacking extension support.[67]
Custom Extensions
Custom extensions in the Extensible Provisioning Protocol (EPP) enable domain registries to address unique operational needs beyond the core protocol and IETF-standardized features, allowing for tailored data collection, policy enforcement, and functionality specific to individual top-level domains (TLDs). These extensions are developed independently by registries and are not part of the official IETF specifications, making them proprietary implementations that must adhere to EPP's extensibility guidelines to maintain compatibility. Registries define custom extensions to support local regulatory requirements or business models, such as collecting specialized registrant information or applying TLD-specific rules during domain provisioning.[74]
A prominent example of custom extensions involves TLD-specific data requirements. The .eu registry, managed by EURid, utilizes a custom contact extension to mandate the collection of VAT identification numbers for EU-based entities, ensuring compliance with European value-added tax regulations during domain registration and updates. Likewise, the .uk registry, operated by Nominet, employs extensions like contact-nom-ext-1.0.xsd to handle UK-specific address formats and organization types (e.g., "Ltd."), validating and structuring contact data to align with national standards. Registries may also build on standardized frameworks for bespoke purposes, such as using the registry fee extension outlined in RFC 8748 to implement unique pricing structures, including refunds, grace periods, and operation-specific costs tailored to their TLD economics.[73][75][76]
Implementation of custom extensions follows EPP's XML-based framework, where new elements and attributes are defined using unique namespaces to encapsulate extension-specific data without conflicting with core protocol structures. For instance, an extension namespace URI is declared in the element of EPP commands and responses, allowing parsers to process additional payloads while preserving backward compatibility; registries must document these namespaces, schemas, and usage rules in their technical specifications for registrars to integrate properly. This approach ensures that core EPP commands remain intact, with extensions appearing as optional, self-contained modules that do not alter mandatory protocol flows. Custom extensions reference namespace handling mechanisms akin to those in standardized extensions, promoting modular design.[74][67]
Despite their flexibility, custom extensions introduce challenges, particularly in interoperability across diverse registry environments. Registrars often face difficulties integrating multiple proprietary extensions, as variations in schema definitions and validation logic can lead to compatibility issues with existing EPP clients and servers, complicating multi-TLD operations. To mitigate these, registries emphasize thorough documentation and testing; tools like ICANN's EPP Selftest Tool provide conformance validation by simulating XML transformations and command responses, helping registrars verify extension support before deployment. Verisign, a major registry operator, has noted that the proliferation of such extensions creates implementation burdens for registrars, underscoring the need for clear guidelines to balance innovation with ecosystem-wide consistency.[77][78]
Response Handling
Result Codes
The Extensible Provisioning Protocol (EPP) employs numeric result codes to indicate the outcome of commands sent from clients to servers, providing a standardized way to signal success or failure without relying solely on textual descriptions. These codes are four-digit integers embedded within the <result> element of an EPP response, as defined in the core protocol specification.[1]
Success result codes confirm that a command has been processed correctly by the server. The code 1000 signifies "Command completed successfully," indicating that the requested action has been fully executed without issues. Similarly, 1001 denotes "Command completed successfully; action pending," which is used when the command succeeds but requires additional offline processing, such as asynchronous updates to external systems. Both codes are part of the foundational set outlined in the EPP protocol.[1]
Client errors, in the 2000-2999 range, arise from issues in the command submitted by the client, such as malformed syntax or invalid parameters. Code 2000 represents "Unknown command," returned when the server encounters an unrecognized command name. Code 2003 indicates "Required parameter missing," triggered if essential elements of the command are absent. Code 2004 signals "Parameter value range error," occurring when a provided parameter falls outside the acceptable range defined by the protocol or object mappings. Code 2200 indicates "Authentication error," used when authentication of the client fails. These codes help clients identify and correct input errors promptly.[1]
Server errors are primarily in the 5000-5999 range for protocol or internal issues, though some 2xxx codes like 2400 ("Command failed") and 2500 ("Command failed; server closing connection") reflect server-side problems. Code 2400 means a command failed due to an internal server error. Code 2500 indicates "Command failed; server closing connection," a more severe error that results in the termination of the current session, usually for non-recoverable issues. These codes allow servers to communicate internal failures while maintaining protocol interoperability.[1]
Result codes are always accompanied by a human-readable message in the <msg> element of the response, which provides explanatory text in English by default (with support for other languages via the lang attribute) to aid debugging and user interaction. While the core set of result codes is specified in RFC 5730, the protocol allows extensions to define additional codes for specialized functionalities, ensuring flexibility across different registry implementations.[1]
Object Status Codes
In the Extensible Provisioning Protocol (EPP), object status codes represent the state of provisioned objects such as domains, hosts, and contacts, controlling their lifecycle stages and operational prohibitions. These statuses are managed through the protocol's transform commands and are reported in query responses to reflect current permissions and pending actions.[1] Server-managed statuses indicate the object's overall viability and server-initiated holds, while client-set statuses impose restrictions to prevent unauthorized changes.[4]
Server statuses include "ok," which denotes an active object with no pending operations or prohibitions; "inactive," applicable primarily to domains when no delegation information is present; "pendingDelete," which enters a grace period following a delete request during which restoration is possible; "pendingTransfer," signaling an in-process transfer; and "serverHold," which withholds DNS publication for domains without affecting other operations.[4] These are set exclusively by the server, often in response to asynchronous events or policy enforcement, and cannot be directly modified by clients.[4] For example, a domain in "pendingDelete" status remains queryable but cannot be updated or transferred until the grace period resolves.[4]
Client statuses, prefixed with "client," are prohibitions that block specific actions to protect against errors or disputes: "clientDeleteProhibited" prevents deletion, "clientUpdateProhibited" blocks modifications, "clientTransferProhibited" inhibits transfers, and "clientRenewProhibited" (domain-specific) disallows renewals.[4] These are applied by sponsoring clients via the <update> command, using <add> or <rem> elements to include or exclude status values from the object's status list.[4] Servers may override client statuses based on policy, but clients cannot alter server-imposed ones.[4]
Status combinations follow strict rules to ensure logical consistency: the "ok" status cannot coexist with any other; pending statuses like "pendingDelete" are incompatible with their corresponding prohibitions (e.g., "pendingDelete" with "clientDeleteProhibited"); and multiple pending statuses cannot combine.[4] Every EPP object must have at least one status value at all times.[4] For domains, the redemption process extends the lifecycle: after the initial 0-75 day grace period in "pendingDelete," a 30-day redemption grace period begins, during which a "pendingRestore" status is added upon restore request, allowing full recovery with a required restore report.[69]
Object-specific variations exist across EPP mappings. Domains support the full set, including "pendingRestore" and renewal-related prohibitions via the grace period extension.[4] Host objects, subordinate to domains, include "linked" (indicating association) alongside "ok," but lack hold or renewal statuses, with transfers handled implicitly through domains.[44] Contact objects similarly feature fewer options, omitting "clientHold," "clientRenewProhibited," and delegation-related statuses like "inactive," focusing instead on basic prohibitions and linkages to other objects.[2]
| Category | Status Examples | Purpose | Applicable Objects |
|---|
| Server-Managed | ok, pendingDelete (serverHold for domains only) | Lifecycle state and server prohibitions | All (domains, hosts, contacts); serverHold limited to domains |
| Client-Set | clientDeleteProhibited, clientTransferProhibited | Client-initiated action blocks | All, with domain-specific additions like clientRenewProhibited |
| Pending | pendingTransfer, pendingRestore | Asynchronous operations | Domains (full set); hosts/contacts (subset, no pendingRestore) |
<update> operations from the core mappings, enabling precise control over object evolution without introducing new commands.[1]
Security Considerations
Authentication Mechanisms
The primary authentication mechanism in the Extensible Provisioning Protocol (EPP) relies on a plaintext password provided within the <login> command to verify client identity.[1] This password, of type pwAuthInfoType, must be a string between 6 and 16 characters in length and is case-sensitive, with initial credentials typically established out-of-band before the first session.[79] Clients can update their password during login using the optional <newPW> element or, for contact objects, via the <update> command in the EPP contact mapping, which allows modification of authentication details associated with individual or organizational contacts.[80] Servers may enforce policies such as limiting the number of consecutive failed login attempts to prevent brute-force attacks, though the exact limits are implementation-specific.[57]
To enhance security beyond basic password authentication, EPP implementations commonly incorporate client certificates based on X.509 standards for mutual Transport Layer Security (TLS) authentication.[81] In this approach, optionally supported by the EPP transport over TCP mapping, both the client and server may present certificates during the TLS handshake to establish mutual identity verification before any EPP commands are processed, ensuring strong client-server authentication at the transport layer.[81] Additionally, many EPP servers implement IP address whitelisting as a supplementary measure, restricting access to predefined client IP addresses or ranges to further validate session origins and mitigate unauthorized connections.[82]
For authorizing object transfers, such as domains or contacts, EPP employs per-object authorization information via the <authInfo> element, often manifested as an authorization code or password unique to the object.[83] This code must be provided in the <transfer> command to confirm the requester's authority, with servers typically generating it as a secret value shared out-of-band with the object owner. To address vulnerabilities in traditional authorization codes, RFC 9154 introduces secure, token-based authorization information that emphasizes high-entropy, short-lived random values (at least 128 bits of entropy) for transfers.[84] Servers store these tokens using cryptographic hashing (e.g., SHA-256 with a 128-bit salt) to protect against exposure, while clients provide the plaintext token during the transfer request for verification.[85]
EPP login and authorization passwords are transmitted in plaintext without built-in hashing, placing reliance on underlying TLS for confidentiality and integrity protection during transit.[65] The base protocol limits password length to 16 characters, but the login security extension defined in RFC 8807 enables longer passwords (minimum 6 characters, maximum per server policy) to support higher entropy and improved resistance to guessing attacks, while also allowing international characters via the PRECIS framework for broader usability.[86] This extension further incorporates security event notifications in login responses, such as warnings for impending password expiration, to promote proactive credential management.[87]
Transport and Data Protection
The Extensible Provisioning Protocol (EPP) operates over Transmission Control Protocol (TCP) using the IANA-assigned port 700 for server listening, establishing a single persistent connection between client and server for the duration of a session.[88] This mapping ensures reliable, ordered delivery of EPP commands and responses, with the session terminating upon explicit logout or connection closure.[88]
Security for transport is enforced through mandatory use of Transport Layer Security (TLS), initiated by the client immediately after the TCP connection via a ClientHello message, providing confidentiality, integrity, and mutual authentication without support for unencrypted fallback in the core protocol.[88] RFC 5734 specifies compatible TLS versions 1.0, 1.1, and 1.2 with cipher suites such as TLS_RSA_WITH_AES_128_CBC_SHA, but these have been superseded by broader recommendations deprecating TLS 1.0 and 1.1 due to known vulnerabilities like POODLE and BEAST, mandating at least TLS 1.2 as the minimum and strongly preferring TLS 1.3 for its elimination of legacy features, mandatory forward secrecy, and resistance to downgrade attacks.[88][89] Post-2020 guidance, including ICANN's Registry Service Provider Handbook referencing RFC 9325, aligns EPP implementations with these updates to mitigate evolving threats.[90][89] As of November 2025, ongoing standardization efforts include Internet-Drafts for mapping EPP over HTTPS (draft-ietf-regext-epp-https) and over QUIC (draft-ietf-regext-epp-quic-02), which leverage modern TLS 1.3 for enhanced security and performance.[8][9]
Data protection in EPP primarily relies on the TLS layer for end-to-end encryption and tamper detection, with additional safeguards against replay attacks provided by unique transaction identifiers (TRIDs)—comprising client-generated and server-assigned elements—that ensure command-response pairing and idempotency, preventing duplicate processing.[67] Timestamps, such as the server's current UTC date in greetings () and enqueued message dates in poll responses (), further enable freshness checks to discard stale or replayed messages.[67] XML digital signing remains optional and is not defined in the base protocol, though it may be implemented via extensions for enhanced non-repudiation where needed.[67]
Common vulnerabilities like man-in-the-middle (MITM) attacks are mitigated through strict TLS certificate validation, requiring clients to verify server identity via out-of-band mechanisms such as pre-shared certificate fingerprints or trusted certificate authorities before proceeding.[88] Denial-of-service (DoS) threats, including connection flooding, are countered by server-enforced limits on concurrent connections and command rates, alongside TLS-level protections against resource-intensive handshakes.[88] While the protocol assumes layered defenses for broader threats, these measures collectively reduce exposure in typical deployments.[88]
Best practices for operational security emphasize server-side logging of non-sensitive elements like TRIDs and result codes to audit sessions without capturing credentials or personal data, facilitating troubleshooting while minimizing privacy risks.[67] For EPP objects containing contact information—such as names, addresses, and emails handled via the contact mapping—implementations must adhere to data protection regulations like the EU's General Data Protection Regulation (GDPR), ensuring consent-based processing, data minimization, and secure storage to protect registrants' rights.[91]
Core EPP RFCs
The core Extensible Provisioning Protocol (EPP) is defined by a set of five interrelated Request for Comments (RFC) documents published in 2009, collectively known as STD 69. These RFCs establish the foundational protocol specifications for EPP, including its command structures, object mappings for domain names, hosts, and contacts, and transport mechanisms. They obsolete the earlier experimental RFC 3730 series (published in 2004) and the proposed standard RFC 4930 series (published in 2007), incorporating refinements based on implementation experience to achieve full Internet Standard status.[92]
RFC 5730 specifies the EPP core protocol, defining the extensible XML-based client-server communication framework for provisioning and managing objects in a shared central repository. It outlines essential commands such as greeting, login, logout, and query operations, along with response formats, error handling, and extensibility provisions to support additional features without breaking compatibility. This document ensures EPP's application-layer neutrality, allowing mappings to various transport layers while emphasizing security and internationalization support.[1]
RFC 5731 provides the domain name mapping, enabling EPP clients to create, update, transfer, renew, and delete Internet domain name objects within a registry. It details domain-specific elements like name servers, status flags, and registration periods, while integrating with the core protocol's command-response model to facilitate automated registrar interactions. This mapping is critical for managing top-level and second-level domains in a standardized manner.[4]
RFC 5732 defines the host mapping for provisioning Internet Protocol (IP) address delegations associated with domain names. It supports operations to create, update, and query host objects, including IP address specifications (IPv4 and IPv6) and delegation to domains, ensuring consistent representation of name server configurations across registries. This facilitates the linkage between domain and infrastructure objects in EPP sessions.[44]
RFC 5733 describes the contact mapping for handling personal and organizational information linked to domain registrations. It covers commands to create, update, and manage contact objects, incorporating data elements such as names, addresses, telephone numbers, and email addresses, with provisions for privacy and internationalized labels. This mapping ensures compliant storage and retrieval of registrant details in a privacy-sensitive environment.[2]
RFC 5734 specifies the transport over Transmission Control Protocol (TCP) secured by Transport Layer Security (TLS), mapping EPP sessions onto reliable, encrypted connections. It details connection establishment, data streaming, and graceful closure procedures, mandating TLS 1.0 or higher for confidentiality and integrity, while allowing for future transport alternatives. This transport layer is the primary mechanism for EPP deployments in production environments.[6]
Extension and Mapping RFCs
The Extensible Provisioning Protocol (EPP) has been extended through various Request for Comments (RFCs) to address specific operational needs, such as grace periods, security enhancements, and specialized object mappings, building upon the foundational protocol defined in core RFCs. Early extensions focused on domain lifecycle management and security features. For instance, RFC 3915, published in September 2004, introduces an EPP extension mapping for handling domain registry grace periods, including redemption grace periods that allow restoration of deleted domains under specific conditions.[69] Similarly, RFC 5910, issued in May 2010, specifies an EPP extension for provisioning and managing Domain Name System Security (DNSSEC) key material, enabling secure delegation of DNSSEC signing authority.[23]
More recent extensions have addressed evolving registry operations and interoperability challenges. RFC 9167, from December 2021, defines an EPP extension for registry maintenance notifications, allowing servers to inform clients of scheduled downtime or events via query and notification mechanisms. RFC 9038, also published in May 2021, establishes an operational practice for handling unhandled namespace URIs in EPP messages, permitting servers to return associated data without full extension support.[24] In the area of secure transfers, RFC 9154, dated December 2021, outlines practices for using strong, random authorization information in EPP transfers to enhance security while keeping values manageable in length.[93] Advancing internationalization, RFC 9873, released in October 2025, provides an extension for adding a secondary email address to EPP contact objects, supporting both internationalized and ASCII-only formats. Additionally, RFC 9874, from September 2025 and designated as Best Current Practice (BCP) 244, details recommended practices for deleting domain and host objects in EPP, including renaming and purging to mitigate risks like domain sniping.[94]
Mapping updates have refined EPP's application to specific object types and policies. RFC 9095, published in July 2021, extends the EPP domain name mapping to support strict bundling registrations, where variant domain names are registered as a single unit to preserve their integrity. RFC 8748, from March 2020, introduces a registry fee extension for EPP, enabling servers to communicate applicable fees, credits, and grace periods for transactions involving domains, hosts, or contacts.
EPP RFCs also evolve through obsoletions to incorporate updates and clarifications. For example, RFC 5731, published in August 2009, obsoletes RFC 4931 by providing an updated EPP mapping for domain name provisioning and management, with improved XML syntax and command semantics.[4] This process ensures ongoing alignment with protocol advancements while maintaining backward compatibility where possible.[4]