Resumen

  • ICANN recibe comentarios entre el 10 de agosto y el 21 de septiembre de 2026 sobre el informe inicial del Technical Study Group para integrar gTLD del DNS global con sistemas de nombres alternativos.
  • La regla principal es la integración de «cadena + controlador»: el nombre y quien lo controla deben coincidir en todos los sistemas, mediante un sistema de registro compartido o una fuente de verdad unificada aunque la operación esté distribuida.
  • El informe no avala la integración. Cada operador deberá obtener una autorización individual por RSEP o por el procedimiento de la ronda 2026, y el lenguaje contractual se publicará después en otra consulta.
  • Queda fuera del estudio técnico una consecuencia de política material: los nombres ya existentes en el sistema alternativo podrían obligar a retener las cadenas equivalentes en el DNS antes de que lleguen a activarse allí.

Una consulta sobre el umbral, no sobre un servicio ya aprobado

El 11 de agosto, ICANN anunció la apertura de comentarios al primer informe de su grupo técnico sobre integraciones de gTLD con sistemas de nombres alternativos. La consulta comenzó el día 10 y terminará el 21 de septiembre a las 23:59 UTC. La iniciativa responde a preguntas recibidas desde 2022 de operadores de registro y posibles solicitantes de la próxima ronda que quieren utilizar la misma cadena en el DNS y en otros entornos de nombres.

El alcance es más estrecho de lo que sugiere una referencia genérica a blockchain. No incluye todas las identidades de cartera, alias de aplicaciones, raíces privadas o sistemas conectados a Internet. El TSG estudia un servicio de registro en el que un operador de gTLD mantiene bajo el mismo control institucional la cadena del DNS global y la cadena equivalente en uno o varios sistemas alternativos.

Tampoco existe una autorización general. El documento del 10 de agosto lleva la marca de borrador y se presenta como informe inicial. Su encargo consiste en contestar una pregunta previa de la Registry Services Evaluation Policy: ¿puede este tipo limitado de servicio funcionar sin un riesgo inaceptable para la seguridad y la estabilidad, y qué condiciones técnicas tendría que cumplir?

La respuesta es positiva con cautelas. El grupo considera que el modelo de mismo nombre y mismo controlador puede operar de forma segura si los controles son reales. Aclara a la vez que no recomienda este mecanismo frente a otros, que no rechaza otras opciones y que ni siquiera respalda por principio la integración. Esa precisión impide confundir una conclusión de viabilidad con consentimiento institucional.

El invariante no es la cadena de bloques, sino el control

El informe denomina su modelo «string+controller integration». La misma cadena debe estar siempre en manos de la misma parte en todos los sistemas; donde no se active, debe quedar reservada exclusivamente para esa parte. Si el diseño no puede mantener ambas condiciones, no es candidato para esta clase de integración.

La regla alcanza a los nombres subordinados. Una asignación, transferencia, suspensión o desactivación no puede separar el control entre dos titulares incompatibles. En los nombres internacionalizados, las variantes y las Label Generation Rules deben aplicarse antes, porque dos normalizaciones diferentes pueden convertir «el mismo nombre» en una afirmación falsa.

El grupo describe dos grandes arquitecturas. La más directa utiliza el Shared Registration System como controlador del alta. Los sistemas alternativos se conectan por detrás del registro tradicional y heredan la cadena entre registro, registrador y titular. Esta opción exige extensiones de EPP para modificar el nuevo estado y de RDAP para que los datos adicionales puedan consultarse.

La segunda arquitectura distribuye operación y datos sin renunciar a una fuente de verdad unificada en sentido lógico. Ningún componente puede aceptar una modificación que rompa la correspondencia entre cadena y controlador. Una cartera, un identificador persistente o una prueba criptográfica podría demostrar el control. En una red con liquidación lenta, una operación del registro DNS podría permanecer pendiente hasta que el otro sistema finalice su estado.

El solicitante debe demostrar algo más fuerte que la posibilidad de coordinación voluntaria: los participantes no deben poder romper la integración sin una orden o aprobación del titular. Así, una infraestructura distribuida no disuelve la rendición de cuentas. El operador del registro sigue siendo la persona jurídica responsable aunque proveedores distintos manejen partes del sistema.

La primera colisión de política ya aparece en el borrador

