La transferencia de siete registros de Jolly Host: delegación DNS, RDAP, DPML y costes de continuidad

Resumen

• El registro de cesiones completadas de la ICANN recoge siete cesiones de acuerdos de registro a Jolly Host, LLC en 2026:.onl,.safety,.circle,.got,.jot,.aeroy el dominio de primer nivel internacionalizado representado en ASCII como.xn--5tzm5gy en Unicode como.网站.[1]
• La IANA identifica actualmente a Jolly Host como organización patrocinadora de.circle,.got,.jot,.only.safety. Las páginas públicas de delegación de.aeroy.网站conservan nombres de organización patrocinadora distintos, aunque muestran contactos técnicos de Identity Digital y el servicio RDAP. Esa diferencia es un estado de registro que hay que conciliar, no una prueba de interrupción ni de actuación indebida.[2][3][4][5][6][7][8]
• Las páginas de acuerdos de registro de la ICANN presentan a Jolly Host como operador de los siete acuerdos. Los instrumentos de cesión establecen una transición jurídica y la asunción de obligaciones; no demuestran por sí solos que todas las funciones técnicas se hayan internalizado ni que todos los registros públicos hayan cambiado simultáneamente.[9][10][11][12][13][14][15][16][17][18][19]
• Una solicitud específica de la empresa para.onlen el marco de la Política de evaluación de servicios de registro (RSEP) describe a Jolly Host como operador de registro filial de Identity Digital y propone añadir el servicio Domains Protected Marks List (DPML) mediante la plataforma de Identity Digital. El escrito afirma que el cambio no debería afectar a la resolución DNS, los archivos de zona, los datos del registro ni la coherencia de las respuestas. Se trata de afirmaciones de diseño acotadas, no de una referencia de producción independiente.[20][21][22]
• La transición genera costes recurrentes de supervisión, integración, mantenimiento y gestión de excepciones en materia de autoridad jurídica, delegación de la zona raíz, aprovisionamiento del registro, contratos con registradores, datos de registro, DNSSEC, límites de política patrocinada, identidad Unicode, bloqueo protector, dependencias de proveedores y evidencia de recuperación.

Nota sobre la imagen:La imagen editorial generada que acompaña al artículo muestra un contexto genérico de operaciones de registro y red. No representa a Jolly Host, Identity Digital, ICANN, IANA, ningún dominio de primer nivel asignado, una instalación real, una arquitectura real, una fiabilidad medida, un incidente ni resultados para clientes.

Jolly Host, LLC es un objeto de empresa especialmente instructivo porque su identidad técnica pública no puede deducirse de su nombre. «Host» podría sugerir un proveedor de alojamiento web convencional, pero los registros conservados establecen un papel distinto y más relevante.

La ICANN incluye a la empresa como cesionaria de siete acuerdos de registro en 2026, y las páginas actuales de acuerdos de registro la presentan como operadora de esos dominios de primer nivel.[1][9]-[15] Ese es el objeto preciso de este artículo: una entidad jurídica vinculada a registros y obligaciones de espacio de nombres en el nivel superior del Sistema de Nombres de Dominio.

Los siete acuerdos no proceden de un único cedente ni de una sola fecha..onlpasó de iRegistry GmbH con fecha de entrada en vigor el 1 de febrero de 2026..safetypasó de Safety Registry Services, LLC el 1 de abril..circle,.goty.jotpasaron de Amazon Registry Services, Inc. el 8 de abril..aeropasó de SITA Information Networking Computing USA el 1 de mayo..网站pasó de Global Website TLD Asia Limited el 26 de mayo.[1] La cartera combina, por tanto, varias historias de transición, un espacio de nombres patrocinado, un espacio de nombres internacionalizado y varios acuerdos base no patrocinados.

El registro público también distingue la identidad jurídica del operador de la prestación técnica del servicio. Las páginas de la IANA de cinco de los nombres indican a Jolly Host como organización patrocinadora, mientras que los contactos administrativos y técnicos apuntan a Identity Digital y el extremo RDAP publicado utiliza un dominio de servicio de Identity Digital.[2]-[6] Las páginas de.aeroy.网站muestran contactos técnicos de Identity Digital y el mismo servicio RDAP, pero conservan otros nombres de organización patrocinadora en el momento de la observación.[7][8] La solicitud de servicio de Jolly Host para.onldenomina a la empresa operador de registro filial de Identity Digital y afirma que los nombres participantes reciben servicio de la plataforma de Identity Digital.[21]

Estos hechos respaldan un análisis de la superficie de control. No revelan una titularidad real jurídicamente completa, la estructura societaria privada, la plantilla interna, la arquitectura de producción, la asignación de cada tarea operativa ni un rendimiento de servicio auditado. Tampoco establecen que una diferencia visible entre registros públicos haya causado impacto en los usuarios. Una transición de registro tiene múltiples almacenes de estado y autoridades; la tarea de ingeniería es mantenerlos atribuibles y conciliados.

La distinción entre autoridad, código en ejecución y resultados es esencial:

1. Los registros de autoridadidentifican al titular del acuerdo, las fechas de entrada en vigor, los servicios permitidos, las obligaciones contractuales y los límites de política.
2. Los registros e interfaces en ejecuciónincluyen la delegación de la zona raíz, los servidores de nombres autoritativos, el material DNSSEC, los extremos RDAP y WHOIS, el aprovisionamiento del registro y los sistemas orientados a los registradores.
3. Los resultados de producciónincluyen la corrección sostenida, la frecuencia de incidentes, el tiempo de recuperación, la experiencia de los registradores, el impacto en los titulares de dominios y los resultados comerciales.

El conjunto de fuentes es sólido para la primera capa y ofrece observaciones acotadas para la segunda. No proporciona un conjunto de datos longitudinal para la tercera. Una evaluación responsable puede, por tanto, explicar la carga operativa y los modos de fallo previsibles sin fabricar una cifra de disponibilidad, una referencia, un caso de cliente ni una arquitectura interna.

Siete cesiones, una cartera y varias vías de transición

La ICANN describe una cesión de acuerdo de registro como una transferencia del acuerdo entre dos entidades.[1] Esa definición es más restringida que una narrativa de adquisición y más útil para la rendición de cuentas técnica. Identifica un objeto contractual, un cedente, un cesionario y una fecha de entrada en vigor. Cada acuerdo cedido arrastra su propia historia, enmiendas, servicios aprobados, avisos y restricciones específicas del espacio de nombres.

