El Protocolo de Aprovisionamiento Extensible ( EPP ) es un protocolo flexible diseñado para asignar objetos dentro de los registros a través de Internet . La motivación para la creación de EPP fue crear un protocolo robusto y flexible que pudiera proporcionar comunicación entre los registros de nombres de dominio y los registradores de nombres de dominio . Estas transacciones son necesarias siempre que se registra o renueva un nombre de dominio , lo que también evita el secuestro de dominios . Antes de su introducción, los registros no tenían un enfoque uniforme y existían muchas interfaces propietarias diferentes. Si bien su uso para nombres de dominio fue el impulso inicial, el protocolo está diseñado para ser utilizable para cualquier tipo de sistema de pedidos y cumplimiento. [1]
El protocolo EPP se basa en XML , un formato estructurado basado en texto. El transporte de red subyacente no es fijo, aunque el único método especificado actualmente es TCP . El protocolo se ha diseñado con la flexibilidad necesaria para permitir el uso de otros transportes, como BEEP , SMTP , SOAP o HTTPS . [1] Sin embargo, solo se ha utilizado HTTPS, mientras que la gran mayoría utiliza TCP.
Los primeros borradores de protocolo fueron publicados como documentos de borrador de Internet de presentación individual de IETF por Scott Hollenbeck de Verisign en noviembre de 2000. [2] Los documentos de presentación individual fueron adoptados por el grupo de trabajo del Registro de Aprovisionamiento de IETF ( provreg ) , que se creó después de que se celebrara una sesión de BoF en IETF-49 en diciembre de 2000. [3] Los documentos de estándar propuestos (RFC 3730 - 3734) fueron publicados por el editor de RFC en marzo de 2004. [4] Los documentos de borrador de estándar (RFC 4930 - 4934) se publicaron en mayo de 2007. [5]
En agosto de 2009, la IETF otorgó a EPP el estatus de estándar completo como STD 69. [6]
La primera extensión del EPP que se convirtió en un estándar propuesto fue la extensión del período de gracia de redención del RFC 3915 en septiembre de 2004. [7] Desde entonces, se han propuesto varias extensiones estándar diferentes. [8]
El protocolo ha sido adoptado por varios registros de nombres de dominio ccTLD, como: .ac , .ag , .ai , .as , .ar , .at , .au , .be , .br , .bz , .ca , .cat , .cc , .ch , .cl , .cn , .co , .cr , .cx , .cz , .dk , .dm , .ee , .es (sobre HTTPS), .eu , .fi , .fm , .fr , .gg , .gr (sobre HTTPS), .gs , .hn , .ht , .il , .im , .in , .io , .it (sobre HTTPS), .je , .ke , .ki. , .ky , .kz , .la , .lc , .li , .lt , .lu , .lv , .md , .me , .mk , .mn , .ms , .mu , .mx , .na , .nf , .ng , .nl , .no , .nu , .nz , .pe , .pk , .pl (sobre HTTPS), .ps , .pt , .ru , .ro , .sc , .se , .sh , .si , .su , .tl , .tm .tv , .tw , .ua , .uk , .us , .vc , .ve y .za, así como registros ENUM como los que operan el Códigos de país +31, +41, +43, +44 y +48. [9]
La ICANN ha establecido como condición en su contrato de registro base ofrecer un servicio EPP, por lo que todos los gTLD han adoptado el protocolo. [10]
Existen múltiples implementaciones de código abierto de software de servidor EPP. El Consejo de Administradores de Códigos de País (CoCCA) mantiene un software de servidor EPP que es utilizado por alrededor de 59 ccTLD y 6 gTLD. [11] Otro software de código abierto es FRED (mantenido por CZ.NIC ) que cuenta con 11 ccTLD como sus usuarios. [12]
Existen tres clases de comandos: administración de sesiones, consulta y transformación de objetos. Estos comandos pueden luego asignarse a objetos que especifican con más precisión su funcionalidad. [1] Los objetos estandarizados más comunes son los hosts, [13] los contactos [14] y los dominios. [15] También existen otros objetos estandarizados como las organizaciones, [16] sin embargo, rara vez se utilizan.
Cuando el cliente se conecta a un servidor, el servidor envía inmediatamente un mensaje de "saludo" al cliente. Este mensaje contiene información sobre el servidor al que el cliente necesita conectarse. Incluye el nombre del servidor, la fecha y hora actuales del servidor en UTC, las funciones admitidas y una política de privacidad. Las funciones admitidas incluyen versiones de EPP, idiomas, objetos y extensiones. [1]
Los comandos de gestión de sesiones son: [1]
Los comandos de consulta son: [1]
Los comandos de transformación de objetos son: [1]
Un ejemplo de comando para crear un dominio podría verse así:
<?xml version="1.0" encoding="UTF-8" standalone="no"?> <epp xmlns= "urn:ietf:params:xml:ns:epp-1.0" > <comando> <crear> <dominio:crear xmlns:dominio= "urn:ietf:params:xml:ns:dominio-1.0" > <dominio:nombre> ejemplo.com </dominio:nombre> <dominio:periodo unidad= "y" > 1 </dominio:periodo> <dominio:ns> <dominio:hostObj> ns1.ejemplo.net </dominio:hostObj> <dominio:hostObj> ns2.ejemplo.net </dominio:hostObj> </dominio:ns> <dominio:registrante> REG-1738 </dominio:registrante> <dominio:contacto tipo= "admin" > ADM-9374 </dominio:contacto> <dominio:contacto tipo= "tecnología" > OTH-2567 </dominio:contacto> <dominio:contacto tipo= "facturación" > OTH-2567 </dominio:contacto> <dominio:información de autenticación> <dominio:contraseña> y85NS%FJ4zeKuHXo </dominio:contraseña> </dominio:información de autenticación> </dominio:crear> </crear> <clTRID> uu28qbb2wo6o5bpk </clTRID> </comando> </epp> Tenga en cuenta que los dos objetos host y los tres objetos de contacto diferentes se tuvieron que crear de antemano para poder usarlos y que el cliente ya tenía que haber iniciado sesión. La contraseña authInfo es un secreto que se requiere en la transferencia entre registradores. El clTRID es un identificador de transacción único para cada comando generado por el cliente. Una respuesta del servidor al comando anterior podría verse así:
<?xml version="1.0" encoding="UTF-8" standalone="no"?> <epp xmlns= "urn:ietf:params:xml:ns:epp-1.0" > <response> <result code= "1000" > <msg> Comando completado correctamente </msg> </result> <resData> <domain:creData xmlns:domain= "urn:ietf:params:xml:ns:domain-1.0" > <domain:name> ejemplo.com </domain:name> <domain:crDate> 2023-03-12T12:00:00.0Z </domain:crDate> <domain:exDate> 2024-03-12T12:00:00.0Z </domain:exDate> </domain:creData> </resData> <trID> <clTRID> uu28qbb2wo6o5bpk </clTRID> <svTRID> ma3fuaeuh7bzpgv9 </svTRID> </trID> </response> </epp> El clTRID es el mismo que el enviado por el cliente, mientras que el svTRID es un identificador de transacción único generado por el servidor. El servidor devuelve un código de resultado, un mensaje y datos de resultado adicionales, como la fecha de vencimiento del dominio recién creado.
El protocolo ofrece la posibilidad de enviar un objeto de extensión en casi todos los comandos posibles para permitir que los registros agreguen nueva funcionalidad sin cambiar los comandos base. [1]
Existen algunas extensiones estandarizadas que se utilizan en muchos registros. Entre ellas se incluyen las extensiones para DNSSEC , [17] IDN , [18] nombres de dominio premium, [19] restauración de dominios ( RGP ) [7] y extensiones para gestionar el lanzamiento de nuevos TLD [20], entre otras cosas. [8]
Algunos registros también desarrollaron extensiones específicas para sus TLD. Un caso de uso común de las extensiones no estandarizadas es la recopilación de datos adicionales necesarios para crear un dominio, por ejemplo, un número de identificación de IVA . [8]
Todas las respuestas del servidor deben seguir un formato específico. Cada código de respuesta corresponde a un mensaje legible para humanos. Los códigos en el formato 1xxx son operaciones exitosas, mientras que los códigos en el formato 2xxx son errores. Los errores se dividen nuevamente en errores de sintaxis de protocolo en el formato 20xx, reglas específicas de implementación como 21xx, seguridad como 22xx, administración de datos como 23xx, sistema de servidor como 24xx y administración de conexión como 25xx. La mayoría de los resultados pueden incluir datos adicionales en el objeto resData, por ejemplo, qué parámetro requerido falta específicamente. [1]
El código de respuesta 1001 permite el procesamiento fuera de línea; un ejemplo de esto puede ser que un registro de nombre de dominio desee validar un registrante antes de que se registre el dominio. En este caso, el dominio se bloquea para otros clientes hasta que se complete el proceso y se notificará al cliente mediante un mensaje de sondeo que puede obtener mediante el comando de sondeo. Los códigos 1300 y 1301 son específicamente para el comando de sondeo y señalan si hay un mensaje o no. [1]
La lista completa de códigos de resultados estandarizados y mensajes de resultados es: [1]
Existen dos tipos de códigos de estado: de servidor y de cliente. La diferencia es que todos los códigos de estado de servidor solo pueden ser establecidos y eliminados por el registro, mientras que los códigos de estado de cliente también pueden ser establecidos y eliminados por el registrador, a menos que un código de estado de servidor lo prohíba. [15]
Los códigos de estado del servidor se utilizan comúnmente para manejar casos de abuso de dominio, marcar la etapa del ciclo de vida del dominio u ofrecer seguridad adicional contra manipulación no autorizada, un servicio a menudo denominado Registry-Lock.
Los códigos de estado del cliente se utilizan comúnmente también para gestionar casos de abuso, falta de pago, datos de contacto no válidos o para una función de bloqueo del registrador .
Los códigos de estado del servidor estandarizados actualmente son: [15] [7]
Los códigos de estado de cliente estandarizados actualmente son: [15]
EPP solo ofrece contraseñas de texto sin formato; además, el tipo de contraseña de inicio de sesión de EPP se especifica como una cadena de entre 6 y 16 caracteres [1], lo que podría considerarse muy poco para los estándares actuales. Por lo tanto, las conexiones a través de TCP deben utilizar TLS y se recomienda encarecidamente el uso de certificados de cliente , así como la confirmación correcta de la identidad del cliente y del servidor. [21]
Además, muchos registros de nombres de dominio ofrecen configurar una lista blanca de IP para conectarse a sus servidores EPP.
El EPP ofrece cierta protección contra ataques de repetición a través del clTRID generado por el cliente, sin embargo, este elemento es opcional y, por lo tanto, no lo utiliza todo el software de servidor. Por lo tanto, el mecanismo de transporte utilizado debería implementar mecanismos antirreproducción adicionales. [1]
{{cite journal}}: Requiere citar revista |journal=( ayuda ){{cite journal}}: Requiere citar revista |journal=( ayuda ){{cite journal}}: Requiere citar revista |journal=( ayuda ){{cite journal}}: Requiere citar revista |journal=( ayuda ){{cite journal}}: Requiere citar revista |journal=( ayuda ){{cite web}}: CS1 maint: bot: estado de URL original desconocido ( enlace ){{cite journal}}: Requiere citar revista |journal=( ayuda ){{cite journal}}: Requiere citar revista |journal=( ayuda ){{cite journal}}: Requiere citar revista |journal=( ayuda ){{cite journal}}: Requiere citar revista |journal=( ayuda ){{cite journal}}: Requiere citar revista |journal=( ayuda ){{cite journal}}: Requiere citar revista |journal=( ayuda ){{cite journal}}: Requiere citar revista |journal=( ayuda )