How EPP works?

EPP (Extensible Provision Protocol) defines an unified way how registrars can communicate with registries of domain names by exchanging XML messages.

EPP is typically implemented as an API between the registrar’s web interface and the Registry. Such integration allows the registrar to react immediately to requests from its clients and know for sure if the action succeeded or not. Should some action, such as registration of a domain name, to be put off until later, the registry will notify the registrar with the service message.

What benefits are from using EPP?

  • Once a client software is implemented, it becomes easier to integrate it with other registries and offer a wider range of top-level domain names to your clients.
  • Requests from your clients can be performed automatically and 24/7

EPP overview

  • A typical EPP conversation starts when the client connects to the server using SSL.
  • Server responds with a “service menu” with offered services and extensions available languages etc.
  • Client logs in using it’s account name and password and chooses services and other options for conversation from the offered ones.
  • Client polls the server for unread notifications and retrieves them if any.
  • Client reads details, creates new or updates existing contact persons, domain names and associated networks as needed. The server responds immediately with a well-defined response code, reflecting the status of the requested object.
  • Client waits for new things to be done, periodically polling for notification messages to keep the session alive.
  • Connection is ended either by the client when all is said and done or by the server if session timeouts.

Although EPP protocol describes both synchronous and asynchronous operation modes, we currently offer EPP service only in synchronous mode (client receives answer for each request and only then sends next command to our server).

Client request

The format of the EPP command and it’s elements are described in detail in section 2.5 of RFC-5730.

Each request from the client (excluding the hello command) may be marked with a client transaction ID (clTRID) value, generated by the client software and being unique for a session.

They are optional according to EPP, but please, use them at least for the object manipulation requests.

Server response

Section 2.6 of RFC-5730 describes the general format of server response and elements it may include. Please, see corresponding sections in our documentation the learn what response to expect from our server on each command.

Note

if an error response includes XML fragment from the client request, it’s namespace prefixes could be different from the original ones (e.g., <ns2:name> instead of <domain:name>)

Data model specifics

Each registrar has a few special contact objects associated:

  • a registrar’s primary person - a legal entity, representing the registrar which is used as a billing contact for all domain names, managed by that registrar.
  • one or more hostmaster contacts (private persons). One of them (the first one created, if not stated otherwise) is a default technical contact for registrar-managed domain names.
  • Each domain name should have also a registrant (a.k.a. holder) and a single administrative contact

Due to differences in the data model, host object mapping, specified RFC 5732 is not implemented - hosts exist only as attributes of domain names and cannot be manipulated as standalone registry objects. So, everywhere domain:hostAttr should used instead of domain:hostObj.

Object identification

Every registrar is assigned a server unique client ID, to be used as a login name for the EPP service.

EPP requires that each domain and contact object also have a globally-unique repository object identifier (ROID), consisting of a local part, a hyphen “-” and a registry suffix. How is it formed?

  • DOM-example_domain_edu_lv-LVNIC for domains - local part is the domain name where dashes and dots are replaced with underlines
  • CNT-100023-LVNIC for contacts, where CNT denotes object type, followed by a number, internal to the server.

Instead of the ROID, in EPP requests and responses each domain and contact object is referred by their local name (also called an object handle):

  • domains are identified by the full domain name in ACE-encoded form
  • contact objects are identified by their contact handle, constructed from the first symbols of contact name, creation date and time (e.g. “nordea1105-23500”)

Sponsorship

In EPP terminology, the sponsoring client of a domain name is the registrar who manages that domain name. All contact objects that are contact persons for a domain are “owned” by the registrar “sponsoring” that domain (terms “owns” and “manages” both are used in the documentation to name “sponsorship” over an object as the EPP protocol calls it). Should the same person have a role (e.g. holder or administrative contact) for several domain names, managed by different registrars, an independent copy of it’s data would be made for each registrar.

Network records, associated with domains, are not separate objects, and so are available only to the registrar managing domain names they are assigned to.

Registrar change is possible only for domain names and for all objects, only their owner can modify them and see their details.