La cartera importa porque una infraestructura común no hace que los siete nombres sean operativamente idénticos..circle,.goty.jotcomparten cedente y fecha de entrada en vigor, y sus páginas de la IANA muestran un patrón similar de seis servidores de nombres con contactos de Identity Digital y RDAP.[2][3][4].onltiene una historia distinta y una solicitud actual de la empresa para añadir DPML.[5][20][21][22].safetyprocede de otro cedente y su registro de transferencia de la IANA se actualizó más tarde ese año.[6].aeroes patrocinado, lo que añade un rol comunitario y de política que no puede reducirse al modelo base no patrocinado.[7][14].网站es un dominio de primer nivel internacionalizado cuyas identidades Unicode y ASCII deben permanecer vinculadas al mismo objeto.[8][15]

Un instrumento de cesión es importante porque registra quién asume el acuerdo. Los instrumentos conservados para.circle,.onl,.aeroy.网站aportan evidencia específica de la transacción, en lugar de depender únicamente de una tabla resumen.[16][17][18][19] Sin embargo, un documento firmado no es un informe de migración de sistemas. No puede demostrar cuándo se rotaron las credenciales, qué servicios permanecieron en una plataforma existente, si cambió la titularidad de la supervisión, cómo se actualizaron los manuales de operaciones ni cuándo reflejó cada directorio público al nuevo operador.

Esa brecha es lo bastante normal como para diseñar en función de ella. Un registro de transición debería separar:

• la fecha de entrada en vigor contractual;
• los hitos de entrega operativa;
• los cambios de cuentas y credenciales del sistema de registro;
• los avisos a registradores y los cambios contractuales;
• las solicitudes de cambio de la zona raíz y su finalización;
• las actualizaciones de identidad en WHOIS y RDAP;
• la responsabilidad de claves y firmante DNSSEC;
• los contactos de custodia de datos y continuidad;
• la titularidad de seguridad, abuso y escalado de emergencias;
• las actualizaciones del sitio web público y de los documentos de política;
• la verificación desde interfaces públicas independientes.

Si estos campos se colapsan en un único indicador de «transferencia completada», los equipos pierden la capacidad de explicar estados parciales. El contrato puede estar en vigor mientras un directorio público sigue mostrando un patrocinador anterior. La plataforma puede continuar sin una migración de plataforma mientras cambia la responsabilidad jurídica. Un registrador puede aprovisionar nombres mientras una página de aviso sigue obsoleta. Cada condición exige un responsable y una vía de reparación distintos.

La estructura de la cartera también modifica el coste de supervisión. Una transferencia puede revisarse como un único objeto. Siete transferencias exigen comprobaciones por TLD y comprobaciones de cartera. Una configuración de plataforma compartida puede aplicarse a varios nombres, pero una suposición incorrecta sobre el patrocinio de.aeroo la representación de.网站puede crear igualmente un fallo específico del espacio de nombres. La reutilización reduce la implementación repetitiva; no elimina la necesidad de vincular cada acción al acuerdo y al dominio de primer nivel correctos.

Operador de registro es un rol de custodia de registros, no soberanía

Un registro de dominios de primer nivel mantiene una base de datos autoritativa de nombres registrados y da soporte a las interfaces técnicas y administrativas que la rodean. Ese rol es poderoso porque un estado de registro incorrecto puede afectar a la delegación, el ciclo de vida y los datos de registro. No es una autoridad ilimitada sobre los usuarios de Internet, los contenidos, las aplicaciones o todas las disputas asociadas a un nombre.

Las páginas públicas de acuerdos definen a Jolly Host mediante una relación de operación con dominios de primer nivel determinados.[9]-[15] Las páginas de la IANA identifican organizaciones patrocinadoras, contactos técnicos, servidores de nombres y servicios de datos de registro.[2]-[8] Son registros de un sistema por capas. La ICANN mantiene el marco de acuerdos. La IANA coordina los registros de delegación de la zona raíz. El registro opera o contrata los servicios de registro. Los registradores conectan a los titulares de dominios con el registro. Los operadores DNS sirven las zonas delegadas.

Los titulares controlan los usos dentro de los límites contractuales y de política. Otros proveedores operan alojamiento, certificados, correo, aplicaciones y contenidos.

Esta visión por capas evita dos errores opuestos. El primero es subestimar la responsabilidad del registro. Un registro debe proteger identificadores, integridad de transacciones, estado de delegación, servicios de datos de registro, metadatos de seguridad y continuidad. Calificarlo de «solo una base de datos» ignora las consecuencias operativas de la base de datos. El segundo error es exagerar su autoridad. Un registro de registro no convierte al operador en un regulador general de la expresión, el comercio o la conducta en línea.

El nombre jurídico de Jolly Host crea un riesgo de clasificación adicional. La evidencia conservada no respalda tratar a la empresa como el proveedor de alojamiento web de los dominios bajo sus dominios de primer nivel. La entidad debe evaluarse como operador de registro vinculado a acuerdos específicos. Los contactos de Identity Digital y las referencias a la plataforma muestran una relación importante de servicio técnico, pero no convierten a cada titular de dominio, registrador o servicio alojado en cliente de Jolly Host.

El control práctico es la vinculación exacta de objetos. Una acción relevante debería identificar:

• la entidad jurídica nombrada en el acuerdo aplicable;
• el dominio de primer nivel exacto, incluidas las formas ASCII y Unicode cuando corresponda;
• el registrador, titular, dominio o etiqueta protegida afectados;
• la disposición de política o acuerdo que autoriza la acción;
• el sistema técnico que la ejecutará;
• la persona o función responsable de la verificación;
• la evidencia de que el estado público resultante coincide con el cambio aprobado.

La autoridad no debe ser más amplia que el registro que la respalda. Un instrumento de transferencia puede autorizar una transición de acuerdo. No autoriza cambios arbitrarios en nombres registrados. Una enmienda DPML puede permitir un servicio de bloqueo protector. No establece que todas las reclamaciones de marca sean válidas. Un registro de la zona raíz puede identificar un estado de delegación. No prueba quién posee todos los servidores ni controla todas las redes subyacentes.

El estado contractual y el estado de la zona raíz son libros distintos

El contraste público más útil en el registro de Jolly Host se da entre las páginas de contratos de la ICANN y las páginas de delegación de la IANA. El libro de cesiones completadas de la ICANN enumera los siete acuerdos como cedidos a Jolly Host, y las páginas de acuerdos correspondientes presentan a Jolly Host como operador.[1][9]-[15] La IANA enumera a Jolly Host como organización patrocinadora de.circle,.got,.jot,.only.safety.[2]-[6] En el momento de la observación, la página de.aeronombra a SITA como organización patrocinadora y la página de.网站nombra a Global Website TLD Asia Limited.[7][8]

