El Protocolo de aprovisionamiento extensible ( EPP ) es un protocolo flexible diseñado para asignar objetos dentro de registros a través de Internet . La motivación para la creación del 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 cada vez que se registra o renueva un nombre de dominio , lo que también evita el secuestro de dominio . 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 impulsor inicial, el protocolo está diseñado para poder utilizarse en cualquier tipo de sistema de pedidos y cumplimiento. [1]
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 a través de TCP . El protocolo ha sido diseñado con la flexibilidad que le permite utilizar otros transportes como BEEP , SMTP , SOAP o HTTPS . [1] Sin embargo, solo HTTPS ha tenido algún uso, mientras que la gran mayoría usa TCP.
Los primeros borradores del protocolo se publicaron como documentos preliminares de Internet de envío individual del IETF por Scott Hollenbeck de Verisign en noviembre de 2000. [2] Los documentos de envío individuales fueron adoptados por el grupo de trabajo del Registro de aprovisionamiento del IETF ( provreg ) , que se creó después de una sesión de BoF . celebrada en IETF-49 en diciembre de 2000. [3] Los documentos estándar propuestos (RFC 3730 - 3734) fueron publicados por el Editor de RFC en marzo de 2004. [4] Los borradores de documentos estándar (RFC 4930 - 4934) se publicaron en mayo de 2007. [ 5]
En agosto de 2009, el IETF otorgó al EPP el estatus de estándar completo como STD 69. [6]
La primera extensión del EPP que se convirtió en una norma propuesta fue la extensión del período de gracia de canje del RFC 3915 en septiembre de 2004. [7] Desde entonces, siguieron varias extensiones diferentes de la norma propuesta. [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 (a través de HTTPS), .eu , .fi , . fm , .fr , .gg , .gr (a través de HTTPS), .gs , .hn , .ht , .il , .im , .in , .io , .it (a través de 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 (a través de 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 +31, + 41, +43, +44 y +48 códigos de país. [9]
ICANN ha puesto como condición en su contrato de registro base ofrecer un servicio EPP, por lo tanto, cada gTLD ha adoptado el protocolo. [10]
Existen múltiples implementaciones de código abierto del software de servidor EPP. El Consejo de Administradores de Códigos de Países (CoCCA) mantiene un software de servidor EPP que utilizan 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 usuarios. [12]
Hay 3 clases de comandos: gestión de sesiones, consulta y transformación de objetos. Estos comandos luego se pueden asignar a objetos, lo que especifica más su funcionalidad exacta. [1] Los objetos estandarizados más comunes son hosts, [13] contactos [14] y dominios. [15] También existen otros objetos estandarizados como 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. Contiene 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, idiomas, objetos y extensiones de EPP. [1]
Los comandos de gestión de sesión son: [1]
Los comandos de consulta son: [1]
Los comandos de transformación de objetos son: [1]
Un comando de ejemplo para crear un dominio podría verse así:
<?xml versión="1.0" codificación="UTF-8" standalone="no"?> <epp xmlns= "urn:ietf:params:xml:ns:epp-1.0" > <comando> <crear> <dominio :create xmlns:dominio= "urn:ietf:params:xml:ns:dominio-1.0" > <dominio:nombre> ejemplo.com </dominio:nombre> <dominio:period unidad= "y" > 1 </dominio :punto> <dominio:ns> <dominio:hostObj> ns1.example.net </dominio:hostObj> <dominio:hostObj> ns2.example.net </dominio:hostObj> </dominio:ns> <dominio:registrante > REG-1738 </dominio:registrante> <dominio: tipo de contacto= "admin" > ADM-9374 </dominio:contacto> <dominio: tipo de contacto= "técnico" > OTH-2567 </dominio:contacto> <dominio : tipo de contacto= "facturación" > OTH-2567 </dominio:contacto> <dominio:authInfo> <dominio:pw> y85NS%FJ4zeKuHXo </dominio:pw> </dominio:authInfo> </dominio:create> </ crear> <clTRID> uu28qbb2wo6o5bpk </clTRID> </command> </epp> Tenga en cuenta que los dos objetos de host y los 3 objetos de contacto diferentes debían crearse de antemano para usarlos y el cliente ya debía haber iniciado sesión. El authInfo pw es un secreto que se requiere en la transferencia entre registradores. El clTRID es una identificación de transacción única 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" > <respuesta> < código de resultado= " 1000" > <msg> Comando completado exitosamente </msg> </result> <resData> <domain:creData xmlns:domain= "urn:ietf:params:xml:ns:domain-1.0" > <domain:name> ejemplo .com </dominio:nombre> <dominio:crDate> 2023-03-12T12:00:00.0Z </dominio:crDate> <dominio:exDate> 2024-03-12T12:00:00.0Z </dominio:exDate> </domain:creData> </resData> <trID> <clTRID> uu28qbb2wo6o5bpk </clTRID> <svTRID> ma3fuaeuh7bzpgv9 </svTRID> </trID> </response> </epp> El clTRID es el mismo que envió el cliente, mientras que el svTRID es una identificación de transacción única generada 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 nuevas funciones sin cambiar los comandos base. [1]
Hay algunas extensiones estandarizadas que utilizan muchos registros. Estos incluyen extensiones para DNSSEC , [17] IDN , [18] nombres de dominio premium, [19] restauración de dominio ( RGP ) [7] y extensiones para manejar 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 para 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 por 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 conexiones 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 nombres de dominio quiera validar a un registrante antes de registrar 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 encuesta que el cliente puede recuperar mediante el comando de encuesta. 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]
Hay 2 tipos de códigos de estado: servidor y cliente. La diferencia es que todos los códigos de estado del servidor solo pueden ser establecidos y eliminados por el registro, mientras que los códigos de estado del cliente también pueden ser establecidos y eliminados por el registrador, a menos que un código de estado del 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 manipulaciones no autorizadas, un servicio a menudo denominado Registry-Lock.
Los códigos de estado del cliente se utilizan comúnmente para manejar casos de abuso, falta de pago, datos de contacto no válidos o para una función de bloqueo de registro .
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 6 a 16 caracteres de longitud [1], lo que podría considerarse muy bajo 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 el servidor. [21]
Además, muchos registros de nombres de dominio ofrecen configurar una lista blanca de IP para conectarse a sus servidores EPP.
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 utilizan todos los software de servidor. Por lo tanto, el mecanismo de transporte utilizado debería implementar mecanismos antirrepetición adicionales. [1]
{{cite journal}}: Citar diario requiere |journal=( ayuda ){{cite journal}}: Citar diario requiere |journal=( ayuda ){{cite journal}}: Citar diario requiere |journal=( ayuda ){{cite journal}}: Citar diario requiere |journal=( ayuda ){{cite journal}}: Citar diario requiere |journal=( ayuda ){{cite web}}: Mantenimiento CS1: bot: estado de la URL original desconocido ( enlace ){{cite journal}}: Citar diario requiere |journal=( ayuda ){{cite journal}}: Citar diario requiere |journal=( ayuda ){{cite journal}}: Citar diario requiere |journal=( ayuda ){{cite journal}}: Citar diario requiere |journal=( ayuda ){{cite journal}}: Citar diario requiere |journal=( ayuda ){{cite journal}}: Citar diario requiere |journal=( ayuda ){{cite journal}}: Citar diario requiere |journal=( ayuda )