El mecanismo produce una consecuencia inmediata cuando el sistema alternativo ya contiene nombres. Para integrarlos, esas cadenas deben incorporarse al estado común y, como mínimo, quedar retenidas en el DNS, aunque nunca se activen en una zona DNS. De lo contrario, otra persona podría recibir la cadena equivalente y romper la promesa de un solo controlador.

El informe reconoce que esta consecuencia técnica puede tener efectos de política, pero los deja fuera de su alcance. Ahí se encuentra la frontera entre proteger la unicidad y decidir una asignación. Retener evita dos controles contradictorios, pero también elimina una cadena de la oferta disponible en el DNS. Una inscripción DNS puede producir el efecto inverso sobre el sistema alternativo.

La técnica no decide qué antigüedad merece prioridad, cómo se avisa a quien pierde disponibilidad, quién paga una retención defensiva, cómo se corrige una prueba defectuosa o qué recurso tiene una parte cuando ambos historiales chocan. Estas preguntas requieren un responsable de decisión y una base de autoridad distinta de la mera capacidad de sincronizar bases de datos.

Los Estatutos de ICANN ofrecen el límite. Su misión abarca la coordinación razonablemente necesaria para la apertura, interoperabilidad, resiliencia, seguridad o estabilidad del DNS. El propio informe recuerda que ICANN no dirige todos los sistemas de nombres de Internet y que no necesita intervenir más allá de la parte que afecte al sistema global.

La idea de coordinación mínima de Lu Heng ayuda a aplicar esa frontera. La unicidad, la prueba de control, la exactitud auditable y la continuidad pueden pertenecer a una capa común. El derecho comercial, la prioridad entre reclamantes previos y los usos permitidos de un nombre no se convierten en competencias técnicas por estar unidos al DNS. La necesidad de evitar un controlador doble puede justificar una negativa estrecha. Una regla más extensa necesita escuchar a los principales afectados, publicar motivos y ofrecer revisión.

La aprobación seguirá siendo individual y contractual

ICANN no está creando una licencia para todos los registros. Cada operador que quiera ofrecer el servicio deberá pasar por RSEP o por el proceso aplicable de la ronda 2026. RSEP examina riesgos de seguridad, estabilidad y competencia. El estudio común pretende evitar que cada solicitante pague por repetir la misma pregunta técnica básica, no eliminar el análisis de su arquitectura concreta.

Tampoco está listo el contrato. ICANN org sigue el trabajo del TSG para redactar enmiendas a los acuerdos de registro. La página de la consulta anticipa que el proyecto final y el texto contractual propuesto aparecerán juntos en otro periodo de comentarios. La carta del grupo contempla una segunda consulta y un informe final en enero de 2027. Hasta entonces faltan los estándares de prueba, controles, plazos de subsanación, medidas de cumplimiento y vías de recurso.

La salida es tan importante como el ingreso. El informe recomienda que toda solicitud incluya un plan obligatorio para apagar la integración. Además, señala que este servicio parece quedar fuera de las funciones críticas que mantiene un Emergency Back-End Registry Operator. Si un registro entra en EBERO, el DNS puede continuar mientras el sistema alternativo integrado deja de funcionar.

Un producto presentado como el mismo nombre en varios sistemas puede, por tanto, dividirse justo durante una crisis institucional. El operador debe explicar qué estado sobrevive, cómo se neutralizan registros obsoletos, qué conserva el titular y cómo se informa a los usuarios. La identidad no es una afirmación del día del lanzamiento; es una obligación de ciclo completo.

Lo que todavía deben separar las consultas

La consulta actual puede comprobar las condiciones técnicas: pruebas del controlador, sincronización, liquidación distribuida, nombres internacionalizados, visibilidad RDAP, transferencias, suspensión, EBERO y cierre. Las observaciones más útiles describirán un fallo verificable, no solo una preferencia ideológica por el DNS o por blockchain.

La siguiente etapa debe separar cuatro actos. El TSG determina que un diseño puede ser seguro. ICANN aprueba o rechaza un servicio concreto. El contrato atribuye facultades de supervisión y cumplimiento. Una regla de política decide qué ocurre con los nombres o titulares desplazados. Los cuatro actos tienen autores, fundamentos y recursos diferentes.

El informe inicial aporta valor porque sustituye la metáfora de un «puente» por un invariante operativo, una entidad legal responsable y un problema de cierre. Su legitimidad depende de no exceder ese logro. La viabilidad técnica abre la puerta de una evaluación; no decide quién tiene derecho a controlar la entrada.

Fuentes