Preparando el protocolo EPP para el futuro: EPP RESTful

En esta publicación, discutimos la propuesta de SIDN Labs para agregar una API basada en REST al Protocolo de Aprovisionamiento Extensible (EPP). Además de hacer que EPP sea más fácil de usar para los registradores, dicha API ayudaría a los registros de dominios al aumentar la escalabilidad y mejorar el rendimiento y la seguridad.

Siendo sin estado, EPP RESTful también se adaptaría mejor a las tecnologías modernas de ingeniería de software como la containerización y Kubernetes. Estamos trabajando con otros registros europeos para estandarizar EPP RESTful en el Grupo de Trabajo de Ingeniería de Internet (IETF), algo que intentamos hacer anteriormente en 2012 (no es un error tipográfico).

¿Qué es EPP?

EPP es un protocolo basado en XML para gestionar objetos de nombres de dominio dentro de un registro en el contexto de procesos como la creación y actualización de nombres de dominio. Es un protocolo estandarizado por el IETF que ha existido durante aproximadamente 15 años. EPP se introdujo para que los registradores tuvieran una interfaz estandarizada y uniforme para el acceso al registro. Eso es muy importante para los muchos registradores que ofrecen a sus clientes nombres de dominio bajo varios Dominios de Nivel Superior (TLD) porque no tienen la complejidad y el costo de un cliente separado para cada registro con el que tratan.

Como el registro del dominio .nl, SIDN ha soportado EPP desde 2010. El núcleo del protocolo EPP está definido en el RFC 5730. Hay especificaciones adicionales para objetos de nombres de dominio, objetos de hosts y objetos de contacto.

¿Cuáles son los problemas con EPP?

Cada vez más registros están adoptando nuevas tecnologías de ingeniería de software, como Kubernetes, que operan en sus propias instalaciones o en entornos de nube privada o pública. En tales entornos, los servicios sin estado basados en REST son comunes. Sin embargo, EPP fue concebido como un protocolo con estado, porque precede al auge de las nuevas tecnologías de software y los servicios basados en REST. Como protocolo con estado, EPP utiliza el concepto de "sesión", con el servidor EPP registrando información sobre el cliente, como los comandos realizados y el estado de la conexión.

La desventaja de un protocolo con estado es que complica el desarrollo de un sistema escalable capaz de procesar rápidamente una gran cantidad de mensajes EPP. La razón es que el sistema EPP de un registro tiene que asegurarse de que cada conexión EPP sea gestionada exclusivamente por un servidor particular para que el estado de la conexión pueda ser monitoreado.

Eso, a su vez, frustra la distribución eficiente de las solicitudes EPP a lo largo de la capacidad de servidor disponible. Como resultado, un solo servidor a veces tendrá que recibir y procesar muchos miles de solicitudes EPP por minuto sobre una conexión dada. El servidor entonces corre el peligro de sobrecargarse, con implicaciones adversas para los registradores y los registrantes, como la demora en el cumplimiento de las solicitudes, los tiempos de espera de las solicitudes y la inestabilidad del servidor, reduciendo la disponibilidad de todo el servicio EPP.

También es más difícil para un registro decidir qué recursos de servidor asignar a qué tipo de solicitud EPP para, por ejemplo, asegurar que los tipos de solicitudes más importantes se traten lo más rápidamente posible.

¿Cuáles son las ventajas de EPP RESTful?

Vemos EPP RESTful (REPP) como una posible solución a los problemas descritos anteriormente y como un medio para realizar un servicio EPP fácil de usar y escalable. Proponemos reutilizar los estándares EPP existentes tanto como sea posible, en combinación con un estilo arquitectónico RESTful. Por lo tanto, REPP debe verse como una mezcla de funcionalidades EPP y REST, en lugar de meramente como una capa de transporte EPP que retransmite mensajes EPP de manera transparente.

A diferencia de EPP, REPP es un protocolo sin estado. No se guarda información sobre el cliente o la conexión en el servidor. Cada solicitud REPP es autónoma e independiente de cualquier solicitud anterior, lo que implica que debe contener toda la información que el servidor necesita para su cumplimiento exitoso, como la información de autenticación del cliente.

Con REPP, el registro tiene más margen para el balanceo de carga. Las solicitudes se pueden distribuir de manera eficiente a lo largo de la capacidad de servidor disponible porque el diseño sin estado de REPP significa que cualquier servidor puede procesar una solicitud dada (en contraste con la situación con EPP).

REPP también hace posible diferenciar entre transacciones de diferentes tipos. Así, por ejemplo, las solicitudes de 'Check' e 'Info' podrían manejarse por separado de otro tráfico, como las transacciones de 'Create' y 'Update' (ver Figura 1).

Un registro típicamente recibirá muchas más solicitudes de información ('Check' e 'Info') que, por ejemplo, solicitudes de 'Create' para nuevos nombres de dominio. Procesar solicitudes de información en una infraestructura separada permitiría a un registro hacer más para asegurar la disponibilidad y el rendimiento de los servidores que manejan otras transacciones.

REPP también beneficiaría a los registradores La integración con una API REST es más fácil y barata de implementar porque REPP ofrece una interfaz sin estado basada en HTTP. En contraste, un protocolo con estado basado en sockets TCP como EPP requiere que los programadores trabajen con una API de sockets de bajo nivel. Además, estamos trabajando en el soporte para otros formatos de datos, como JSON, para facilitar su uso en las API web modernas.