Hace un poco más de 10 años, la Corporación para la Asignación de Nombres y Números en Internet (ICANN) ayudó a lanzar el Sistema de Gestión de la Zona Raíz (RZMS), un conjunto de componentes interrelacionados que modernizó la gestión de la zona raíz del Sistema de Nombres de Dominio (DNS). Algunas de las mejoras que incorporó incluían la automatización de muchas etapas del procesamiento, lo que mejoró la exactitud del procesamiento y redujo los tiempos de procesamiento. Otra mejora fue el lanzamiento de un portal de autoservicio que permite a los administradores de dominios de alto nivel (TLD) realizar tareas comunes por sí mismos.
Los orígenes del RZMS se remontan a principios de la década de 2000. Si bien ha cumplido bien su objetivo, con el tiempo, nuestras necesidades crecieron y algunos de los diseños incorporados al sistema original han limitado nuestra capacidad de hacer evolucionar la plataforma hacia el futuro. La llegada del Programa de Nuevos Dominios Genéricos de Alto Nivel (gTLD) aumentó de manera significativa la cantidad de TLD en la zona raíz, lo que también cambió la forma en que algunos de nuestros clientes trabajan. Algunas organizaciones ahora se dedican a la administración de cientos de TLD y necesitan herramientas nuevas para que los ayuden a agilizar la gestión de sus carteras. También observamos nuevas clases de solicitudes que no existían en el pasado, como actualizaciones frecuentes a las claves de firmas para los TLD.
El equipo de Ingeniería y Tecnologías de la Información de la ICANN, que desarrolla el RZMS, decidió volver a crear toda la plataforma desde cero, a fin de diseñar un sistema modular moderno que se adapte mejor a las necesidades futuras. Un pequeño equipo de proyecto multidisciplinario ha dedicado los últimos años a crear este sistema y ahora estamos acercándonos a su finalización y lanzamiento.
Además de replicar todas las funciones existentes en una arquitectura moderna, en este lanzamiento inicial, hemos realizado algunos cambios clave al sistema que ofrecerán mejoras significativas a nuestros clientes. Los cambios más importantes son:
- Un nuevo modelo de contacto que identifica a las personas que están autorizadas a interactuar con la Autoridad de Números Asignados en Internet (IANA) de manera independientemente de los contactos técnicos y administrativos que se publican para la comunidad en general. Al distinguir estas funciones, brindamos gran flexibilidad para que los administradores de TLD configuren sus roles y responsabilidades de manera que se adapten específicamente a sus necesidades organizativas. Los administradores de TLD también pueden personalizar la cantidad de aprobaciones necesarias para cada tipo de solicitud de cambio y cuyos representantes están autorizados a aprobar diferentes tipos de solicitudes.
- Asimismo, el nuevo modelo brinda importantes resultados en materia de seguridad al conceder a las personas sus propias cuentas. Exigiremos que los usuarios de nuestro sistema inicien sesión con sus credenciales para aprobar solicitudes, en vez de nuestra práctica anterior de a veces aceptar aprobaciones con solo hacer clic en un enlace de un correo electrónico.
- Las pruebas de conformidad de la estructura de los TLD, el proceso de “control técnico”, se han separado en su propio sistema independiente. La diferenciación de los controles técnicos del RZMS nos permitirá mejorar los controles técnicos (como agregar nuevas pruebas para identificar configuraciones de TLD problemáticas adicionales), así como incorporar optimizaciones de desempeño para que las pruebas se puedan realizar con más rapidez.
- Una Interfaz de Programación de Aplicaciones preliminar, que permitirá a los administradores de TLD crear o usar herramientas para comunicarse de manera programática con nuestro sistema. Las funciones iniciales se centran en actualizaciones masivas, para que las organizaciones que gestionan muchos TLD puedan realizar operaciones en varios TLD de manera eficiente.
Una de las decisiones que tomamos para el nuevo modelo de contacto es limitar la cuenta a las personas. Esto significa que cada persona que use el sistema tendrá su propio nombre de usuario y su propia contraseña, en vez de una contraseña compartida entre varias personas. Cada administrador de TLD podrá crear tantas cuentas como sean necesarias para sus representantes y los registros públicos (como los que se muestran en los registros del WHOIS) pueden continuar basándose en roles en vez de estar vinculados a cualquier persona.
Funciones futuras
Si bien consideramos que estas funciones abordan las mejoras más apremiantes que nuestros clientes solicitan, sabemos que hay más por hacer. Hemos tenido que tomar algunas decisiones sobre en qué funciones nuevas centrarnos para finalizar y lanzar esta versión de la plataforma, y cuáles aplazar para más adelante en nuestra hoja de ruta de desarrollo.
Una parte de las funciones aplazadas de especial interés es la autenticación multifactor. Reconocemos que algunos de nuestros clientes cada vez más desean esta función, pero debemos asegurarnos de implementarla con cautela y consideración de manera que fortalezca la seguridad de la zona raíz. La autenticación multifactor tiene muchas consideraciones importantes, entre ellas, asegurarse de que funcione para las personas de cualquier país del mundo y que funcione para los clientes sobre los que quizá no tengamos noticias desde hace muchos años.
Parte de nuestra consideración en aplazar este trabajo y considerarlo de manera más minuciosa es el Estudio preliminar del proceso de actualización de la zona raíz. En este estudio, el revisor externo no recomienda agregar la autenticación multifactor tradicional a la zona raíz y señala que algunas de las protecciones exclusivas que tenemos en nuestro proceso ya ofrecen protecciones que la autenticación multifactor pretende agregar. Consideramos que puede haber un rol para más opciones de autenticación multifactor en el futuro y esperamos tener futuros diálogos para centrar nuestro trabajo adecuadamente en esta área.
Este estudio identificó varias otras áreas para posibles mejoras al proceso de actualización de la zona raíz y analizaremos el informe final de manera más exhaustiva para informar nuestro trabajo futuro. Por ejemplo, un área común de comentarios que recibieron los revisores fue mejorar la forma en que se realizan los controles técnicos para que los problemas detectados que sean menores no retrasen indebidamente el procesamiento. Hemos estado explorando modos de clasificar los problemas en función de su gravedad y de permitir que los administradores de TLD descarten posibles problemas por sí mismos cuando es probable que tengan un impacto menor, lo que debería mejorar esto en gran medida.
Próximos pasos
A fin de prepararse para este sistema nuevo, la IANA realizará actividades de difusión directa con muchos de nuestros clientes para comentarles sobre el impacto del sistema. Una de los preparativos más grandes es identificar la forma de migrar del modelo de contacto anterior al nuevo de forma tal que no cause inconvenientes a nadie.
En los casos en los que algunos TLD tengan muchas cuentas distintas, buscaremos maneras de ayudar a consolidarlas en un único nombre de usuario y una única contraseña para cada persona. Esto incluye los casos en los que quizá tengamos varias direcciones de correo electrónico registradas para la misma persona, donde habrá que determinar qué direcciones consolidar.
Otra de las mejoras al nuevo modelo de contacto incluirá organizar el formato de los campos de dirección de correo postal en nuestra base de datos. Tenemos previsto comunicarnos con los TLD para aclarar sus direcciones.
Además de este debate sobre cómo desplegar la nueva versión con nuestros clientes, esperamos recopilar sus comentarios sobre el funcionamiento de nuestro sistema e incorporar esos comentarios en futuras versiones en forma periódica.