Este artículo no infiere la causa de esa diferencia. Los sistemas públicos pueden tener flujos de actualización, requisitos de revisión, fechas de entrada en vigor o calendarios de publicación distintos. Una cesión contractual puede estar completada antes de que se presente o muestre un cambio de gestión de la zona raíz. Un TLD patrocinado puede conservar una relación de patrocinio distinta del titular del acuerdo de registro. Una página también puede ir con retraso o reflejar un rol cuyo significado difiere del de «operador». Sin el caso de cambio y el registro de autoridad pertinentes, una afirmación más contundente sería especulación.

La diferencia demuestra igualmente por qué importa la conciliación. Un responsable de transición no debería preguntar solo si «la empresa cambió». Debería comparar campos exactos entre libros independientes:

La conciliación necesita un modelo de tolerancia. Algunas diferencias son esperables durante una transición controlada. Otras son errores. El registro debería identificar qué campos deben cambiar antes de la fecha de entrada en vigor, cuáles pueden cambiar después, el retraso máximo aceptable, el responsable de cada cambio y la prueba que lo cierra. Sin ese modelo, los equipos tratan cada diferencia como una emergencia o permiten registros obsoletos indefinidamente.

El principio del código en ejecución da prioridad al comportamiento público al evaluar lo que realmente encuentran los resolutores y los clientes. Si la raíz delega en un conjunto de servidores de nombres, esa delegación gobierna la resolución DNS con independencia de la etiqueta de una página contractual. Si un arranque RDAP dirige a los clientes a un servicio, las respuestas del extremo importan operativamente. Pero el comportamiento en ejecución no borra la responsabilidad jurídica. El operador debe poder mostrar quién autorizó el estado y por qué es coherente con el acuerdo.

Plataforma compartida: beneficio de continuidad y concentración de dependencias

Los registros de la IANA identifican repetidamente contactos administrativos o técnicos de Identity Digital y publican un servicio RDAP de Identity Digital.[2]-[8] La solicitud de Jolly Host para.onlafirma que los dominios de primer nivel participantes reciben servicio de la plataforma de Identity Digital y describe a Jolly Host como operador de registro filial de Identity Digital.[21] Estas declaraciones respaldan un modelo de servicio compartido. No revelan su arquitectura completa.

Una plataforma de registro compartida puede reducir el riesgo de migración. Si un acuerdo cambia de manos dentro de un grupo organizativo o una relación de servicio mientras la plataforma técnica permanece estable, puede no ser necesario sustituir a la vez todos los servidores de nombres, extremos EPP, servicios RDAP, rutas de despliegue o sistemas de supervisión. La continuidad puede preservar la integración con los registradores y reducir el número de cambios simultáneos.

El mismo diseño concentra dependencias. Un defecto de la plataforma, un error de configuración, un problema de credenciales, un fallo de despliegue o un incidente del plano de control pueden afectar a varios dominios de primer nivel. Los contactos compartidos pueden crear ambigüedad sobre si un problema corresponde al operador jurídico, al proveedor de la plataforma o a otra filial. Una transición que parece sencilla porque la infraestructura no se mueve puede fracasar igualmente si la rendición de cuentas, el acceso a los datos, el escalado o los derechos de salida no están claros.

El modelo de supervisión debería tratar, por tanto, la responsabilidad jurídica y la ejecución técnica como campos separados. Para cada función de registro, debe registrarse:

• el operador responsable del acuerdo;
• el proveedor de servicios técnicos;
• el sistema de registro;
• la autoridad de escritura;
• la autoridad de aprobación;
• el responsable de supervisión;
• el responsable de incidentes;
• el responsable de retención de datos y evidencia;
• la dependencia de recuperación;
• el servicio sustituto o la vía de salida;
• la verificación realizada por el operador y no únicamente por el proveedor.

La externalización no elimina la necesidad de comprender la superficie de control. El operador no necesita reproducir todos los detalles de implementación, pero sí evidencia suficiente para aprobar cambios, investigar excepciones, verificar el estado público, cumplir las obligaciones del acuerdo y gestionar una transición de proveedor. Una cláusula contractual sin verificación técnica es incompleta. Un panel de supervisión sin asignación de autoridades también es incompleto.

La infraestructura compartida complica la medición. Seis servidores de nombres no son seis dominios de fallo independientes solo porque tengan etiquetas distintas. Varios extremos pueden compartir redes, software, controles de despliegue, credenciales o personal de operaciones. A la inversa, un dominio de servicio común no prueba que todos los componentes compartan un único modo de fallo. La diversidad física y administrativa exige evidencia más allá del recuento de extremos.

Las fuentes conservadas no aportan una topología auditada, un informe de disponibilidad, un historial de incidentes, una prueba de recuperación ni un resultado de nivel de servicio del proveedor. Un artículo serio debe dejar esos valores como desconocidos. El registro público respalda preguntas para la diligencia debida:

1. ¿Qué funciones de registro presta Identity Digital para cada acuerdo cedido?
2. ¿Qué credenciales y aprobaciones de cambios controla Jolly Host?
3. ¿Cómo verifica Jolly Host de forma independiente el estado de DNS, RDAP, WHOIS, custodia y de cara a los registradores?
4. ¿Qué dependencias son comunes a los siete nombres?
5. ¿Qué evidencia demuestra que la restauración puede preservar la identidad de los objetos y las transacciones recientes?
6. ¿Cuál es la vía acotada si cambia la relación con el proveedor compartido?

Se trata de requisitos de control, no de acusaciones de que falte un control.

Delegación DNS y el coste del estado exacto

Las páginas de la IANA exponen una parte concreta de la capa de ejecución: nombres de servidores de nombres autoritativos, direcciones IPv4 e IPv6, contactos y extremos de datos de registro.[2]-[8] Para.circle,.got,.joty.safety, el patrón visible de servidores de nombres utiliza varios hostsv0n*yv2n*con ambas familias de direcciones..onl,.aeroy.网站muestran patrones de nombres de host distintos.[2]-[8] Esa variación basta para exigir una verificación por objeto.

Un cambio de delegación puede fallar de varias formas:

