Het EPP-protocol toekomstbestendig maken: RESTful EPP
Het standaard protocol voor domeinnaamregistraties geschikt maken voor gebruik in moderne softwaredevelopmentarchitecturen
In deze blog bespreken we ons voorstel om EPP te voorzien van een op REST gebaseerde API. Dit maakt EPP eenvoudiger te gebruiken voor registrars en biedt voor domeinregistry’s verhoogde schaalbaarheid en betere performance en security. Ook sluit het stateless karakter van RESTful EPP beter aan bij nieuwe software-engineeringtechnologieën zoals containerisatie en Kubernetes. We werken samen met Europese collega-registry’s om RESTful EPP te standaardiseren in de Internet Engineering Task Force (IETF), een herstart van onze eerste poging uit 2012 (geen typo ;-).
Wat is EPP?
Het Extensible Provisioning Protocol (EPP) is een op XML gebaseerd protocol voor het beheren van domeinnaamobjecten in een registry, bijvoorbeeld om domeinnamen te creëren of te updaten. Het is een door de IETF gestandaardiseerd protocol dat al zo’n 15 jaar bestaat. Het doel van EPP is het aanbieden van een gestandaardiseerde, uniforme interface aan registrars. Dit is belangrijk voor veel registrars, omdat ze domeinnamen van meerdere toplevels aanbieden aan registrants. EPP voorkomt dat een registrar voor elke domeinregistry een aparte client moet ontwikkelen, wat veel complexiteit oplevert en kosten verhoogt.
Als registry voor het .nl-domein volgt SIDN deze standaard sinds 2010. De kern van het EPP-protocol is beschreven in RFC 5730. Daarnaast bestaan er specificaties voor domeinnaam-, host- en contact-objecten.
Wat zijn de problemen met EPP?
Steeds meer registry’s maken de overstap naar nieuwe software-engineeringtechnologieën zoals Kubernetes, die ze on-premises gebruiken of op een private of publieke cloud. In een dergelijke omgeving wordt vaak gebruikgemaakt van op REST gebaseerde stateless services. EPP is echter ontworpen ontworpen als een stateful-protocol, omdat het stamt uit een tijd waarin deze softwaretechnologieën en op REST gebaseerde services nog niet zo gewoon waren. Stateful wil zeggen dat het protocol gebruikmaakt van het concept van een ‘sessie’, waarmee de EPP-server informatie over de client bijhoudt, zoals uitgevoerde EPP-commando’s en de status van de connectie.
Het nadeel van een stateful-protocol is dat het daarmee moeilijker is om goed schaalbare systemen te ontwikkelen die snel een groot aantal EPP-berichten kunnen verwerken. Het EPP-systeem van een registry moet er namelijk voor zorgen dat elke EPP-connectie steeds door dezelfde server wordt afgehandeld. Dit omdat alleen die server de state van de betreffende connectie bijhoudt. Hierdoor is het moeilijk om de beschikbare servercapaciteit efficiënt te verdelen over alle EPP-requests. Het komt dan bijvoorbeeld voor dat een server via een enkele EPP-connectie vele duizenden verzoeken per minuut moet ontvangen en verwerken. Hierdoor kan een server overbelast raken, met nadelige gevolgen voor registrars en registrants. Het kan bijvoorbeeld langer duren voordat een request wordt uitgevoerd, een request kan mislukken (time-out) of de server kan instabiel raken en zo de beschikbaarheid van de hele EPP-dienstverlening van de registry reduceren. Het is voor een registry ook moeilijker te bepalen welke serverresources in te zetten voor welk EPP-requesttype, bijvoorbeeld om voor de belangrijkere requesttypen een snellere service te leveren.
Waarom RESTful EPP?
Met RESTful EPP (REPP) proberen we de hierboven beschreven problemen op te lossen en een eenvoudig te gebruiken en schaalbare EPP-service. Dit doen we door zoveel mogelijk de bestaande EPP-standaarden te hergebruiken en deze te combineren met een RESTful-architectuurstijl. REPP is zo meer een mix van EPP en REST-functionaliteit en niet alleen een transportlaag die EPP-berichten transparant doorgeeft.
Anders dan EPP is REPP is een stateless-protocol. Dit betekent dat de server geen informatie bijhoudt over de client of de connectie. Iedere REPP-request staat op zichzelf en is onafhankelijk van voorafgaand requests, wat betekent dat requests alle informatie moet bevatten die de server nodig heeft voor het succesvol uitvoeren ervan. Denk bijvoorbeeld client-authenticatie-informatie.
REPP biedt een registry meer load balancing-mogelijkheden om de REPP-requests te verdelen over de beschikbare servercapaciteit. Dit omdat REPP stateless is en het dus anders dan bij EPP niet meer uitmaakt welke server een REPP-request verwerkt. Het wordt ook mogelijk om te differentiëren tussen de verschillende soorten transacties. Bijvoorbeeld door Check- en Info-requests te scheiden van de overige transacties zoals Create en Update (zie figuur 1). Een registry ontvangt vaak enorme aantallen informatieve requests (Check- en Info), veel meer dan voor de create requests waarmee bijvoorbeeld nieuwe domeinnamen worden geregistreerd. Door deze informatieve request op een separate infrastructuur te verwerken, kan een registry de beschikbaarheid en performance voor de overige transacties beter garanderen.
Figuur 1. Load balancing van EPP-transacties met behulp van REPP.
Voor registrars biedt REPP ook voordelen; een integratie met een REST API is eenvoudiger en goedkoper te implementeren, omdat REPP een stateless op HTTP gebaseerde interface biedt. Dit is anders dan een op stateful TCP-sockets gebaseerd protocol zoals EPP, waarbij programmeurs moeten werken met een low-level socket-API. Daarnaast werken we ook aan support voor andere data-formats zoals JSON, wat beter aansluit bij het gebruik in moderne web-API’s.
We hebben je hulp nodig!
We werken we bij SIDN Labs met collega-registry’s in de Internet Engineering Task Force (IETF) aan een conceptvoorstel voor een RESTful EPP-specificatie. Ons doel is om dit concept samen met geïnteresseerde registrars en registry’s verder uit te werken en uiteindelijk als nieuwe IETF-standaard te publiceren. Wil jij graag bijdragen? Neem dan contact met ons op, of stuur ons je bijdrage door middel van een GitHub pull request.
