El cambio de la clave raíz DNSSEC ya se realizó: qué deben revisar los operadores

El hito de octubre de 2026 no fue un relevo del operador de la zona raíz del DNS. Fue un rollover de la clave para la firma de la llave (KSK) que sustenta DNSSEC: desde el 11 de octubre, la nueva KSK-2024, identificada por la etiqueta 38696, firma el conjunto DNSKEY de la raíz. La sustitución estaba planificada por ICANN y la IANA como parte de una transición gradual iniciada en 2024.

La diferencia importa. La zona raíz sigue siendo el punto superior de referencia de la jerarquía DNS y su operación no pasó a una nueva entidad por este cambio. Lo que se actualizó fue la clave criptográfica que los resolutores validadores usan como ancla de confianza para verificar la zona raíz y, a través de ella, la cadena DNSSEC. Presentar el evento como un cambio de operador confunde gobernanza e infraestructura con una renovación de claves.

El calendario de ICANN situó la nueva firma el 11 de octubre de 2026 y la retirada de la clave anterior para una etapa posterior, prevista para enero de 2027. Por tanto, al 9 de noviembre de 2026, el evento principal ya ocurrió, pero el ciclo de mantenimiento de la clave no está completo. La consecuencia práctica se concentra en los sistemas que realizan validación DNSSEC con una configuración propia o antigua.

El DNS organiza los nombres de dominio en una jerarquía. En su parte superior está la zona raíz, que publica referencias a los dominios de nivel superior —por ejemplo, .com, .org o extensiones nacionales— y a los servidores responsables de ellos. Un servidor raíz no conserva la dirección IP de cada sitio web: orienta al resolutor hacia el siguiente nivel de la búsqueda.

Cuando un resolutor recursivo no encuentra una respuesta en su caché, puede consultar una de las identidades raíz. La respuesta lo dirige al servidor del TLD correspondiente; después, el resolutor continúa hacia los servidores autorizados del dominio. Si la información ya está almacenada en caché, la consulta puede resolverse sin llegar a la raíz, de modo que esta no interviene en cada visita a una página.

También conviene distinguir las 13 identidades raíz nombradas —de la A a la M— de las máquinas físicas. El sistema se distribuye mediante numerosas instancias y operadores independientes; ICANN describe 13 identidades gestionadas por 12 operadores y más de 1.500 servidores individuales. La redundancia y el enrutamiento anycast permiten atender consultas desde múltiples ubicaciones, pero no convierten cada instancia en un operador distinto ni eliminan la coordinación de la zona raíz.

DNSSEC añade firmas criptográficas para que un resolutor validador pueda comprobar la autenticidad e integridad de los datos DNS. La KSK raíz valida el conjunto de claves DNSKEY de la zona raíz; otras claves de esa zona se emplean en la cadena que permite verificar referencias a dominios de nivel superior. La nueva clave no cambia la estructura de dominios ni los registros de los sitios: renueva el punto de partida criptográfico de esa verificación.

KSK-2024 se publicó en la zona raíz el 11 de enero de 2025, con antelación suficiente para que los resolutores compatibles con la actualización automática de anclas de confianza pudieran aprenderla. El 11 de octubre de 2026 comenzó a firmar la zona raíz. La clave anterior, KSK-2017, no debe confundirse con la nueva: la operación de firma y la eliminación definitiva de una clave son etapas distintas del proceso.

Este reemplazo tampoco es una migración a un algoritmo criptográfico diferente. ICANN y Cloudflare describen KSK-2017 y KSK-2024 como claves que usan RSA/SHA-256. Por eso, el rollover actual prueba y renueva la distribución de la confianza sin implicar que la raíz haya pasado a criptografía poscuántica. Un cambio de algoritmo requeriría compatibilidad adicional en los resolutores y sería un proceso separado.

Para la mayoría de las personas, no hay una acción que realizar en el teléfono, el ordenador o el router. Quienes usan resolutores administrados por su proveedor de Internet o por un servicio DNS público dependen de que ese operador mantenga el software y sus anclas de confianza al día. No es necesario cambiar de servidor DNS simplemente porque se haya renovado la KSK.

El trabajo corresponde sobre todo a administradores de resolutores recursivos que validan DNSSEC, en especial cuando mantienen anclas manuales, ejecutan software antiguo o gestionan equipos que han estado desconectados durante largos periodos. Si el resolutor no confía en KSK-2024, puede rechazar la validación de respuestas correctamente firmadas. Para las personas que dependen de ese resolutor, el síntoma podría ser que algunos nombres no resuelvan aunque los sitios y sus servidores estén funcionando.

Una respuesta SERVFAIL, por sí sola, no demuestra que falte la nueva clave: puede deberse a otras causas de configuración o validación. La comprobación pertinente es el estado de confianza que utiliza realmente el resolutor, no solo que la clave aparezca en una respuesta DNS. ICANN identifica la etiqueta 38696 para KSK-2024; los administradores deben contrastarla con el procedimiento y los archivos de anclas de su software, y no retirar manualmente la clave antigua sin seguir el calendario oficial.

La renovación de la KSK se refiere a la validación criptográfica de DNSSEC. La latencia de una consulta depende, entre otros factores, de la ubicación del resolutor, las rutas de Internet y si la respuesta está en caché; el rollover, por sí solo, no permite concluir que haya una mejora general de latencia.

En seguridad, la función de DNSSEC es ayudar a detectar respuestas DNS no auténticas o modificadas, no cifrar por sí mismo las consultas ni ocultar el nombre solicitado. Cambiar la clave conserva la capacidad de validar la zona raíz con una clave renovada, pero no reemplaza otras medidas de seguridad, como el mantenimiento del resolutor, la protección de sus sistemas o el cifrado del transporte DNS cuando corresponda.

El proceso también pone a prueba la coordinación entre la publicación de una nueva clave, su adopción en resolutores y el retiro de la anterior. El primer rollover de la KSK raíz tuvo lugar en 2018; la transición actual es la segunda. La continuidad depende de que los sistemas validadores tengan una ancla válida, mientras que la arquitectura distribuida y las cachés aportan resiliencia a otras partes de la resolución. Son mecanismos complementarios, no intercambiables.

Si administra un resolutor con validación DNSSEC, la decisión útil es verificar que su configuración confíe en KSK-2024 (etiqueta 38696) y que el mecanismo de actualización de anclas funcione. Revise la documentación de la versión instalada y el estado persistente del servicio: la presencia de la clave en la zona pública no garantiza que el software la tenga incorporada como ancla de confianza.

Para equipos con resolutores de terceros, la acción razonable es consultar el estado o los avisos del proveedor si aparecen errores persistentes de resolución. No cambie los registros de un dominio ni desactive DNSSEC como primera respuesta a un SERVFAIL sin identificar antes dónde falla la validación. El problema puede estar en el resolutor, en una zona concreta o en otra parte de la cadena.

El siguiente hito del calendario descrito por ICANN es la retirada de KSK-2017, prevista para enero de 2027. Hasta entonces, administradores y proveedores deben seguir las instrucciones oficiales y mantener las actualizaciones de seguridad habituales. Para los usuarios finales, el mensaje es más sencillo: no hay que reconfigurar la conexión por este rollover; el cambio debe gestionarse en la infraestructura que valida las consultas.