La clave raíz de internet cambia hoy: qué es el rollover KSK-2024 y qué revisar en tu DNS
Hoy, 11 de octubre de 2026, la zona raíz de DNS cambia la clave que la firma: entra KSK-2024 y sale KSK-2017. Para la mayoría no pasa nada; para un resolver sin la clave nueva, todo deja de resolverse. Este es el rollover KSK-2024 y el test de cinco minutos.
El rollover KSK-2024: qué cambia hoy en la raíz de DNS
La zona raíz es la lista de arriba del todo del DNS: la que indica dónde están los servidores de cada dominio de primer nivel. Desde hoy, el conjunto de claves de esa zona lo firma KSK-2024 (key tag 38696) en lugar de KSK-2017 (key tag 20326), que llevaba ocho años en ese papel. Las dos son claves RSA/SHA-256, así que no cambia el algoritmo: cambia el material de la clave.
Es el segundo rollover de la raíz en la historia de internet. El primero fue el de octubre de 2018, cuando KSK-2010 pasó el relevo a KSK-2017, y se retrasó un año porque demasiados resolvers no estaban preparados.
De KSK-2017 a KSK-2024: qué es una clave de firma de clave
Para poder comprobar que una respuesta de DNS viene de quien dice venir existe DNSSEC. Dentro de DNSSEC hay dos tipos de claves: la ZSK firma los registros del día a día de una zona y la KSK firma el conjunto de claves de la zona. Esa KSK es el ancla de confianza de todo el sistema: la cadena de validación empieza ahí y no hay nada por encima que la respalde. Por eso cambiarla es un asunto delicado y por eso se avisa con meses de antelación.
Lee también
Las dos fechas: 11 de octubre de 2026 y enero de 2027
Son dos momentos distintos, no uno. Hoy la clave nueva empieza a firmar y la vieja deja de firmar. La KSK-2017 sigue presente en el conjunto de claves de la raíz, pero ya sin firmar, hasta que se retira formalmente en enero de 2027. Después de esa segunda fecha, un resolver que solo confíe en la clave vieja se queda sin validación.
Por qué la clave nueva lleva meses publicada
KSK-2024 está publicada en la zona raíz desde febrero de 2025, unos veinte meses antes del cambio. Ese margen es intencionado: existe para que los resolvers tengan tiempo de aprenderla sin prisa. Quien aprovechó ese tiempo no tiene nada que hacer hoy; quien no, se entera hoy.
Por qué a la mayoría no le va a pasar nada
Dos formas de recibir la clave: RFC 5011 o el paquete de tu distribuidor
Un resolver validador puede enterarse de la clave nueva por dos caminos. El primero es automático y se llama RFC 5011: el propio resolver ve la clave nueva en la raíz y, tras un periodo de espera pensado para evitar engaños, empieza a confiar en ella sin que nadie toque nada. El segundo es más mundano: la actualización del paquete de tu distribución, de tu imagen de contenedor o del firmware de tu router ya trae el ancla de confianza nueva.
Si tu resolver usó cualquiera de las dos vías, hoy no notas nada. Y ese es el caso de la mayoría de conexiones del mundo, que además no usan un resolver propio: usan el del operador o uno público.
El caso especial de las imágenes de contenedor y los routers de empresa
Donde aparecen los problemas es donde el software se queda quieto. Una imagen de contenedor fijada por etiqueta en lugar de actualizarse con frecuencia, un servidor que no se ha tocado en años, el router gestionado de una oficina o un resolver casero pueden tener un ancla de confianza que nunca se refrescó. No es un perfil exótico: es el perfil de mucho software que funciona bien y por eso nadie lo mira.
Qué se rompe si tu resolver no confía en KSK-2024
SERVFAIL en todo: dominios firmados y no firmados
El fallo no es parcial. Un resolver validador que no tenga la clave nueva no puede validar la respuesta de la raíz, y sin esa validación no hay cadena de confianza posible: devuelve SERVFAIL tanto en dominios firmados como en los que no lo están. Es decir, no falla un sitio concreto: falla todo lo que pasa por ese resolver. Ese es el escenario que los operadores quieren evitar, y de ahí salen las "caídas misteriosas" cuando alguien descubre el problema por sus usuarios y no por su configuración.
DNSSEC no cifra: autentica
Conviene decirlo porque el titular fácil lo suele confundir: DNSSEC no cifra el tráfico ni protege la privacidad de tus consultas. Lo que hace es firmar y verificar respuestas, para que nadie pueda falsificar la dirección de un nombre. Si nadie valida, el efecto no es que tus datos queden expuestos: es que la suplantación de respuestas deja de detectarse.
El test de cinco minutos con sentinels del RFC 8509
Las dos consultas y cómo leer cada resultado
Existe un mecanismo estándar para preguntarle a un resolver si confía en una clave concreta: los sentinels de ancla de confianza del RFC 8509. Son nombres especiales bajo dnstest.dev. Hay que lanzar las consultas contra el resolver que realmente usan tus equipos, no contra el portátil desde el que escribes.
dig @192.0.2.53 root-key-sentinel-is-ta-38696.dnstest.dev A
dig @192.0.2.53 root-key-sentinel-not-ta-38696.dnstest.dev ALa lectura de cada respuesta es la parte que más se confunde:
- is-ta-38696 pregunta si el resolver confía en la clave con tag 38696. Debe responder con un registro A: si responde, el resolver está listo para el rollover.
- not-ta-38696 pregunta lo contrario, si no confía en esa clave. Debe dar SERVFAIL, precisamente porque sí confía. Una respuesta normal aquí significa que el resolver no está validando.
La trampa: cuando "todo responde" significa que no hay validación
Si las dos consultas responden con normalidad, no se puede concluir que tu resolver esté preparado. Significa una de dos cosas: que no hace validación DNSSEC, o que no soporta el mecanismo de sentinels. Los resolvers que no validan no se rompen por el rollover, pero tampoco comprueban que las respuestas que entregan sean auténticas. Un control útil es preguntar por un tag que no existe: debería dar SERVFAIL.
Consulta contra el resolver correcto: tu portátil no cuenta
El test solo vale si lo ejecutas contra el resolver que atiende a tus clientes o servidores reales. Comprobar el del portátil desde el que escribes es la forma más rápida de obtener un "todo bien" que no dice nada del sistema que de verdad te importa.
Cómo comprobar tu ancla de confianza, por software
La regla transversal es buscar el key tag 38696 —o su digest DS— en el ancla de confianza del resolver. Si no aparece, ese es el problema.
BIND: bind.keys y rndc managed-keys status
En BIND el material arranca en el fichero bind.keys y el estado del mecanismo se consulta desde la consola de control con rndc managed-keys status. Ahí se ve si la clave está aceptada o todavía en espera.
Unbound: el fichero root.key y el reinicio del servicio
En Unbound la clave vive en el fichero que apunta la opción auto-trust-anchor-file, normalmente root.key. Antes de tocarlo conviene respaldarlo, luego refrescar el ancla desde la fuente oficial y reiniciar el servicio. Cambiar el fichero sin reiniciar deja el cambio en el disco pero no en memoria.
Knot Resolver, PowerDNS Recursor y systemd-resolved
Knot Resolver guarda su ancla en root.keys y expone un resumen del estado por su socket de control; si el fichero es escribible, se actualiza sola. PowerDNS Recursor y los resolvers locales de los sistemas operativos tienen su propio mecanismo, y la ruta y el comando exactos dependen de la versión: confírmalos en la documentación de tu implementación antes de tocar nada.
Si falta el key tag 38696, esto es lo que haces
Actualizar el paquete o refrescar el ancla con el material de IANA
El primer paso es actualizar el paquete, la imagen o el firmware del resolver, que suele arreglarlo sin más. Si no puedes esperar, el ancla se refresca a mano con el material publicado por IANA y después se reinicia el servicio. Ese material se toma siempre de la fuente oficial, nunca de un blog ni de un fichero de claves copiado de otra instalación.
El apaño temporal: apuntar a un resolver público que ya está listo
Si tienes usuarios esperando y no puedes actualizar en el momento, la salida rápida es apuntar temporalmente a un resolver público grande, que se actualizó por su cuenta hace tiempo, y volver a tu resolver cuando puedas arreglarlo. Es un parche, no una solución, y hay que tratarlo como tal.
Lo que no hay que hacer
No copies ficheros de claves de un blog ni de una guía de terceros, y no reinicies todo por reflejo: reiniciar un resolver sin la clave nueva solo repite el fallo de forma más ordenada. El orden correcto es diagnosticar con los sentinels, actualizar el ancla desde la fuente oficial y luego reiniciar.
El problema que aparece el mismo día: firmas caducadas
Hay un detalle que se ve justo ahora porque ahora todo el mundo mira su DNS: las firmas caducadas. Una zona mal mantenida puede arrastrar registros de firma ya expirados, y eso rompe la validación igual que un ancla desactualizada, sin tener nada que ver con el rollover. Si tu diagnóstico no cuadra, merece la pena descartar este segundo problema antes de darle vueltas a la clave raíz.
Qué queda pendiente hasta enero de 2027
El calendario no termina hoy. La clave vieja se retira en enero de 2027, y ese día se acaba el margen de maniobra: quien siga confiando solo en ella dejará de validar. La ventana entre hoy y esa fecha es exactamente el tiempo que tienes para arreglar un sistema que aún no esté listo.
Quien no tiene nada que hacer: quien usa el DNS de su operador o un resolver público, y quien depende de un hosting gestionado que ya actualizó. Quien debería mirar hoy: quien administra un servidor con BIND, Unbound o Knot, un contenedor con una imagen fijada por etiqueta, un router de oficina o el DNS interno de una red. El mantenimiento que nadie ve es el que sostiene internet, y este es uno de esos casos: si administras servidores, en el blog tienes una guía de deploy de Laravel 13 en un VPS donde este tipo de comprobaciones de infraestructura encajan igual de bien.
