This post is co-authored by Marco Davids.
In this post, we discuss SIDN Labs’ proposal to add a REST-based API to the Extensible Provisioning Protocol (EPP). As well as making EPP easier for registrars to use, such an API would help domain registries by increasing scalability and improving performance and security.
Being stateless, RESTful EPP would also better suit modern software engineering technologies such as containerization and Kubernetes. We’re working with other European registries to standardize RESTful EPP at the Internet Engineering Task Force (IETF) — something we previously tried to do back in 2012 (not a typo 😉 ).
What is EPP?
EPP is an XML-based protocol for managing domain name objects within a registry in the context of processes such as creating and updating domain names. It’s an IETF-standardized protocol that has been around for roughly 15 years. EPP was introduced so registrars have a standardized, uniform interface for registry access. That’s very important for the many registrars that offer their customers domain names under various Top-Level Domains (TLDs) because they don’t have the complexity and cost of a separate client for every registry they deal with.
As the registry for the .nl domain, SIDN has supported EPP since 2010. The core of the EPP protocol is defined in RFC 5730. There are additional specifications for domain name objects, host objects, and contact objects.
What are the problems with EPP?
More and more registries are adopting new software engineering technologies such as Kubernetes, which operate on their own premises or in private or public cloud environments. In such environments, REST-based stateless services are commonplace. However, EPP was conceived as a stateful protocol, because it predates the rise of the new software technologies and REST-based services. As a stateful protocol, EPP uses the ‘session’ concept, with the EPP server logging information about the client, such as the commands performed and the connection status.
The disadvantage of a stateful protocol is that it complicates developing a scalable system capable of rapidly processing a large amount of EPP messages. The reason is that a registry’s EPP system has to ensure that each EPP connection is managed exclusively by one particular server so that the status of the connection can be monitored.
That, in turn, frustrates the efficient distribution of EPP requests across the available server capacity. As a result, a single server will sometimes have to receive and process many thousands of EPP requests per minute over a given connection. The server is then in danger of being overloaded, with adverse implications for registrars and registrants, such as delayed request fulfilment, request time-outs and server instability, reducing the availability of the entire EPP service.
It’s also harder for a registry to decide what server resources to allocate to what EPP request type to, for example, ensure that the most important request types are dealt with most quickly.
What are the advantages of RESTful EPP?
We see RESTful EPP (REPP) as a possible solution to the problems outlined above and as a means of realizing a user-friendly, scalable EPP service. We propose reusing the existing EPP standards as far as possible, in combination with a RESTful architectural style. REPP should therefore be seen as a mix of EPP and REST functionalities, rather than merely as an EPP transport layer that relays EPP messages transparently.
Unlike EPP, REPP is a stateless protocol. No information about the client or the connection is held on the server. Every REPP request is self-contained and independent from any preceding requests, implying that it must contain all the information the server needs for successful fulfilment, such as client authentication information.
With REPP, the registry has more scope for load balancing. Requests can be distributed efficiently across the available server capacity because REPP’s stateless design means that any server can process a given request (in contrast to the situation with EPP).
REPP also makes it possible to differentiate between transactions of different types. So, for example, ‘Check’ and ‘Info’ requests could be handled separately from other traffic, such as ‘Create’ and ‘Update’ transactions (see Figure 1).
A registry will typically receive far more information requests (‘Check’ and ‘Info’ requests) than, for example, ‘Create’ requests for new domain names. Processing information requests on a separate infrastructure would enable a registry to do more to assure the availability and performance of the servers handling other transactions.
REPP would benefit registrars as well. Integration with a REST API is easier and cheaper to implement because REPP offers a stateless, HTTP-based, interface. By contrast, a stateful TCP socket-based protocol like EPP requires programmers to work with a low-level socket API. We’re additionally working on support for other data formats, such as JSON to facilitate use in modern web APIs.
We need your help!
Under the umbrella of the IETF, the SIDN Labs team is currently working with various other registries on a draft RESTful EPP specification. Our plan is to collaborate with interested registrars and registries on further development of the draft, to ultimately get it published as an IETF standard. If you’d like to be involved, please get in touch, or submit your contribution using a GitHub pull request.
Maarten Wullink and Marco Davids are Research Engineers at SIDN Labs.
Originally published at SIDN Labs.
The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog.