25 Extensible Provisioning Protocol (EPP)

Prototypical answer:

gTLDFull Legal NameE-mail suffixDetail
.suzukiSUZUKI MOTOR CORPORATIONgmoregistry.comView

1. Overview

Extensible Provisioning Protocol (EPP) is the industry standard interface for managing registrations between a registry and its registrars in a Shared Registration System (SRS). It is specified in a series of IETF RFCs.

EPP, in summary, consists of a generic XML-based protocol framework (RFC 5730) that specifies the high level commands that are generally useful in the provisioning of registry objects, as well as an extension mechanism for managing various classes of registry objects. Extensions that prescribe the use of certain object classes are commonly referred to as “mappings”. Of particular interests to gTLD registries and registrars are: domain name mapping (RFC 5731), host mapping (RFC 5732), contact mapping (RFC 5733), grace periods mapping (RFC 3915), and DNSSEC mapping (RFC 5910.)

The framework was designed to decouple content from the underlying network transport, so that the same XML serialization format and protocol flow may be carried by different underlying transports such as TCP, SMTP, HTTP. By far, the most commonly used transport is Transport Layer Security (TLS) over TCP as specified in RFC 5734.

GMO Registry (backend registry)’s implementation of EPP is fully compliant with RFCs 5730, 5731, 5732, 5733, 5734, 3915 and 5910. In addition, custom extensions are compliant with RFC 3735.

2. Architecture

CRMP employs a multi-tiered EPP service architecture to achieve fault tolerance, availability, scalability and security. The EPP service is logically separated into Front End Servers and Back End Application Servers. This architecture provides several benefits:
better resource utilization - each component can be scaled independently according to its respective load profile
risk isolation - decoupled components communicating via well-defined interfaces minimizes the exposure in cases such as fault or compromise of one component
fault tolerance - redundant load-balanced instances presents no single point of failure
high availability - back end application servers can be restarted or taken out of rotation without affecting registrar connections

The following diagram depicts the stated architecture of the EPP service comprising Front End EPP Servers and Back End Application Servers.

EPP and Application Servers Architecture

![attached: 25_1.png](⁄25_1.png)

2.1. Front End Servers

Externally, it offers a standards-compliant EPP service protected by TLS over TCP port 700. This is handled by a cluster of high-performance, lightweight front end servers whose primary functions are to encode and decode EPP frames, authenticate clients and maintain the persistent connections (authenticated sessions.)

The cluster is protected behind redundant firewalls, and is load balanced so it scales linearly with the number of servers. Each server has a capacity of 10,000 concurrent connections.

The front end servers also features additional safeguards against abuse. A maximum concurrent connections limit per registrar may be set, and also rate limits for read and write EPP transactions may be enforced.

2.2. Back End Application Servers

All commands from clients are received by the front end EPP servers and forwarded to an internal cluster of application servers using an efficient and reliable remote procedure call mechanism. The application server is armed with SRS application logic, business rules and TLD policies. Each incoming EPP command is processed and returned to the front end EPP server.

The attached diagram depicts the interaction between the EPP Server and Application Server in a typical session.

EPP and Application Servers Interaction

![attached: 25_2.png](⁄25_2.png)

The application server implements a set of fully standards-compliant EPP mappings for domains, hosts, contacts objects, as well as DNSSEC and grace period data. It implements the “hostObj” style for specifying name servers in the domain mapping (RFC 5731), which is more widely implemented in gTLD registries than the “hostAttr” alternative.

3. Interface Specification

3.1. Transport

GMO Registry will offer EPP over the most commonly used transport -- Transport Layer Security (TLS) over TCP as specified in RFC 5734.

The EPP server requires clients to present a client certificate during the TLS⁄SSL handshake phase. GMO Registry supports a list of trusted commercial certification authorities (CAs) that issue client certificates, and will make the list available to registrars.

The client certificate SHA1 fingerprint must be pre-provisioned out of band and linked to the registrar’s EPP account in the SRS database. It will be used as an additional authentication factor which, together with the client ID and password, will be validated at the time of EPP session establishment (login).

3.2. Base EPP Standards

GMO Registry fully supports the core EPP specification (RFC 5730), as well as the Domain Name Mapping (RFC 5731), Host Mapping (RFC 5732), and Contact Mapping (RFC 5733).

3.3. Extensions

In addition to the core EPP specification and the basic object mappings, GMO Registry also supports the mappings specified in the following IETF standards track RFCs.

3.3.1. RFC 3915 - Grace Period Mapping

In order to encourage interoperability and ease registrar integration to the GMO Registry SRS, the grace period mapping is fully adopted to support the domain name lifecycle. Please refer to the answers to Question 27 “Registration Lifecycle”.

3.3.2. RFC 5910 - DNSSEC Mapping

GMO Registry accepts Delegation Signer (DS) records from child zones (registered domains) over EPP using the DS Data Interface specified in RFC 5910.

3.3.3. Launch Phase Mapping

GMO Registry will adopt any formally ICANN-approved EPP extension to manage its sunrise process. Absent such an extension, GMO Registry will adopt the launch phase mapping designed by Cloud Registry to manage applications for domain names, typically during the initial phases of a gTLD launch, such as Sunrise or land rush.

It does not impact the registration lifecycle of domains as application objects are managed separately from domain objects. The relationship between application objects and domain objects are outlined below:

