Un cambio silencioso pero crítico en la infraestructura de Internet está programado para el 11 de octubre de 2026: se sustituirá la clave criptográfica situada en la cima de la cadena global de confianza DNSSEC. La mayoría de las personas no debería notar nada. Sin embargo, una red que dependa de un resolver validador desactualizado podría parecer desconectada aunque su acceso a Internet siga activo.
ICANN renovó la advertencia a finales de julio de 2026. Según la organización, más del 95 % de los resolvers que envían las señales analizadas ya reconoce la nueva clave. La cifra es tranquilizadora, pero no incluye necesariamente cada appliance antiguo, firmware sin soporte, instalación aislada o sistema con un ancla configurada manualmente.
Aquí el benchmark se convierte en una herramienta operativa. Una medición previa registra la latencia, el jitter y la disponibilidad normales de cada resolver aprobado. El día del cambio permite separar rápidamente un fallo DNS de un problema de Wi-Fi, proveedor o aplicación.
¿Qué cambiará el 11 de octubre de 2026?
DNSSEC añade firmas criptográficas a los datos DNS. Un resolver validador las usa para comprobar que la respuesta es auténtica y no fue modificada durante el trayecto. En la cima de la jerarquía está la Key Signing Key de la zona raíz, o KSK, que funciona como ancla de confianza global.
La clave actual, KSK-2017, tiene el identificador 20326. Su sucesora, KSK-2024, utiliza el identificador 38696. La nueva clave se publicó con mucha antelación para que los resolvers compatibles con la actualización automática de la RFC 5011 pudieran aprenderla sin interrupciones.
| Etapa | Fecha | Qué ocurre |
|---|---|---|
| Prepublicación | 11 de enero de 2025 | KSK-2024 aparece en la zona raíz |
| Confianza automática | desde el 10 de febrero de 2025 | Los resolvers RFC 5011 pueden confiar en ella |
| Rollover | 11 de octubre de 2026 | KSK-2024 pasa a firmar la raíz |
| Retirada de la clave anterior | enero de 2027 | La KSK anterior sale del conjunto activo |
El evento sustituye el par de claves, no el algoritmo criptográfico. El rollover de 2026 sigue usando RSA con SHA-256.
¿Quién debe actuar?
Usuarios domésticos
Si el router recibe el DNS automáticamente del proveedor, o utilizas un servicio mantenido como Cloudflare, Google Public DNS o Quad9, el operador se encarga de la actualización. No necesitas cambiar contraseñas, volver a registrar dominios ni sustituir el DNS solo por la llegada del rollover.
Conviene recordar la fecha. Si muchos sitios sin relación entre sí dejan de abrir el 11 de octubre mientras las conexiones directas por IP siguen funcionando, el resolver configurado debe investigarse pronto.
Empresas, proveedores y laboratorios
Debes verificar la preparación si la organización ejecuta un resolver recursivo que valida DNSSEC, especialmente cuando:
- usa un ancla de confianza configurada manualmente;
- ejecuta una versión antigua de BIND, Unbound, PowerDNS Recursor o Knot Resolver;
- estuvo apagado o sin acceso a la zona raíz durante mucho tiempo;
- está integrado en un firewall, router o appliance sin soporte;
- no puede escribir las actualizaciones automáticas en su directorio de estado.
ICANN recomienda localizar el key tag 38696 en el archivo de anclas utilizado. Los nombres habituales son bind.keys en BIND, root.key en Unbound y PowerDNS Recursor, y root.keys en Knot Resolver. Sigue la documentación de la versión instalada antes de modificar nada.
Cómo probar si el resolver valida DNSSEC
ICANN recomienda esta prueba a los administradores. Sustituye DIRECCION_DNS por la dirección IPv4 o IPv6 del resolver:
dig @DIRECCION_DNS dnssec-failed.org A +dnssecEl dominio de prueba es inválido de forma intencionada. Por tanto:
status: SERVFAILsignifica que el resolver detectó la firma incorrecta y valida DNSSEC;status: NOERRORsignifica que entregó los datos sin validarlos.
La prueba confirma que la validación está activa, pero no demuestra por sí sola que KSK-2024 esté guardada. El paso decisivo es comprobar la etiqueta 38696 en el estado del ancla y revisar los registros. Actualiza o reinicia el servicio solo siguiendo al proveedor: una edición improvisada puede provocar justamente el fallo que intentas evitar.
Crea una línea base con DNS Benchmark
Una auditoría breve ahora puede ahorrar horas en octubre:
- Prueba el resolver que la red utiliza realmente. Incluye DNS corporativo, DNS del proveedor y alternativas públicas autorizadas.
- Registra media, P95, jitter y disponibilidad. En este evento, resolver correctamente importa más que obtener la menor media.
- Repite en diferentes horarios. Separa la congestión normal del comportamiento del rollover.
- Guarda los resultados de agosto y septiembre. Serán la referencia anterior al cambio.
- Repite el mismo conjunto el 11 y 12 de octubre. Un cambio brusco en un resolver lo señala; un fallo amplio exige revisar DNSSEC y conectividad.
Consulta DNS Benchmark para profesionales de TI para un flujo de auditoría más completo.
Síntomas de un ancla desactualizada
Un resolver que no confía en la nueva KSK puede ser incapaz de validar la raíz. Como la cadena DNSSEC empieza allí, el impacto puede ir mucho más allá de un solo dominio firmado.
Las señales habituales incluyen:
- muchos sitios distintos fallan simultáneamente;
- las aplicaciones muestran “servidor no encontrado” con la red conectada;
- aparecen respuestas
SERVFAILgeneralizadas; - otro resolver actualizado funciona en la misma conexión;
- las IP conocidas responden, pero los dominios no;
- los registros mencionan trust anchor, DNSKEY o errores de validación.
Estos síntomas tienen otras posibles causas. Compara resolvers, códigos y registros en lugar de diagnosticar solo por la latencia.
¿Cambiar al DNS más rápido lo soluciona?
Solo si el resolver actual es el origen del fallo. El rollover no convierte automáticamente a Cloudflare, Google o Quad9 en el servicio más rápido; comprueba si cada operador mantuvo correctamente su cadena de confianza.
En casa, comparar resolvers públicos puede revelar que el DNS entregado por el router dejó de funcionar. En una empresa, un cambio sin autorización puede romper nombres internos, split-horizon, filtrado y auditoría. Prepara una alternativa aprobada y probada previamente con el mismo nivel esperado de DNSSEC.
Evita combinar un resolver validador con otro que ignore DNSSEC. El sistema puede alternarlos de forma inesperada, generar respuestas inconsistentes y debilitar la protección.
Para el usuario común, el cambio debe ser invisible. Para quien opera DNS, “seguramente se actualizó solo” no es una comprobación. Cinco minutos para localizar la etiqueta correcta y una línea base guardada pueden evitar una respuesta a incidentes mucho más larga.
