Introduciendo la Próxima Generación de Gestión de la Zona Raíz

Hace un poco más de 10 años, la Corporación de Internet para la Asignación de Nombres y Números (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 introdujo incluyeron la automatización de muchas fases del procesamiento, lo que mejoró la precisión y redujo los tiempos de procesamiento. Otra mejora fue el lanzamiento de un portal de autoservicio que permite a los administradores de dominios de nivel superior (TLD) realizar tareas comunes por sí mismos.

Los orígenes de RZMS se remontan a principios de la década de 2000. Si bien ha cumplido bien su objetivo, con el tiempo nuestras necesidades han crecido y algunos de los diseños incorporados en el sistema original han limitado nuestra capacidad para evolucionar la plataforma en el futuro. La llegada del Programa de Nuevos Dominios de Alto Nivel Genéricos (gTLD) aumentó significativamente el número de TLD en la zona raíz, lo que también cambió la forma en que algunos de nuestros clientes trabajan. Algunas organizaciones ahora participan en la gestión de cientos de TLD y necesitan nuevas herramientas para ayudarles a optimizar la gestión de sus carteras. También vemos nuevos tipos de solicitudes que no existían antes, como actualizaciones frecuentes de las claves de firma para TLD.

El equipo de Ingeniería y Tecnología de la organización de ICANN, que desarrolla el RZMS, tomó la decisión de reconstruir toda la plataforma desde cero, para crear un sistema modular moderno que fuera más adaptable a las necesidades futuras. Un pequeño equipo de proyecto interfuncional ha pasado los últimos años construyendo este sistema, y ahora estamos cerca de su realización y lanzamiento.

Además de replicar toda la funcionalidad existente en una arquitectura moderna, hemos realizado algunos cambios clave en el sistema en esta versión inicial que proporcionarán mejoras significativas a nuestros clientes. Los más notables son:

• Un nuevo modelo de contacto que identifica a las personas autorizadas a interactuar con la Autoridad de Números Asignados de Internet (IANA) por separado de los contactos administrativos y técnicos que se publican para la comunidad en general. Al distinguir estas funciones, proporcionamos una flexibilidad significativa a los administradores de TLD para configurar sus roles y responsabilidades de acuerdo con las necesidades de su organización. Los administradores de TLD también pueden personalizar la cantidad de aprobaciones necesarias para cada tipo de solicitud de cambio y qué representantes están autorizados para aprobar diferentes tipos de solicitudes.
• El nuevo modelo también proporciona resultados importantes en términos de seguridad al emitir cuentas individuales a las personas. Requeriremos que los usuarios de nuestro sistema inicien sesión con sus credenciales para aprobar solicitudes, en lugar de nuestra práctica anterior de permitir a veces aprobaciones simplemente haciendo clic en un enlace en un correo electrónico.
• Las pruebas de conformidad de la infraestructura de TLD, el proceso de "verificación técnica", se han separado en su propio sistema independiente. La separación de las verificaciones técnicas del RZMS nos permitirá evolucionar las verificaciones técnicas (como agregar nuevas pruebas para identificar configuraciones problemáticas adicionales de TLD), así como introducir optimizaciones de rendimiento para que las pruebas se ejecuten más rápido.
• Una interfaz de programación de aplicaciones preliminar, que permitirá a los administradores de TLD construir o utilizar herramientas para comunicarse programáticamente con nuestro sistema. Las características 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 hemos tomado para el nuevo modelo de contacto es limitar las cuentas a individuos. Esto significa que cada persona que utiliza el sistema tendrá su propio nombre de usuario y contraseña únicos, en lugar de una contraseña compartida utilizada por varias personas. Cada administrador de TLD podrá crear tantas cuentas como sea necesario para sus representantes, y los registros públicos (como los que aparecen en los registros WHOIS) pueden seguir siendo basados en roles en lugar de estar vinculados a un individuo en particular.

Funcionalidad futura

Si bien creemos que estas características abordan las mejoras más urgentes que nuestros clientes están solicitando, sabemos que hay más trabajo por hacer. Hemos tenido que tomar algunas decisiones sobre en qué nuevas funciones centrarnos para completar y lanzar esta iteración de la plataforma, y cuáles posponer para más adelante en nuestra hoja de ruta de desarrollo.

Una pieza de funcionalidad pospuesta de particular interés es la autenticación multifactor. Reconocemos que algunos de nuestros clientes desean esta característica, pero debemos asegurarnos de implementarla de manera cuidadosa y considerada que fortalezca la seguridad de la zona raíz. La autenticación multifactor tiene muchas consideraciones importantes, como asegurarse de que funcione para las personas en cualquier país del mundo y funcione para clientes de los que es posible que no tengamos noticias durante muchos años.

Parte de nuestra consideración al posponer este trabajo y considerarlo más detenidamente es el Estudio del Proceso de Actualización de la Zona Raíz en Borrador. En este estudio, el revisor de terceros no recomienda agregar autenticación multifactor tradicional a la zona raíz y señala que algunas de las protecciones únicas que tenemos en nuestro proceso ya proporcionan protecciones que la autenticación multifactor pretende agregar. Creemos que puede haber un papel para más opciones de autenticación multifactor en el futuro y esperamos que los diálogos futuros enfoquen adecuadamente nuestro trabajo en esta área.

Este estudio identificó varias otras áreas para posibles mejoras en el proceso de actualización de la zona raíz, y estudiaremos más detenidamente el informe final para informar nuestro trabajo futuro. Por ejemplo, una área común de retroalimentación que recibieron los revisores fue mejorar la forma en que se realizan las verificaciones técnicas para que los problemas detectados que son menores no retrasen indebidamente el procesamiento. Hemos estado explorando formas de calificar los problemas por gravedad y permitir a los administradores de TLD desestimar posibles problemas por sí mismos cuando es probable que el problema tenga un impacto menor, lo que debería mejorar esto en gran medida.

Próximos pasos

En preparación para este nuevo sistema, IANA llevará a cabo un contacto directo con muchos de nuestros clientes para hablar con ellos sobre el impacto del sistema. Una de las preparaciones más importantes es identificar cómo migrar del antiguo modelo de contactos al nuevo de manera que no cause inconvenientes a nadie.

En los casos en los que algunos TLD tengan muchas cuentas diferentes, buscaremos formas de consolidarlas bajo un solo nombre de usuario y contraseña para cada individuo. Esto incluye casos en los que podemos tener varias direcciones de correo electrónico registradas para la misma persona, y tendremos que determinar cuáles direcciones consolidar.

Otra de las mejoras en el nuevo modelo de contactos incluirá ordenar el formato de los campos de dirección postal en nuestra base de datos. Esperamos ponernos en contacto con los TLD para aclarar sus direcciones.

Más allá de esta discusión sobre la implementación de la nueva versión con nuestros clientes, esperamos recibir sus comentarios sobre cómo funciona el sistema y tener en cuenta esos comentarios en futuras versiones de forma regular.