Name uniqueness - there may be multiple application objects for a given domain name, whereas there can only be a single domain object for a given domain name at any time.
Registration blocking - once a domain name is applied for, an application is created and at the same time the corresponding domain name is blocked from registration.
Allocation - depending on registry policies, during and at the end of a launch phase, applications will be processed and eventually allocated or cancelled. If allocated, a domain is created with information from the application. Once created, the domain has no further relationship with the application from which it was created.
Trademark validation - certain launch phases with rights protection mechanisms in place may require rights to be validated by a third party such as the Trademark Clearinghouse. In those instances, trademark related data is attached to application objects and special business rules are in place to validate them against the third party validation service.

Cloud Registry contributed the initial IETF draft to the wider ICANN community and brought the discussions to the IETF Provreg mailing list for community consensus building, with a view to take it to IETF Standards Track RFC.

This draft document is attached as ![EPP Launch Phase Mapping Internet Draft](⁄q25_draft-tan-epp-launchphase-01.pdf). Latest version of the specification will be published at http:⁄⁄tools.ietf.org⁄html⁄draft-tan-epp-launchphase or the collaborative online repository: https:⁄⁄github.com⁄cloudregistry⁄EPP-Launch-Phase-Extension-Specification

3.3.4. IDN Extension

In order to support IDN registrations carrying a language tag attribute, GMO Registry supports the EPP Extension specified in the IDN Mapping Extension for EPP, currently in draft form with the latest version available at 〈http:⁄⁄tools.ietf.org⁄html⁄draft-obispo-epp-idn〉. A copy is also attached as ![EPP IDN Mapping Internet Draft](⁄q25_draft-obispo-epp-idn-00.pdf).

4. Operations

As part of the SRS operations, the EPP service is proactively monitored to facilitate detection and reaction to fault and abuse. This also includes metrics collection that aids in capacity and load planning to ensure that ample headroom is provided in anticipation of load spikes. For more details, please consult the response to Question 42: Monitoring and Fault Escalation.

5. Resourcing Plans

The implementation and operation of the EPP service involve the following roles:
Technical Manager
Network Engineer
Applications Engineer
Database Administrator
System Architect
System Administration
Technical Support
Security Officer
Registry Administrator
Trademark Protection
QA and Process Manager

The attached table, “resource_fte.png”, outlines the overall FTE equivalent resources available to GMO Registry for the initial implementation and ongoing operations of the registry, of which the EPP service is a subset.

5.1. Current Capabilities
The registry platform is already deployed and proven in production supporting two ccTLDs. With the exception of additional policies that are specific to each ccTLD, these implementations are consistent with the specifications detailed in this document.

5.2. Initial Implementation
Initial implementation of this aspect of registry operations refers to:
allocation of network resources such as dedicated front end and backend virtual IP addresses
implementation of monitoring configurations outlined in this document that are additional to the current production monitoring setup
implement the EPP extensions outlined, of which a majority are already supported in production.

During this phase, all roles listed above are involved in the planning and implementation of their respective systems in support of this component.

5.3. Ongoing Maintenance
The ongoing maintenance of the EPP service involves:
monitoring the EPP infrastructure and service ensuring the SLA obligations of Specification 10 are met
providing technical support to registrars regarding connection or SSL handshake issues
provisioning of firewall rules according to IP subnets given by registrars
capacity planning

The follow roles are involved in this phase of the operations:
Technical Manager
Applications Engineer
System Administration
Technical Support
Security Officer
Registry Administrator
QA and Process Manager

Similar gTLD applications: (26)

gTLDFull Legal NameE-mail suffixzDetail
.mtpcMitsubishi Tanabe Pharma Corporationgmoregistry.com-3.34Compare
.konamiKONAMI CORPORATIONkonami.com-3.34Compare
.DNPDai Nippon Printing Co., Ltd.mail.dnp.co.jp-3.34Compare
.toshibaTOSHIBA Corporationgmoregistry.com-3.34Compare
.canonCanon Inc.web.canon.co.jp-3.34Compare
.GGEEGMO Internet, Inc.gmoregistry.com-3.34Compare
.otsukaOtsuka Holdings Co., Ltd.otsuka.jp-3.34Compare
.greeGREE, Inc.gmoregistry.com-3.34Compare
.GMOGMO Internet, Inc.gmoregistry.com-3.34Compare
.nhkJapan Broadcasting Corporation (NHK)internet.nhk.or.jp-3.34Compare
.hitachiHitachi, Ltd.hitachi.com-3.34Compare
.datsunNISSAN MOTOR CO., LTD.thomsonbrandy.jp-3.34Compare
.kddiKDDI CORPORATIONgmoregistry.com-3.34Compare
.infinitiNISSAN MOTOR CO., LTD.thomsonbrandy.jp-3.34Compare
.nissanNISSAN MOTOR CO., LTD.thomsonbrandy.jp-3.34Compare
.sharpSharp Corporationgmoregistry.com-3.34Compare
.yokohamaGMO Registry, Inc.gmoregistry.com-3.33Compare
.osakaGMO Registry, Inc.gmoregistry.com-3.33Compare
.nagoyaGMO Registry, Inc.gmoregistry.com-3.33Compare
.TOKYOGMO Registry, Inc.gmoregistry.com-3.33Compare
.MAILGMO Registry, Inc.gmoregistry.com-3.33Compare
.ryukyuBusinessRalliart inc.gmoregistry.com-3.29Compare
.okinawaBusinessRalliart inc.gmoregistry.com-3.29Compare
.SHOPGMO Registry, Inc.gmoregistry.com-3.25Compare
.SHOPGMO Registry, Inc.gmoregistry.com-3.25Compare
.INCGMO Registry, Inc.gmoregistry.com-3.25Compare