• el conjunto de servidores de nombres aprobado difiere del presentado;
• las direcciones glue faltan, están obsoletas o asociadas al host incorrecto;
• las rutas IPv4 e IPv6 se comportan de forma distinta;
• algunos servidores autoritativos sirven una versión de zona diferente;
• el material DNSSEC del padre no coincide con el del hijo;
• la supervisión consulta cachés recursivas en lugar del estado autoritativo;
• un operador valida el nombre legible pero cambia el objeto ASCII incorrecto;
• un proveedor actualiza su plataforma mientras la solicitud de zona raíz sigue pendiente;
• las instrucciones de reversión identifican servidores pero no el estado de seguridad correspondiente.

El modelo correcto separa el estado previsto, el registrado y el observado. El estado previsto procede del cambio autorizado. El estado registrado procede de los registros del registro y de la zona raíz. El estado observado procede de consultas de protocolo contra la ruta autoritativa. Una operación solo se cierra cuando los tres coinciden dentro de una tolerancia explícita.

El almacenamiento en caché hace que el tiempo importe. Un cambio correcto de la zona raíz no aparece en todas partes al instante, y una ruta obsoleta puede seguir respondiendo desde cachés. La evidencia debería registrar la hora de observación, el punto de observación, el comportamiento del resolutor y si la consulta alcanzó servidores autoritativos. «Resuelve» no es suficiente. La respuesta podría proceder de una caché, omitir la validación DNSSEC o representar solo una familia de direcciones.

La automatización puede realizar comparaciones, pero necesita identificadores exactos y comprobaciones semánticas. Un código de respuesta DNS correcto no prueba que se haya servido la zona esperada. Un sistema de supervisión debería verificar el dominio de primer nivel, la identidad del servidor autoritativo, las propiedades SOA esperadas, la cadena DNSSEC cuando corresponda y la coherencia entre extremos. Las pruebas negativas deberían confirmar que los nombres inexistentes y las solicitudes malformadas reciben el tratamiento esperado.

Las páginas de origen no proporcionan mediciones DNS longitudinales de Jolly Host. Este artículo no afirma disponibilidad, latencia, cobertura anycast, capacidad de consulta ni rendimiento de conmutación por error. Identifica el estado que una transición de registro debe supervisar y las pruebas que producirían evidencia defendible.

RDAP, WHOIS y corrección semántica

Las páginas de la IANA publican extremos RDAP para los espacios de nombres asignados, y algunas también publican información del servicio WHOIS.[2]-[8] Estos servicios exponen datos de registro sujetos a restricciones de política y acceso. No son intercambiables con el DNS. El DNS responde si un nombre resuelve a través de la ruta de delegación; RDAP y WHOIS responden preguntas sobre objetos y eventos del registro.

El riesgo de transición aparece cuando no se preservan la identidad y el historial de eventos. Un extremo puede devolver un éxito HTTP mientras sirve el objeto incorrecto, información obsoleta del registrador, un estado incorrecto o fechas de eventos con procedencia poco clara. Un servicio puede ser accesible pero omitir datos exigidos por el perfil aplicable. Un cliente puede seguir un registro de arranque obsoleto. Las vistas públicas y autenticadas pueden diferir por diseño.

La supervisión semántica debería verificar:

• el objeto consultado exacto y el dominio de primer nivel;
• la conformidad de la respuesta y el tipo de contenido;
• la identidad del servicio autoritativo;
• los campos de registrador y estado esperados para un objeto de prueba controlado;
• el orden de los eventos y las marcas de tiempo;
• las referencias a servidores de nombres;
• los datos de delegación segura cuando existan;
• el comportamiento de redacción y acceso exigido por la política;
• las respuestas esperadas de no encontrado y consultas malformadas;
• la coherencia con el estado autoritativo del registro.

Un servicio RDAP compartido puede simplificar el comportamiento de los clientes en varios nombres, pero aumenta la necesidad de pruebas de enrutamiento. El servicio debe seleccionar el espacio de nombres y el objeto correctos. Un error de configuración que asocie un TLD a la política o al almacén de datos incorrectos puede producir una salida plausible pero incorrecta. Una supervisión solo de transporte puede no detectarlo.

WHOIS introduce un coste de mantenimiento adicional porque los clientes, los formatos de salida, los controles de frecuencia y las expectativas heredadas difieren de RDAP. Si ambos servicios siguen publicados, los operadores deben definir qué campos deben coincidir, qué diferencias están motivadas por la política y qué servicio es autoritativo para una pregunta determinada. Una discrepancia no es automáticamente un fallo, pero necesita una explicación.

Ninguna fuente conservada mide la fiabilidad de RDAP o WHOIS de Jolly Host ni la calidad de los datos a lo largo del tiempo. Los extremos publicados establecen una superficie de servicio. No establecen satisfacción del cliente, distribuciones de tiempo de respuesta, resistencia al abuso ni resultados de corrección.

DPML: capacidad declarada, fiabilidad del producto y resultados de producción

La solicitud RSEP de Jolly Host para.onlcrea un ejemplo útil de cómo separar tres categorías de evidencia. La solicitud propone añadir el servicio Domains Protected Marks List al acuerdo de.onl. Describe una suscripción que puede bloquear etiquetas exactas o variantes de la disponibilidad general en los dominios de primer nivel participantes atendidos por la plataforma de Identity Digital.[21] El libro RSEP de la ICANN muestra la solicitud como aprobada, y el inventario del acuerdo de.onlcontiene una enmienda asociada al servicio.[20][22]

En la capa decapacidad, el escrito describe lo que el servicio pretende hacer. Una etiqueta que cumpla los requisitos puede retirarse del conjunto de disponibilidad general en los espacios de nombres participantes. Un titular de derechos u otra parte elegible puede necesitar más adelante una vía de anulación o desbloqueo. El escrito vincula el servicio al lenguaje de servicios aprobados y a las disposiciones de nombres reservados.[21]

En la capa defiabilidad del producto, el escrito afirma que Identity Digital opera el servicio desde 2013 y que se prueba mediante un conjunto automatizado de garantía de calidad para los despliegues del sistema.[21] Es una declaración relevante de la empresa. No es un resultado de fiabilidad auditado de forma independiente. La fuente no publica casos de prueba, cobertura, tasas de fallo, tasas de bloqueo erróneo, resultados de reversión ni datos de incidentes.

En la capa deresultados de producción, el escrito no proporciona recuentos de adopción, retención de clientes, abusos evitados, infracciones no detectadas, carga de soporte de los registradores, volumen de disputas ni impacto económico. Afirma que el mercado principal es el canal de registradores corporativos y que la adición propuesta no debería tener efectos sobre la competencia, los precios de registro, los datos de registro ni el comportamiento DNS.[21] Son afirmaciones acotadas realizadas en una solicitud regulatoria, no resultados observados universales.

