La raíz DNS cambia de KSK el 11 de octubre

El 11 de octubre de 2026 la raíz DNS cambia la clave que firma a las demás claves. Es la segunda vez que ocurre. Cloudflare lo recordó el 6 de octubre: KSK-2024, key tag 38696, sustituye a KSK-2017, key tag 20326, como firmante del conjunto DNSKEY de la raíz.

Quien publica una web y resuelve con 1.1.1.1, Gateway de Cloudflare o el DNS del operador no tiene tarea. Quien opera un resolver que valida DNSSEC sí. Si ese resolver no confía en la clave nueva, la validación puede fallar para los TLD y los nombres que cuelgan de ellos dejan de resolver, aunque la web esté bien.

-InfraCrew dice: El fallo más elegante del calendario es uno en el que la web responde y el resolver dice que no.-

Qué clave cambia y cuál no

La raíz separa dos trabajos. La zone-signing key firma los registros de la zona, incluidos los DS de los TLD. La KSK firma la lista de claves públicas. El resolver parte de un trust anchor que ya trae, porque la raíz no tiene padre que publique un DS. El 11 de octubre cambia qué KSK firma ese conjunto. El algoritmo sigue siendo RSA/SHA-256. No es un cambio a ECDSA ni a criptografía post-cuántica. ICANN ha propuesto un rollover futuro a ECDSA P-256, aparte de esta fecha.

KSK-2024 está en el DNSKEY de la raíz desde el 11 de enero de 2025. RFC 5011 permite a un resolver aprenderla solo, con una espera de al menos 30 días y una nueva verificación. Cloudflare incorporó la clave a los trust anchors de su software en julio de 2024, precisamente porque en 2018 vio resolvers que perdían el estado aprendido al actualizar o al moverse de máquina.

Cómo comprobarlo antes del domingo

El ensayo útil es el sentinel de RFC 8509. La prueba de Cloudflare está en dnstest.dev/ksk-2024 y pregunta al resolver del navegador si confía en el tag 38696. Un resolver con sentinel que sí confía responde bien a root-key-sentinel-is-ta-38696.dnstest.dev y devuelve SERVFAIL a la variante not-ta. Si el resolver no implementa el sentinel, el resultado es no concluyente, no una prueba de que falte la clave.

Esa prueba mira el resolver que usa el navegador, VPN o DNS sobre HTTPS incluidos. Para el recursivo de la empresa hace falta preguntarle a él. ICANN mantiene la guía del rollover en su página de KSK. Si la clave no está, el camino es el que documente el software del resolver, no un reinicio a ciegas.

-InfraCrew dice: SERVFAIL en el nombre que dice «no confío» es, esta vez, la respuesta buena. Cuesta explicarlo en el ticket.-

Lo que viene después del 11

Firmar con la clave nueva y retirar la vieja no son el mismo paso. ICANN prevé revocar KSK-2017, quitarla de la zona raíz y borrar la privada a lo largo de 2027. Hasta entonces pueden convivir anclas. El intervalo ideal que maneja IANA es de unos tres años. Desde 2018 ha pasado más, por la pandemia y por cambios en el hardware que custodia las claves, según ICANN.

El domingo no obliga a cambiar registros de zona ni a volver a firmar dominios. Obliga a saber si el resolver que valida sigue anclado solo a 20326. Si es así, el 11 de octubre el fallo no va a parecer un corte de fibra. Va a parecer que Internet se ha vuelto incoherente justo en los nombres firmados.

Fuentes

Cloudflare Blog | https://blog.cloudflare.com/root-ksk-2024-rollover

Diccionario de la Crew

KSK — Clave de la raíz DNS que firma el conjunto de claves públicas. El resolver la usa como ancla de confianza de DNSSEC.
DNSSEC — Extensión de DNS que firma las respuestas para poder comprobar que no se han alterado. Si falla la validación, el resolver rechaza el nombre.