Future-proofing the EPP protocol: RESTful EPP
Adapting the standard domain name registration protocol for use in modern software development architectures
The original blog is in Dutch, this is the English translation.
In this blog, we discuss our proposal to add a REST-based API to the EPP protocol. 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 be a better fit with modern software engineering technologies such as containerisation and Kubernetes. We're working with other European registries to standardise RESTful EPP at the Internet Engineering Task Force (IETF) – something we previously tried to do back in 2012. (Not a typo ;-).)
What is EPP?
The Extensible Provisioning Protocol (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-standardised protocol that has been around for roughly 15 years. EPP was introduced so that registrars have a standardised, uniform interface for registry access. That's very important for the many registrars that offer their customers domain names under various top-level domains, 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 they 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 status of the connection.
The disadvantage of a stateful protocol is that it complicates the task of developing a scalable system capable of rapidly processing a large number of EPP messages. The reason being 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 in order 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 realising 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 that 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 therefore enable a registry to do more to assure the availability and performance of the servers handling other transactions.
Figure 1: EPP transaction load balancing enabled by REPP.
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 Internet Engineering Task Force (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, with a view to ultimately getting it published as an IETF standard. If you'd like to be involved, please get in touch, or submit your contribution by using a GitHub pull request.