El servicio también reubica trabajo en lugar de eliminarlo. Un bloqueo puede reducir la actividad repetitiva de registro, pero crea vías de supervisión y excepción:

• validar la elegibilidad y las marcas protegidas;
• generar etiquetas exactas y variantes;
• aplicar el conjunto correcto de TLD participantes;
• prevenir un bloqueo excesivamente amplio;
• permitir que otro titular legítimo de derechos registre;
• gestionar erratas y disputas de variantes;
• sincronizar plazos y renovaciones;
• notificar a los registradores;
• preservar evidencia de auditoría;
• revertir un control incorrecto o caducado;
• verificar que el DNS y los registros existentes no se vean afectados.

Un control que bloquea registros es relevante incluso si no modifica el DNS de dominios existentes. Los falsos positivos pueden impedir registros legítimos. Los falsos negativos pueden dejar disponible una etiqueta esperada. Una anulación puede autorizarse incorrectamente. Una actualización de cartera puede incluir el dominio de primer nivel equivocado. Una suscripción puede caducar sin el cambio de estado esperado.

La solicitud afirma que el servicio no debería afectar a la resolución DNS, los archivos de zona, el ciclo de vida de los dominios, el almacenamiento de datos del registro, el tiempo de respuesta, la coherencia ni la consistencia.[21] Un plan de verificación de producción traduciría esas afirmaciones en comprobaciones medibles antes y después de la activación. Compararía el estado de la zona y de los datos de registro, ejecutaría pruebas de etiquetas positivas y negativas, verificaría el comportamiento de los registradores, probaría la autoridad de anulación y confirmaría la reversión. El escrito público no publica esos resultados.

Integración con registradores y cambio contractual

Las transiciones de registro y los nuevos servicios de registro llegan a los registradores. El registro público de listas de correo de la ICANN incluye avisos de enmienda del acuerdo de registrador de.only una notificación de aprobación asociada a Jolly Host.[23] Esa evidencia muestra una superficie de cambio en el canal de registradores; no revela la implementación ni la experiencia de producción de cada registrador.

La integración con registradores tiene al menos cuatro capas:

1. Contrato y aviso.Los registradores necesitan los términos aplicables, la fecha de entrada en vigor y el alcance.
2. Comportamiento del protocolo.Los comandos EPP, extensiones, códigos de error y estados de objeto deben coincidir con el servicio documentado.
3. Preparación operativa.Las credenciales, entornos de prueba, contactos de soporte, supervisión y conciliación deben estar actualizados.
4. Flujo de trabajo del cliente.Las interfaces del registrador deben explicar con precisión bloqueos, anulaciones, renovaciones y excepciones.

Un registro puede desplegar un cambio de plataforma correcto mientras un registrador lo gestiona mal. Un registrador puede implementar una interfaz correcta sobre términos obsoletos. Un equipo de soporte puede entender la política mientras clientes automatizados reintentan incorrectamente una transacción incierta. Por tanto, la preparación de extremo a extremo no puede inferirse de una sola capa.

Los resultados de escritura inciertos son un modo de fallo recurrente. Si un cliente envía un comando EPP y pierde la respuesta, un reintento ciego puede duplicar o entrar en conflicto con la primera operación. La vía más segura es conservar un identificador de transacción, consultar el estado autoritativo del objeto, compararlo con el estado previsto y reintentar solo cuando la conciliación lo respalde. El mismo principio se aplica a los bloqueos protectores y las anulaciones.

Las ventanas de cambio deberían identificar la compatibilidad con versiones anteriores y el comportamiento de denegación ante fallo. Si un registrador no reconoce un nuevo estado de servicio, ¿debe rechazar la solicitud, mostrar una explicación acotada o enviarla a revisión? Una degradación silenciosa puede crear expectativas de cliente incoherentes. Un mensaje de error ilimitado puede exponer detalles internos sin ayudar a la recuperación.

El coste de la documentación forma parte de la fiabilidad de producción. Los términos, la documentación de protocolo, los casos de prueba, los procedimientos de soporte y las expectativas de supervisión deben referirse a la misma versión y fecha de entrada en vigor. Un servicio no es operativamente maduro solo porque el código central acepte un comando.

El límite de política patrocinada de.aero

.aerodifiere de los otros seis acuerdos porque la ICANN lo presenta como un dominio de primer nivel patrocinado.[14] Un espacio de nombres patrocinado tiene una comunidad definida y responsabilidades de política delegadas. El registro de cesión de 2026 nombra a Jolly Host como cesionaria del acuerdo, mientras que la página de la IANA observada para este artículo sigue nombrando a SITA como organización patrocinadora y muestra contactos técnicos de Identity Digital.[1][7][18]

Esos registros no deben simplificarse en una afirmación de que una parte es «dueña» del espacio de nombres de aviación. Los roles relevantes pueden incluir operador del acuerdo, patrocinador, autoridad de política, plataforma técnica, registrador, titular de dominio y coordinador de la zona raíz. Un cambio en un rol no borra necesariamente los demás.

La elegibilidad patrocinada crea trabajo adicional de excepción. Un flujo de registro genérico pregunta si una etiqueta está disponible y si el titular cumple los términos básicos. Un flujo patrocinado también puede exigir evidencia de que un titular pertenece a la comunidad definida o cumple los requisitos de una categoría. Eso introduce interpretación de política, validación, apelaciones, renovaciones y transiciones cuando cambia la elegibilidad.

La automatización puede comprobar evidencia estructurada y aplicar reglas claras. No puede hacer desaparecer preguntas de política ambiguas. Si un registro está incompleto, el sistema necesita un estado de retención acotado en lugar de aceptarlo silenciosamente o rechazarlo de forma permanente. Los revisores necesitan la versión exacta de la regla, la evidencia aportada, la decisión, la autoridad y la vía de corrección.

El límite patrocinado también importa durante la recuperación. Restaurar objetos de dominio sin restaurar la evidencia de elegibilidad, las versiones de política o las decisiones de excepción puede producir un registro técnicamente válido pero institucionalmente incompleto. Las pruebas de copia de seguridad deberían incluir relaciones y procedencia, no solo etiquetas y códigos de estado.

Las fuentes conservadas no establecen el volumen de registro de.aero, los resultados de política, la frecuencia de disputas ni el impacto de la transición. Establecen un tipo de acuerdo distinto y un registro público multirrol que exige una conciliación cuidadosa.

