Protocolo de aprovisionamiento extensible

El Protocolo de Aprovisionamiento Extensible ( EPP ) es un protocolo flexible diseñado para la asignación de objetos dentro de los registros a través de Internet . La motivación para la creación del EPP fue desarrollar un protocolo robusto y flexible que permitiera la 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 previene el secuestro de dominios . Antes de su introducción, los registros carecían de un enfoque uniforme y existían numerosas interfaces propietarias. Si bien su uso para nombres de dominio fue el impulso inicial, el protocolo está diseñado para ser utilizable 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 TCP . El protocolo se ha diseñado con la flexibilidad necesaria para permitirle usar otros transportes como BEEP , SMTP , SOAP o HTTPS . ^{[ 1 ]} Sin embargo, solo HTTPS se ha utilizado en cierta medida, mientras que la gran mayoría usa TCP.

Los primeros borradores de protocolo fueron publicados como documentos de Internet Draft 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 una sesión BoF celebrada en IETF-49 en diciembre de 2000. ^{[ 3 ]} Los documentos de Estándar Propuesto (RFC 3730 - 3734) fueron publicados por el Editor de RFC en marzo de 2004. ^{[ 4 ]} Los documentos de Estándar Borrador (RFC 4930 - 4934) fueron publicados en mayo de 2007. ^{[ 5 ]}

