Resumen

  • El crecimiento de los nuevos gTLD, las carteras de cientos de dominios y las actualizaciones frecuentes de DNSSEC cambiaron la carga que debía asumir el RZMS.
  • La reconstrucción añadió umbrales de aprobación por tipo de solicitud, concurrencia, una API y controles técnicos independientes; cada gestor de TLD conservó la responsabilidad de mantener reglas y cuentas operativas.

Análisis

Más solicitudes cambiaron la forma del trabajo

El RZMS anterior no había fracasado. Ya automatizaba fases del proceso, mejoraba la precisión y reducía los tiempos, además de ofrecer a los gestores de TLD un portal de autoservicio para tareas comunes. La presión vino de una carga distinta: el programa de nuevos gTLD aumentó las delegaciones, algunas organizaciones gestionaban carteras de cientos de dominios y las actualizaciones de claves DNSSEC se hicieron más frecuentes.

En mayo de 2022, Davies dijo que el equipo de Ingeniería y Tecnología de la Información de ICANN decidió reconstruir la plataforma con una arquitectura modular. Un pequeño equipo interdisciplinario llevó adelante el proyecto durante varios años. Su relato explica las decisiones y el contexto operativo; no afirma que él desarrollara el sistema por sí solo. El reto era absorber nuevos patrones de solicitudes sin atar cada mejora a un flujo fijo.

La escala cambió antes que la interfaz

La versión previa ya había automatizado fases del proceso, mejorado la precisión y reducido tiempos. También permitió a los gestores realizar tareas comunes desde un portal. Con el crecimiento de los nuevos gTLD, algunos operadores pasaron a administrar cientos de dominios; además aumentaron solicitudes como las actualizaciones frecuentes de claves DNSSEC. Esos usos presionaron los límites de una arquitectura diseñada años antes.

Davies atribuyó la reconstrucción a la decisión del equipo de Ingeniería y TI de ICANN y al trabajo de un grupo transversal. Su papel público fue explicar las prioridades y la transición, no reclamar la autoría individual del software. El historial oficial de versiones de IANA registra que la versión de diciembre de 2022 permitió tener más de dos aprobadores y configurar umbrales distintos por tipo de solicitud. También incorporó una API y solicitudes concurrentes. La separación de las comprobaciones técnicas en otro sistema buscaba que esas pruebas pudieran evolucionar sin quedar ligadas a la gestión de solicitudes.

La división de funciones no entrega toda la decisión a la interfaz. La IANA explica que su trabajo en la zona raíz comprende asignar gestores de TLD, registrar los datos técnicos de delegación y publicar un registro relacionado. La descripción institucional de la zona raíz distingue la base de datos que documenta gestores, contactos y datos técnicos del archivo DNS que contiene la zona raíz. Una aprobación interna permite que una solicitud avance; no convierte a quien pulsa el botón en propietario del dominio ni reemplaza las demás etapas del proceso.

El segundo factor tuvo que esperar

La autenticación multifactor no formó parte del lanzamiento inicial. En 2022, Davies señaló que la solución debía funcionar en cualquier país y para clientes que quizá pasaran años sin entrar en el sistema. Ese requisito afecta a la recuperación: un control puede dificultar el acceso indebido y, al mismo tiempo, dejar fuera a la persona que necesita tramitar una operación legítima.

El estudio del proceso de actualización de la zona raíz de 2022, dirigido por un consorcio externo, no describe un consenso absoluto sobre el problema. El 82 % de quienes respondieron consideró suficientes las medidas de seguridad existentes; un 18 % mencionó posibles debilidades y algunos propusieron MFA. Son percepciones de los encuestados de aquel estudio, no una medición de todo el sector ni de la política vigente. El estudio también analizó el principio entonces aplicado de que las solicitudes podían venir de personas fuera de una lista fija de contactos autorizados.

La protección adicional llegó en etapas. En enero de 2025, Davies presentó MFA y la verificación de identidad como opciones voluntarias. La guía vigente de IANA, revisada en julio de 2026, establece la verificación como requisito para habilitar MFA y usar la API, pero no para los demás usos del RZMS. La API está limitada a las acciones permitidas por cada cuenta; sus integraciones pueden probarse primero en un entorno OTE que nunca modifica producción, según la guía de API.

La recuperación tiene un costo de información. Un proveedor externo conserva las imágenes de identificación y del rostro durante un máximo de siete días. IANA mantiene el nombre legal, la fecha de nacimiento y el resultado de la validación mientras la cuenta sigue activa. La combinación sirve para volver a acreditar a alguien que perdió su acceso, pero obliga a las organizaciones a entender qué datos acompañan a esa capacidad.

La escala traslada responsabilidades al gestor

Los umbrales configurables y las solicitudes simultáneas hacen que el servicio se adapte mejor, pero el software no puede elegir una política de aprobación adecuada para cada organización. El gestor de TLD debe mantener actualizada su lista de representantes, definir cuántas personas aprueban cada tipo de solicitud y prever la recuperación de cuentas que quizá se usan con poca frecuencia. Muy pocos aprobadores crean un cuello de botella; exigir demasiadas aprobaciones puede retrasar el mantenimiento ordinario.

La API extiende el control a procesos programáticos, aunque sigue respetando los permisos de cada usuario. El entorno Operational Test and Evaluation de IANA permite probar integraciones antes de usarlas en producción. Las comprobaciones técnicas también son independientes de la autorización: una configuración técnicamente conforme no aprueba una solicitud, y una aprobación no sustituye la revisión ni la implementación.

El RZMS es solo una parte de la gestión de la zona raíz. IANA asigna gestores de TLD, registra datos técnicos de delegación y publica Root Zone Database, que es distinta del archivo DNS de la zona raíz. El registro de cambios de junio de 2026 muestra la versión 3.6.1. La contribución duradera de la reconstrucción es ofrecer un flujo adaptable, no garantizar que cada organización lo configure bien. Su desempeño depende de que las reglas locales, la recuperación de cuentas y las pruebas técnicas evolucionen al ritmo de la carga.

Fuentes