El límite IDN de.网站

El séptimo acuerdo cedido está representado por la etiqueta ASCII.xn--5tzm5gy la etiqueta Unicode.网站, que significa «sitio web».[8][15][19] Ambas representaciones se refieren al mismo objeto de dominio de primer nivel, pero el software, los registros, las interfaces de usuario, las políticas y el personal pueden tratarlas de forma distinta.

Los errores de identidad son previsibles:

• un ticket usa la forma Unicode mientras una API espera ASCII;
• un registro almacena una forma y una regla de supervisión busca la otra;
• una cadena copiada contiene una secuencia de puntos de código inesperada;
• un informe trata la traducción «sitio web» como un objeto distinto;
• un cambio se aplica a una etiqueta visualmente similar pero distinta;
• un panel muestra Unicode sin preservar la representación en la red;
• una página de acuerdo y un registro de la zona raíz se comparan con normalizaciones incoherentes.

Todos los registros duraderos deberían preservar la etiqueta ASCII exacta, la forma Unicode, el método de conversión y el identificador interno canónico. La presentación legible no debe sustituir a la identidad de protocolo. Una lista de comprobación de transición que solo diga «TLD de sitio web» es insegura porque la frase puede referirse al concepto en inglés y no al objeto delegado.

Las operaciones IDN también implican política y representación de datos de registro. Los registradores necesitan reglas de entrada probadas. Las salidas RDAP y WHOIS necesitan una identidad predecible. Las herramientas DNS necesitan nombres seguros para la red. Las revisiones de seguridad deben distinguir la internacionalización legítima de las etiquetas visualmente engañosas. Estas preocupaciones no justifican tratar todos los IDN como riesgosos; justifican una ingeniería exacta.

La página de contrato de la ICANN observada presenta a Jolly Host como operador, mientras que la página de la IANA nombra a Global Website TLD Asia Limited como organización patrocinadora e identifica contactos técnicos de Identity Digital.[8][15] Es un ejemplo especialmente claro de por qué los registros jurídicos, de delegación y de servicio técnico deben compararse sin forzarlos a un único campo simplista de propietario.

Ninguna fuente conservada establece la adopción de IDN, la experiencia de usuario, las tasas de abuso, la frecuencia de errores de conversión ni los resultados para clientes de este registro. Esos datos exigen conjuntos de datos y métodos definidos.

DNSSEC y metadatos de seguridad en una transición

DNSSEC hace más sensibles las transiciones de registro porque los metadatos de seguridad del padre deben permanecer alineados con el estado de firma del hijo. Las páginas de delegación de la IANA exponen información de servidores de nombres y el contexto más amplio de la zona raíz, pero los registros conservados no revelan la custodia de claves privadas, la arquitectura de firma, los procedimientos de rotación ni el historial de incidentes.[2]-[8]

Una transición debe identificar quién controla:

• las operaciones de firma de claves y de zona;
• la autoridad de envío de DS;
• la aprobación de cambios;
• la rotación de emergencia;
• la supervisión desde resolutores validadores;
• el material y el acceso de recuperación;
• la evidencia de auditoría;
• el escalado con proveedores.

Cambiar la identidad jurídica del operador no exige necesariamente cambiar las claves DNSSEC. Cambiar la plataforma técnica sí podría. Cualquier decisión exige un registro explícito. Mantener las claves puede reducir los cambios simultáneos, pero puede conservar dependencias de accesos o procedimientos anteriores. Rotar las claves puede mejorar la separación, pero crea riesgo de temporización y reversión.

La secuencia segura depende del diseño real, que no es público aquí. Los controles generales incluyen la observación dual del estado del padre y del hijo, rotaciones escalonadas, validación independiente, tiempos de retención explícitos, condiciones de reversión y preservación de los identificadores exactos de claves y del material de resumen. Las claves privadas nunca deben aparecer en la evidencia operativa ordinaria.

Una consulta de validación correcta demuestra una ruta acotada en un momento dado. No demuestra una validación continua ni una recuperación segura. La supervisión debería distinguir respuestas no firmadas, fallos de validación, datos obsoletos, errores de transporte e incoherencia autoritativa. También debería verificar ambas familias de direcciones cuando estén publicadas.

Los metadatos de seguridad ilustran la diferencia entre redundancia e independencia. Varios servidores autoritativos pueden servir todos un conjunto de firmas roto. Varios monitores pueden compartir el mismo resolutor o red. Un control fiable exige observaciones diversas y un modelo de estado esperado, no simplemente más indicadores verdes.

Continuidad de datos, custodia y evidencia de recuperación

La continuidad del registro no se limita a mantener el DNS en línea. El registro debe preservar la identidad de los objetos, el estado del ciclo de vida, las relaciones con los registradores, los datos de registro, los datos de servidores de nombres, los metadatos de seguridad, los servicios aprobados, la procedencia de la política y el historial de transacciones de forma suficiente para operar y recuperarse dentro de sus obligaciones.

Una cesión de acuerdo cambia quién es responsable de esa continuidad. Los instrumentos de cesión muestran la asunción de relaciones contractuales para los acuerdos nombrados.[16]-[19] No muestran el método de migración de datos ni la prueba de recuperación. Si la misma plataforma continúa, puede que no se produzca una migración masiva de datos, pero el acceso, la autoridad, la custodia y la titularidad de la recuperación siguen necesitando revisión.

Las copias de seguridad no son prueba de recuperación. Una copia puede estar completa en la capa de almacenamiento e inutilizable en la capa de registro. Puede omitir transacciones recientes, usar identificadores que ya no coinciden con los registros públicos, depender de claves no disponibles o restaurarse en un software que interpreta la política de forma distinta. La evidencia de recuperación debería demostrar:

1. recuentos exactos de objetos e identificadores dentro de un conjunto de prueba acotado;
2. integridad referencial entre dominios, contactos, registradores, hosts y eventos de estado;
3. coherencia de las salidas DNS y de datos de registro tras la restauración;
4. preservación de los metadatos de seguridad y la procedencia de la política;
5. conciliación de transacciones posteriores al punto de recuperación;
6. reentrada controlada a las escrituras;
7. verificación independiente contra los registros públicos de delegación y servicio.

La recuperación de la cartera exige límites por TLD. Una plataforma común puede restaurar varios registros, pero la política, el acuerdo, el IDN, el patrocinio y las configuraciones de servicio difieren. Una restauración que aplique la configuración de un espacio de nombres a otro puede producir un comportamiento sintácticamente válido pero semánticamente incorrecto.