En agosto de 2009, el 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 de RFC 3915 en septiembre de 2004. ^{[ 7 ]} Desde entonces, le siguieron varias extensiones de estándares propuestas 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 (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 los registros ENUM como los que operan el +31, Códigos de país +41, +43, +44 y +48. ^{[ 9 ]}

ICANN ha establecido como condición en su contrato de registro base la oferta de un servicio EPP. Por lo tanto, 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 utilizado por alrededor de 59 ccTLD y seis gTLD. ^{[ 11 ]} Otro software de código abierto es FRED (mantenido por CZ.NIC ), que cuenta con 11 ccTLD como usuarios. ^{[ 12 ]}

Existen tres clases de comandos: administración de sesiones, consulta y transformación de objetos. Estos comandos se pueden asignar a objetos, lo que especifica su funcionalidad exacta. ^{[ 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 ]} aunque rara vez se utilizan.

Cuando el cliente se conecta a un servidor, este le envía inmediatamente un mensaje de "saludo". Este mensaje contiene información sobre el servidor al que el cliente debe conectarse, como el nombre del servidor, la fecha y hora actuales en UTC, las funciones compatibles y una política de privacidad. Las funciones compatibles incluyen versiones de EPP, idiomas, objetos y extensiones. ^{[ 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 ejemplo de comando para crear un dominio podría ser el siguiente:

<?xml version="1.0" encoding="UTF-8" standalone="no"?> <epp xmlns= "urn:ietf:params:xml:ns:epp-1.0" > <command> <create> <domain:create xmlns:domain= "urn:ietf:params:xml:ns:domain-1.0" > <domain:name> example.com </domain:name> <domain:period unit= "y" > 1 </domain:period> <domain:ns> <domain:hostObj> ns1.example.net </domain:hostObj> <domain:hostObj> ns2.example.net </domain:hostObj> </domain:ns> <domain:registrant> REG-1738 </domain:registrant> <domain:contact type= "admin" > ADM-9374 </domain:contact> <domain:contact type= "tech" > OTH-2567 </domain:contact> <domain:contact type= "billing" > OTH-2567 </domain:contact> <domain:authInfo> <domain:pw> y85NS%FJ4zeKuHXo </domain:pw> </domain:authInfo> </domain:create> </create> <clTRID> uu28qbb2wo6o5bpk </clTRID> </command> </epp>

Tenga en cuenta que los dos objetos host y los tres objetos de contacto diferentes debían crearse previamente para poder utilizarlos, y el cliente debía haber iniciado sesión. El authInfo pwes un secreto necesario en la transferencia entre registradores. El clTRIDes un ID de transacción único para cada comando que genera el cliente. Una respuesta del servidor al comando anterior podría tener este aspecto:

<?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> example.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 clTRIDidentificador es el mismo que envió el cliente, mientras que el svTRIDidentificador de transacción es un ID único generado por el servidor. El servidor devuelve un código de resultado, un mensaje y datos 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 funcionalidades sin cambiar los comandos base. ^{[ 1 ]}

Hay algunas extensiones estandarizadas que utilizan muchos registros. Estas 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 ]} y mantenimientos de registro ^{[ 21 ]} entre otras cosas. ^{[ 8 ]}

Algunos registros también desarrollaron extensiones específicas para sus TLD. Un caso de uso común para las extensiones no estandarizadas es la recopilación de datos adicionales necesarios para crear un dominio, por ejemplo, un número de identificación fiscal (IVA) . ^{[ 8 ]}

Todas las respuestas del servidor deben seguir un formato específico. Cada código de respuesta corresponde a un mensaje legible para el usuario. Los códigos con el formato 1xxx indican operaciones exitosas, mientras que los códigos con el formato 2xxx indican errores. Los errores se dividen a su vez en errores de sintaxis de protocolo (formato 20xx), reglas específicas de implementación (formato 21xx), seguridad (formato 22xx), gestión de datos (formato 23xx), sistema del servidor (formato 24xx) y gestión de la conexión (formato 25xx). La mayoría de los resultados pueden incluir datos adicionales en el resDataobjeto, por ejemplo, qué parámetro obligatorio falta. ^{[ 1 ]}

El código de respuesta 1001 habilita el procesamiento fuera de línea. Un ejemplo de esto podría ser que un registro de nombres de dominio desee validar a un registrante antes de registrar el dominio. En este caso, el dominio se bloquea para otros clientes hasta que el proceso se complete, y el cliente recibirá una notificación mediante un mensaje de sondeo que puede obtener mediante el comando `poll`. Los códigos 1300 y 1301 son específicos para el comando `poll` e indican si hay un mensaje disponible. ^{[ 1 ]}

La lista completa de códigos de resultado estandarizados y mensajes de resultado es: ^{[ 1 ]}

Existen dos tipos de códigos de estado: de servidor y de cliente. La diferencia radica en 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 habitualmente para gestionar casos de abuso de dominio, marcar la etapa del ciclo de vida del dominio u ofrecer seguridad adicional contra manipulaciones no autorizadas, un servicio que a menudo se denomina Bloqueo de Registro.

Los códigos de estado del cliente también se utilizan habitualmente para gestionar casos de abuso, impago, 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 del cliente estandarizados actualmente son: ^{[ 15 ]}

EPP solo admite contraseñas en texto plano; además, el tipo de contraseña de inicio de sesión de EPP se especifica como una cadena de 6 a 16 caracteres ^{[ 1 ],} lo que podría considerarse muy bajo para los estándares actuales. Por lo tanto, las conexiones sobre TCP deben usar 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. ^{[ 22 ]}

Muchos registradores de nombres de dominio también ofrecen la posibilidad de configurar una lista blanca de direcciones IP para conectarse a sus servidores EPP.

EPP ofrece cierta protección contra ataques de repetición a través del correo generado por el cliente clTRID; sin embargo, este elemento es opcional y, por lo tanto, no lo utiliza todo el software del servidor. Por consiguiente, el mecanismo de transporte utilizado debe implementar mecanismos adicionales contra ataques de repetición. ^{[ 1 ]}

• RFC  3375 , Requisitos del protocolo genérico de registro-registrador
• RFC  5730 , Protocolo de aprovisionamiento extensible (EPP) (sustituye a RFC  4930 , que a su vez sustituyó a RFC  3730 )
• RFC  5734 , Protocolo de aprovisionamiento extensible (EPP) Transporte sobre TCP (sustituye a RFC  4934 )

• RFC  5731 , Protocolo de aprovisionamiento extensible (EPP) para la asignación de nombres de dominio (sustituye a RFC  4931 )
• RFC  5732 , Protocolo de aprovisionamiento extensible (EPP) para asignación de hosts (sustituye a RFC  4932 )
• RFC  5733 , Protocolo de aprovisionamiento extensible (EPP) Mapeo de contactos (sustituye a RFC  4933 )
• RFC  8543 , Mapeo de la organización del protocolo de aprovisionamiento extensible (EPP)

• RFC  3735 , Directrices para la ampliación del EPP
• RFC  3915 , Asignación del período de gracia del registro de dominio (por ejemplo, agregar período de gracia , período de gracia de redención )
• RFC  4114 , E.164 Asignación de números para el Protocolo de aprovisionamiento extensible (EPP)
• RFC  5076 , Mapeo de información de validación ENUM para el protocolo de aprovisionamiento extensible
• RFC  5910 , Asignación de extensiones de seguridad del sistema de nombres de dominio ( DNS ) para el protocolo de aprovisionamiento extensible (EPP) (sustituye a RFC  4310 , DNSSEC )
• RFC  8334 , Mapeo de la fase de lanzamiento para el Protocolo de aprovisionamiento extensible (EPP)
• RFC  8495 , Extensión del token de asignación para el protocolo de aprovisionamiento extensible (EPP)
• RFC  8544 , Extensión de organización para el Protocolo de aprovisionamiento extensible (EPP)
• RFC  8590 , Extensión de sondeo de cambios para el protocolo de aprovisionamiento extensible (EPP)
• RFC  8748 , Extensión de la tarifa de registro para el Protocolo de aprovisionamiento extensible (EPP)
• RFC  8807 , Extensión de seguridad de inicio de sesión para el Protocolo de aprovisionamiento extensible (EPP)
• RFC  9038 , Protocolo de aprovisionamiento extensible (EPP): Espacios de nombres no gestionados
• RFC  9154 , Protocolo de aprovisionamiento extensible (EPP) Información de autorización segura para transferencia
• RFC  9167 , Notificación de mantenimiento del registro para el protocolo de aprovisionamiento extensible (EPP)

• QUIÉN ES
• Protocolo de acceso a datos de registro
• ICANN
• Nombre de dominio internacionalizado
• Disco de pegamento
• Protocolo de aprovisionamiento RESTful