Resumen

  • El grupo técnico de ICANN estudia un modelo acotado: la misma cadena en un gTLD y en uno o más sistemas alternativos, controlada por la misma parte y coordinada por el operador del registro.
  • El informe recomienda un plan obligatorio de apagado y señala que la integración parece quedar fuera de las cinco funciones críticas que conserva un operador de emergencia EBERO.
  • El primer comentario público cierra el 21 de septiembre de 2026. El documento no es una política final, un servicio aprobado ni evidencia de un fallo real.

La continuidad de un registro y la continuidad de todo lo que se conecte a él no son la misma promesa.

Ese límite aparece con claridad en el informe publicado por el Technical Study Group de ICANN. El grupo no intenta gobernar todos los sistemas de nombres alternativos. Examina una arquitectura concreta: una cadena idéntica en el DNS global y en otro sistema, bajo el control de una misma parte. El operador del registro de gTLD coordina la relación, aunque pueda delegar componentes técnicos.

El informe considera que ese diseño podría funcionar sin suscitar problemas significativos de seguridad o estabilidad si mantiene controles operativos adecuados. No afirma que carezca de riesgos. Tampoco respalda la integración en general ni descarta mecanismos distintos.

Apagar una interfaz no resuelve un estado

El modelo usa un vocabulario amplio porque un nombre atraviesa decisiones diferentes. Puede estar disponible, incorporado al conjunto, asignado, retenido, activo, desactivado, suspendido o inhabilitado. Cada estado responde a una pregunta propia: quién puede recibir el nombre, quién lo controla, en qué sistema funciona y qué acciones siguen permitidas.

Por eso, cerrar un portal o dejar de responder consultas no demuestra una salida completa. El nombre alternativo podría seguir asignado al antiguo titular. Podría quedar libre mientras el nombre DNS aún pertenece a otra persona. Una caché, un registro distribuido o un proveedor contratado podría conservar un estado distinto al de la fuente principal.

La condición de “misma cadena” no corrige esa divergencia. Dos etiquetas visualmente iguales pueden representar autoridades opuestas. El valor del modelo depende de conservar también el “mismo controlador” durante transferencias, expiraciones, suspensiones y cese del servicio.

El borrador activo del grupo DNSOP de IETF trata el ciclo de vida, la validación de control y la sincronización como problemas separados. Advierte que una integración desactualizada puede dejar el control en manos de alguien que ya no es el titular del dominio. Es un Internet-Draft en curso, no una obligación de ICANN, pero muestra por qué la validación inicial no basta.

La cobertura de EBERO tiene cinco bordes

Cuando un operador de gTLD corre el riesgo de dejar de mantener funciones críticas, ICANN puede activar un Emergency Back-end Registry Operator. Su mandato cubre la resolución DNS, el Shared Registration System, el servicio de datos de registro, los depósitos de custodia y una zona firmada correctamente con DNSSEC.

La integración con el sistema alternativo no figura en esa enumeración. El informe entiende que probablemente no sobreviviría a una operación EBERO. La observación no demuestra un defecto del mecanismo de emergencia; demuestra que su perímetro fue diseñado para otras funciones.

La consecuencia de gobernanza es sencilla. Un operador no debería dejar que la frase “protegido por la continuidad del registro” se convierta en garantía de que cualquier identidad paralela seguirá funcionando. Y si la integración está destinada a detenerse durante la emergencia, el modo de detenerla forma parte del diseño del servicio, no de la improvisación posterior.

De ahí la recomendación: la definición del servicio debería enumerar sus capacidades y un plan para desactivarlas si el modelo deja de ser viable. Mientras falte experiencia sustancial, el plan de apagado tendría que ser obligatorio al evaluar la solicitud.

Un plan puede fallar en silencio

El texto correcto puede depender de una cuenta, una firma o un proveedor que no esté disponible durante el incidente. Puede contemplar el cese de nuevas altas sin decidir qué ocurre con los nombres existentes. Puede asignar la última acción a un titular que ya no tiene incentivo para ejecutarla. También puede ignorar una recuperación parcial en la que el DNS vuelve antes que el sistema alternativo.

Nada de esto prueba que el modelo vaya a fallar. Explica por qué la existencia del plan no es la misma evidencia que el resultado de una prueba.

El Registry Services Evaluation Policy ofrece el cauce institucional. Mediante RSEP, un operador propone añadir, modificar o retirar un servicio y ICANN valora posibles efectos significativos sobre seguridad, estabilidad y competencia. El informe sostiene además que no se deben rebajar sus requisitos técnicos mínimos para volver rentable la propuesta; un diseño debilitado sería otro servicio y necesitaría evaluación propia.

La regla debe extenderse al apagado. Si un ensayo deja estados sin reconciliar, el registro debe conservar la excepción y corregir el diseño. Cambiar el criterio de finalización después del ensayo solo convierte una brecha operativa en una definición conveniente.

El proceso sigue abierto. La consulta iniciada el 10 de agosto termina el 21 de septiembre. La carta del grupo prevé revisar aportaciones, publicar otro borrador y abrir una segunda consulta en octubre, para después trabajar hacia un informe final en enero de 2027. Ninguna de esas etapas futuras equivale a una decisión ya tomada.

Las fuentes consultadas no prueban que exista un servicio aprobado, que un registro concreto haya fallado, que EBERO haya recibido esta integración o que dos controladores reales se hayan separado. La cuestión es anterior a esos hechos: qué evidencia mínima debería poder producir el sistema si algún día tiene que salir.

Fuentes