Actualizado el 18 de octubre de 2026. El cambio previsto ya ocurrió: KSK-2024, identificador 38696, comenzó a firmar la raíz DNS el 11 de octubre. IANA confirmó la entrada en servicio de la nueva clave. Comunicado de IANA.
El 15 de octubre, ICANN informó de que el cambio se completó según lo previsto. Está evaluando informes que afectan a un número limitado de sistemas y su posible relación con la transición. Esto no demuestra una caída generalizada. Balance de ICANN.
¿Qué cambió y qué queda pendiente?
DNSSEC autentica datos DNS mediante una cadena de firmas. La KSK raíz es el ancla en la parte superior. Un resolver validador debe confiar en la clave adecuada para verificar las respuestas.
| Hito | Situación |
|---|---|
| Publicación anticipada de KSK-2024 | Realizada para permitir actualizar los resolvers |
| Inicio de la firma de la raíz con KSK-2024 | 11 de octubre de 2026 |
| Revocación de la KSK anterior | Prevista para enero de 2027 |
IANA mantiene el calendario y las anclas oficiales. Activar la nueva clave no completa todas las etapas de mantenimiento.
¿Quién debe revisar su entorno ahora?
Los usuarios de resolvers mantenidos por su proveedor o por servicios públicos normalmente dependen de la actualización del operador. No hay motivo para cambiar contraseñas o direcciones DNS solo porque cambió la clave.
Los administradores de resolvers propios deben comprobar el key tag 38696 en el estado de confianza que utiliza realmente el software. Prioriza instalaciones antiguas, anclas manuales, appliances sin soporte y servidores que estuvieron apagados mucho tiempo.
La RFC 5011 permite actualizar anclas automáticamente, pero el resolver necesita mantener su estado y observar los cambios. Consulta la documentación de la versión instalada antes de recargar el servicio o editar archivos.
Cómo investigar SERVFAIL tras el cambio
Recomendamos empezar con dos consultas al mismo resolver, sustituyendo DIRECCION_DNS:
dig @DIRECCION_DNS cloudflare.com A +dnssec
dig @DIRECCION_DNS dnssec-failed.org A +dnssecEl segundo dominio tiene DNSSEC inválido de forma intencionada. Un SERVFAIL allí, por sí solo, no demuestra que la validación funcione: un resolver con el ancla rota también puede fallar en todas las consultas.
Comprueba que el primer dominio resuelva, revisa la indicación de autenticación (ad, cuando corresponda) y que se rechace el dominio inválido. Después examina registros, reloj del servidor y anclas. Estas consultas no sustituyen la inspección de la configuración; cualquier SERVFAIL tampoco demuestra relación con el rollover.
Cómo usar el benchmark después del evento
Compara los resultados actuales con mediciones anteriores si existen. Sin historial, registra una referencia ahora: mismos dominios, misma red y horarios comparables. Observa disponibilidad, errores, mediana, P95 y jitter cuando estén disponibles.
La latencia ayuda a investigar, pero no identifica por sí sola un fallo criptográfico. Consulta DNS Benchmark para profesionales de TI. En empresas, utiliza alternativas aprobadas para preservar nombres internos y políticas de acceso.
¿Este cambio convirtió el DNS en poscuántico?
No. Sustituir una clave y migrar el algoritmo de firma son procesos distintos. Lee qué cambia con DNSSEC poscuántico en 1.1.1.1.