La continuidad también incluye personas y proveedores. Las credenciales, los contactos de escalado, la autoridad jurídica y los derechos de decisión deben sobrevivir a cambios de personal o corporativos. Un manual que dependa de una persona no disponible no es un plan de recuperación. Un proveedor que puede restaurar infraestructura pero no puede autorizar un cambio de la zona raíz no puede cerrar el incidente por sí solo.

Las fuentes públicas no demuestran el calendario de copias de seguridad de Jolly Host, el estado de custodia, el objetivo de punto de recuperación, el objetivo de tiempo de recuperación ni los resultados de pruebas. La conclusión defendible es más restringida: los acuerdos cedidos y la relación de servicio compartido crean obligaciones concretas de continuidad cuya evidencia debe abarcar las capas jurídica y de ejecución.

Coste de supervisión, integración, mantenimiento y excepciones

La cartera de siete registros produce cuatro categorías de coste recurrentes.

El coste de supervisióncubre la autoridad y la evidencia. El personal debe saber qué entidad, acuerdo, dominio de primer nivel, servicio y proveedor están implicados. Los cambios de alto impacto necesitan aprobación, separación de funciones y verificación. Los casos de política patrocinada e IDN exigen contexto adicional. Los servicios de bloqueo automatizado exigen controles de elegibilidad y anulación.

El coste de integracióncubre los límites entre los registros de la ICANN, la delegación de la IANA, los sistemas de registro, los registradores, RDAP y WHOIS, DNS y DNSSEC, los documentos de política y las interfaces de los proveedores. Un campo correcto en un sistema puede estar obsoleto en otro. El trabajo de integración incluye el mapeo de identificadores, versiones, errores, contactos y fechas de entrada en vigor.

El coste de mantenimientocrece con el tiempo. Las credenciales caducan. Los contactos cambian. Los acuerdos reciben enmiendas. Las configuraciones de política y servicio evolucionan. Los certificados rotan. Las claves DNSSEC se rotan. Los registradores entran y salen. Las expectativas de supervisión cambian. Los registros públicos necesitan revisión. Una plataforma estable reduce parte del trabajo de migración, pero no detiene la deriva del ciclo de vida.

El coste de gestión de excepcionescubre los casos que no encajan en la ruta rutinaria: escrituras inciertas, registros públicos no coincidentes, bloqueos incorrectos de etiquetas, solicitudes legítimas de anulación, confusión en la representación IDN, disputas de elegibilidad patrocinada, datos de registro obsoletos, incidentes de proveedores, DNSSEC roto, transiciones de registrador fallidas y divergencias de recuperación.

La automatización puede reducir la comparación y validación repetitivas. También reubica el trabajo en el diseño de reglas, el mantenimiento del estado esperado, el control de acceso, la supervisión y la revisión de excepciones. La pregunta relevante no es si una tarea se volvió automática. Es si el trabajo total y el riesgo disminuyeron después de añadir la supervisión necesaria para confiar en la automatización.

Un registro de costes útil registra volumen y esfuerzo solo cuando se miden. No debe inventarlos. Los equipos pueden hacer un seguimiento del número de transiciones, discrepancias, revisiones manuales, transacciones inciertas, eventos de reversión y tiempo de conciliación. Sin un método y un intervalo temporal, una cifra numérica es decoración.

El conjunto de fuentes actual no proporciona mediciones internas de Jolly Host. Respalda un modelo de coste cualitativo y un plan de pruebas, no una afirmación cuantificada de eficiencia.

Registro de modos de fallo

Los siguientes son escenarios previsibles derivados de la superficie de control documentada. No son afirmaciones de que Jolly Host haya experimentado esos fallos.

Entidad jurídica incorrecta.Un cambio se autoriza utilizando un registro de cedente o filial después de la fecha de entrada en vigor del acuerdo. Control: vincular la autoridad al acuerdo, instrumento, identificador de entidad y momento de entrada en vigor exactos.

Desajuste entre contrato y raíz.Una página de acuerdo y una página de delegación muestran partes distintas sin explicación registrada. Control: clasificar los significados de los roles, identificar el calendario esperado, asignar un responsable de conciliación y preservar el caso de cambio.

Dominio de primer nivel incorrecto.Una acción de cartera incluye un espacio de nombres no previsto. Control: listas permitidas exactas, revisión por TLD, comparación en seco y verificación de protocolo posterior al cambio.

Alcance excesivo de la plataforma compartida.Una configuración común se supone válida para un espacio de nombres patrocinado o IDN. Control: perfiles de excepción explícitos y pruebas negativas específicas del espacio de nombres.

Resultado de aprovisionamiento incierto.Un registrador pierde la respuesta a una escritura. Control: evidencia de transacción, consulta del estado autoritativo, diseño idempotente y reintento acotado.

Falsa salud de RDAP.El extremo devuelve éxito para el objeto incorrecto o un estado obsoleto. Control: aserciones semánticas, comparación de eventos y pruebas de error esperado.

Divergencia WHOIS/RDAP.Los servicios muestran identidad o información de ciclo de vida incoherentes. Control: mapeos de campos documentados, comparación consciente de la política y titularidad de la corrección.

Error de delegación DNS.Los registros de servidores de nombres o glue difieren del estado aprobado. Control: comparación previsto-registrado-observado en IPv4 e IPv6.

Ruptura de la cadena DNSSEC.El material de seguridad del padre y del hijo deja de estar alineado. Control: cambio escalonado, validación independiente, tiempos de retención y reversión probada.

Falso positivo de DPML.Una etiqueta legítima se bloquea sin autoridad aplicable. Control: evidencia de elegibilidad, versión exacta de la regla, vía de anulación y estado reversible.

Falso negativo de DPML.Una etiqueta protegida sigue disponible porque el conjunto de participación o la lógica de variantes son incorrectos. Control: corpus de pruebas positivas y negativas, comprobaciones de mapeo de TLD y supervisión de renovaciones.

Confusión de objetos IDN.La presentación Unicode y la identidad ASCII en la red divergen en registros o herramientas. Control: preservar ambas formas y un identificador canónico.

Pérdida de política patrocinada.La recuperación restaura el estado del dominio pero no la evidencia de elegibilidad ni las decisiones de política. Control: incluir procedencia y relaciones en las pruebas de recuperación.

Deriva de credenciales.Antiguos empleados o proveedores conservan acceso, o certificados necesarios caducan. Control: inventario de titularidad, rotación, revocación, supervisión de caducidad y revisión de transición.

Fallo de dependencia compartida.Varios TLD se ven afectados por un fallo de plataforma o del plano de control. Control: mapeo de dependencias, pruebas de radio de impacto, despliegue escalonado y reversión acotada.

Divergencia de recuperación.El estado interno restaurado no coincide con la delegación pública actual ni con las transacciones recientes. Control: conciliación de transacciones y verificación independiente del estado público antes de reanudar escrituras.

Cada escenario necesita un responsable, una señal de detección, un requisito de evidencia, una autoridad de decisión, una vía de corrección y una prueba de cierre. Una lista de comprobación sin responsable no es un control. Una alerta sin modelo de estado esperado es ruido.

Un marco práctico de revisión

Para Jolly Host y las partes dependientes, la evidencia pública respalda un marco de revisión disciplinado.

Primero,preservar la identidad exacta. Utilizar la entidad empresarial, el acuerdo, el TLD, la etiqueta ASCII y Unicode cuando corresponda, el registrador, el dominio, el servicio y los identificadores de transacción. No inferir el rol técnico a partir del nombre de la empresa.

Segundo,separar los libros. Los registros contractuales, de zona raíz, de sistema de registro, de registrador y de proveedor responden preguntas distintas. Compararlos sin forzarlos a un único campo de propietario.

Tercero,separar la capacidad de la fiabilidad y los resultados. Los documentos de acuerdos y RSEP establecen capacidad autorizada o declarada. Las observaciones de protocolo establecen un comportamiento actual acotado. La fiabilidad y los resultados para clientes exigen evidencia longitudinal.

Cuarto,mapear las partes responsables y ejecutoras. Una plataforma compartida puede aportar continuidad, pero el operador del acuerdo sigue siendo responsable de saber quién puede aprobar, escribir, supervisar, recuperar y verificar.

Quinto,tratar las transiciones como máquinas de estado. Registrar hitos y campos incompletos en lugar de un único indicador de finalización. Definir calendarios aceptables y escalado para las diferencias.

Sexto,probar el significado, no solo la accesibilidad. Las comprobaciones de DNS, RDAP, WHOIS, EPP, bloqueo y recuperación deben verificar el objeto, estado, política y relación de seguridad correctos.

Séptimo,preservar los casos especiales. El patrocinio de.aeroy la internacionalización de.网站son dimensiones de control de primer orden, no etiquetas que normalizar.

Octavo,diseñar vías de excepción antes del despliegue. Las escrituras inciertas, los desajustes de registros, las solicitudes de anulación, las disputas de elegibilidad, los problemas de claves y los fallos de proveedores no se resolverán por la vía rutinaria.

Noveno,hacer reversibles las acciones de alto impacto cuando sea posible. Los bloqueos protectores, los cambios de configuración y los pasos de transición necesitan una reversión acotada y verificación posterior a la acción.

Décimo,informar de la incertidumbre con honestidad. La ausencia de un incidente público no es una medición de disponibilidad. Una solicitud exitosa no es un resultado para el cliente. Una referencia a un servicio compartido no es una arquitectura completa.

Conclusión

El registro público de Jolly Host muestra una superficie real de control de Internet. La ICANN registra siete cesiones de acuerdos de registro a la empresa en 2026, que cubren nombres base no patrocinados, un espacio de nombres patrocinado y un espacio de nombres internacionalizado.[1][9]-[19] Los registros de la IANA exponen el estado actual de delegación, servidores de nombres, contactos, WHOIS y RDAP, incluidas diferencias en la organización patrocinadora mostrada para.aeroy.网站en el momento de la observación.[2]-[8]

La solicitud DPML de.onlañade una capa de servicio específica de la empresa. Describe una capacidad de bloqueo protector prestada a través de la plataforma de Identity Digital, formula afirmaciones acotadas de seguridad y estabilidad e identifica el canal de registradores corporativos.[20][21][22] No proporciona resultados de fiabilidad independientes ni resultados para clientes.

La carga de ingeniería consiste en mantener alineadas la autoridad y el comportamiento en ejecución sin fingir que son lo mismo. Eso exige identificadores exactos, registros de transición por TLD, mapeo de dependencias de la plataforma compartida, pruebas semánticas de DNS y datos de registro, control de cambios de los registradores, disciplina del ciclo de vida DNSSEC, preservación de la política patrocinada, controles de identidad Unicode, anulaciones acotadas de bloqueo protector, evidencia de recuperación y titularidad explícita de las excepciones.

Los registros públicos establecen el operador y la superficie de control. No establecen la arquitectura privada, la disponibilidad auditada, la tasa de incidentes, el rendimiento de recuperación, el volumen de registro, los ingresos, la adopción ni el éxito con clientes. Esas afirmaciones quedan fuera de la evidencia.

La imagen destacada es solo un contexto genérico de infraestructura generado. No representa a Jolly Host, Identity Digital, ICANN, IANA, ningún dominio de primer nivel asignado, una instalación real, una arquitectura real, una fiabilidad medida, un incidente ni resultados para clientes.

Fuentes

1. ICANN: Cesiones completadas de acuerdos de registro
2. IANA: Registro de delegación de.CIRCLE
3. IANA: Registro de delegación de.GOT
4. IANA: Registro de delegación de.JOT
5. IANA: Registro de delegación de.ONL
6. IANA: Registro de delegación de.SAFETY
7. IANA: Registro de delegación de.AERO
8. IANA: Registro de delegación de.网站
9. ICANN: Acuerdo de registro de.circle
10. ICANN: Acuerdo de registro de.got
11. ICANN: Acuerdo de registro de.jot
12. ICANN: Acuerdo de registro de.onl
13. ICANN: Acuerdo de registro de.safety
14. ICANN: Acuerdo de patrocinio del TLD.aero
15. ICANN: Acuerdo de registro de.网站
16. ICANN: Acuerdo de cesión y asunción de.circle
17. ICANN: Acuerdo de cesión y asunción de.onl
18. ICANN: Acuerdo de cesión y asunción de.aero
19. ICANN: Acuerdo de cesión y asunción de.网站
20. ICANN: Proceso de la Política de evaluación de servicios de registro y solicitudes presentadas
21. ICANN: Solicitud RSEP de DPML para.onl de Jolly Host
22. ICANN: Enmienda al acuerdo de registro de.onl sobre DPML
23. Avisos públicos de acuerdos de registrador de la ICANN