Cambio de llave raíz del DNS el 11 de octubre: qué revisar en tu pyme

El domingo 11 de octubre de 2026 cambia la llave criptográfica que protege la raíz del DNS, el sistema que traduce nombres como tuempresa.com.ar en direcciones de internet. Desde ese día, la raíz va a usar solo la llave nueva, llamada KSK-2024. Si tu pyme navega con el DNS de tu proveedor de internet o con un servicio público como 1.1.1.1, no tenés que configurar nada en tu red (igual conviene hacer la prueba de cinco minutos que explicamos abajo). Si en tu red hay un servidor propio que resuelve nombres y valida DNSSEC (en la oficina, en un VPS o en la nube), tenés que comprobar esta semana que ya confía en la llave nueva: si no lo hace, para los equipos que dependen de él va a ser como quedarse sin internet.

En esta guía te explicamos qué cambia, cómo saber en cinco minutos si estás alcanzado y qué hacer si algo falla el lunes a la mañana.

Qué cambia exactamente el 11 de octubre#

DNSSEC es una capa de seguridad del DNS que firma las respuestas para que nadie pueda falsificarlas en el camino. Toda esa cadena de firmas termina en una llave maestra de la raíz, la KSK (Key Signing Key). Los servidores que validan DNSSEC guardan una copia de esa llave como "ancla de confianza" y comparan todo contra ella.

Estos son los datos clave, según Cloudflare y la guía de ICANN:

Ese número, 38696, es el que vas a buscar en tus servidores. El cambio no es un corte de un minuto: ICANN advierte que los registros involucrados tienen una vida en caché de 48 horas, así que los efectos pueden aparecer en cualquier momento de las 48 horas posteriores. En la práctica, un servidor no preparado puede funcionar bien el domingo y empezar a fallar el lunes o el martes.

Más adelante viene otro paso: según Cloudflare, ICANN planea revocar la KSK-2017 en 2027, sacarla de la raíz y destruir su clave privada.

Qué pasa si un servidor no está preparado#

Un servidor que valida DNSSEC y solo confía en la llave vieja no puede verificar las firmas nuevas. En lugar de responder, falla. ICANN lo describe sin vueltas: la red va a sufrir fallas totales de resolución de DNS que cortan el acceso a internet.

Para el equipo de una pyme, los síntomas se parecen a una caída del proveedor, y por eso son fáciles de diagnosticar mal. Según la guía de ICANN, las páginas web pueden dejar de cargar o verse a medias, y el correo puede dejar de recibir mensajes nuevos o mostrar partes con errores. Si el lunes 12 alguien dice "no anda internet" pero el router tiene conexión y las direcciones IP responden, el DNS interno es el primer sospechoso.

A quién afecta y a quién no#

La gran mayoría de los sitios web no tiene que tocar nada. Cloudflare aclara que la mayoría de quienes operan sitios web no necesitan hacer cambios, y que quienes usan su resolver 1.1.1.1 tampoco: la empresa agregó la KSK-2024 a sus anclas de confianza en julio de 2024. El riesgo está del lado de quien resuelve nombres, no de quien publica un dominio.

Un ejemplo hipotético: una distribuidora con un servidor Linux en la oficina que hace de DNS para las cajas, el sistema de gestión y el correo. Si ese servidor tiene una configuración vieja, el lunes 12 se cae todo junto aunque la conexión a internet funcione perfecto.

Cómo saber en cinco minutos si estás listo#

Paso 1: el test desde el navegador#

Desde una computadora de la oficina, abrí la prueba de KSK-2024 que recomienda Cloudflare. Usa una técnica estándar (los "centinelas" del RFC 8509) para preguntarle a tu resolver si confía en la llave 38696. La página explica cómo leer el resultado: si el nombre de prueba is-ta-38696 carga y not-ta-38696 queda bloqueado, tu resolver confía en la llave nueva; si pasa al revés, todavía no.

Dos aclaraciones del propio test: el resultado vale solo para el camino de DNS de esa computadora, no para todos tus equipos, y si los tres nombres de prueba cargan, tu resolver no soporta la técnica y el test no dice nada sobre la llave. En ese caso pasá al paso 2.

Para Latinoamérica, el blog de LACNIC menciona otra herramienta basada en la misma técnica, todavía en versión beta: test.kskroll.vulcano.cl.

Paso 2: la prueba desde la terminal#

Si administrás un servidor, Cloudflare publicó dos consultas con dig. Reemplazá 1.1.1.1 por la dirección de tu resolver:

dig @1.1.1.1 root-key-sentinel-is-ta-38696.dnstest.dev. A
dig @1.1.1.1 root-key-sentinel-not-ta-38696.dnstest.dev. A

Si el resolver confía en KSK-2024, la primera consulta responde normalmente y la segunda devuelve SERVFAIL.

Paso 3: buscar la llave en el archivo de configuración#

ICANN pide verificar la configuración a mano en lugar de suponer que la actualización automática funcionó, y busca el identificador 38696 en estos archivos según el software:

En BIND, la base de conocimiento de ISC indica dos comandos para ver qué llaves tiene cargadas: rndc secroots (en todas las versiones) y rndc managed-keys status (desde BIND 9.11). En Unbound, la herramienta unbound-anchor configura o actualiza el ancla de confianza de la raíz.

Por qué un servidor "que se actualiza solo" puede fallar igual#

La mayoría de los resolvers aprende la llave nueva sola, con un mecanismo estándar (RFC 5011): si observa y valida la llave nueva durante 30 días, la agrega a sus llaves de confianza, según explica Verisign. Como la KSK-2024 se publicó en enero de 2025, un servidor encendido y bien configurado tuvo tiempo de sobra.

El problema son las excepciones, y en una pyme son más comunes de lo que parece:

• El servidor no puede escribir lo que aprende. ICANN pide revisar que el resolver tenga permisos de escritura en su carpeta de almacenamiento: si no puede guardar la llave nueva, la "aprende" y la pierde.
• Migraciones y reinstalaciones. En el cambio anterior, de 2018, actualizaciones de software y mudanzas entre máquinas hicieron que algunos resolvers perdieran lo que habían aprendido. Si migraste el servidor a otro proveedor cloud o lo reinstalaste desde una imagen vieja, revisalo.
• Configuración manual. Según ISC, en BIND hay que intervenir a mano si la validación se configuró con dnssec-validation yes; en lugar de auto, y recomienda reemplazar las cláusulas antiguas trusted-keys por managed-keys, que se actualizan solas.
• Equipos que arrastran configuraciones viejas. Verisign midió en julio de 2026 que cerca del 3,5 % de los resolvers todavía conserva la KSK-2010, una llave revocada en 2019. Es una señal de cuántos sistemas quedan sin mantenimiento durante años.

La buena noticia es que la adopción general es alta: ICANN informa que más del 95 % de los resolvers que reportan datos ya reconocen la KSK-2024. La mala es que, si tu servidor está en la minoría restante, el problema es enteramente tuyo.

Qué hacer ahora#

1. Hacé el inventario de quién resuelve nombres en tu red. Mirá qué DNS entrega el router por DHCP y qué DNS usa cada servidor (en Linux, por ejemplo, en la configuración de red del sistema). Anotá si alguno apunta a un resolver propio.
2. Corré el test de dnstest.dev desde la oficina y desde cada sede o red distinta.
3. En cada resolver propio, buscá 38696 en el archivo de anclas que corresponde a tu software y confirmá que la carpeta tiene permisos de escritura.
4. Si falta la llave, actualizá el software o el ancla antes del sábado 10. Hacelo en horario hábil, no el domingo a la noche.
5. Prepará el plan B por escrito. Si el lunes falla algo, la guía de ICANN propone, como medida temporal, desactivar la validación DNSSEC o configurar un ancla negativa para la raíz; después, instalar la KSK-2024 como ancla de confianza y volver a activar la validación. La medida temporal te deja sin la protección de DNSSEC, así que no la dejes puesta.
6. Avisale al equipo. Que quien atiende sistemas sepa que el lunes 12 y el martes 13 un "no anda internet" puede ser DNS.
7. Marcá los backups viejos. Si restaurás después del 11 una máquina virtual o una imagen anterior a 2025, revisá el ancla antes de ponerla en producción.

Esto se suma a una lista que venimos repitiendo en el blog: lo que se instala en servidores propios necesita un responsable de mantenimiento, como vimos con la falla crítica de Jira y Confluence en servidores Data Center y con las actualizaciones pendientes de n8n self-hosted. Y si administrás tu DNS en Cloudflare, aprovechá para ordenar quién puede tocarlo con el control de accesos por roles que Cloudflare abrió a todos los planes.

Qué está pasando en Latinoamérica#

La preparación también tuvo foco regional. En julio de 2026, ICANN y NIC.br, el registro de los dominios .br de Brasil, organizaron una sesión técnica que incluyó la preparación para este cambio. En LACNIC43, Hugo Salgado, arquitecto de DNS de Tucows Domains, pidió a proveedores de internet y empresas que operan resolvers que revisaran su infraestructura antes de octubre de 2026. Y ICANN publicó su guía en los seis idiomas oficiales de la ONU, incluido el español, y en portugués, según su comunicado del 11 de agosto.

Al 7 de octubre no encontramos datos públicos sobre el estado de preparación de los proveedores de internet argentinos en particular. Por eso conviene hacer el test aunque uses el DNS del proveedor: si falla, es un dato concreto para reclamarle.

Preguntas frecuentes#

¿Tengo que cambiar algo en el DNS de mi dominio o en mi hosting?#

No por este cambio. Afecta a los servidores que consultan y validan nombres, no a los que publican tu dominio. Cloudflare aclara que la mayoría de los operadores de sitios web no necesita hacer nada.

¿Me conviene desactivar DNSSEC para no arriesgarme?#

No como medida preventiva. ICANN propone desactivar la validación solo como salida temporal si un resolver falla, y volver a activarla apenas se instala la llave nueva. Lo correcto es verificar hoy que el ancla esté actualizada.

¿Por qué no se cambió con más aviso?#

Se avisó con mucho tiempo: la llave nueva está publicada en la raíz desde enero de 2025 y los resolvers bien configurados la incorporaron solos. Lo que cierra ahora es el período de transición.

¿Cada cuánto pasa esto?#

El cambio anterior fue en 2018 y este es el segundo. Según Tech Times, el próximo se espera alrededor de 2029, así que vale la pena dejar documentado cómo lo resolviste.

Si querés que lo revisemos con vos#

En Mark-Co Digital administramos servidores, DNS e infraestructura cloud para pymes de toda Argentina. Si no tenés claro qué resolver usa tu red o querés que verifiquemos tus servidores antes del domingo, mirá nuestro servicio de cloud e infraestructura, el de configuración de DNS y dominios o el de servidores en Compute Engine, o contanos tu caso y lo vemos juntos.

Fuentes#

• The keys to the Internet change on October 11. Are you ready? (Cloudflare Blog, 6 de octubre de 2026)
• Preparing for the Root Zone KSK Rollover: What You Need to Know (ICANN, 27 de julio de 2026)
• What to Expect During the Root KSK Rollover (ICANN, guía en PDF)
• ICANN Publishes Guidance to Help Prepare for the October 2026 Root KSK Rollover (ICANN, 11 de agosto de 2026)
• The 2024-2026 Root Zone KSK Rollover: Updates and Observations (Verisign Blog, 28 de julio de 2026)
• Prueba de KSK-2024 (dnstest.dev)
• Root KSK Rollover in BIND (ISC Knowledge Base)
• unbound-anchor (documentación de Unbound, NLnet Labs)
• DNS Root Key Signing (LACNIC Blog)
• DNS Trust Anchor Rollover 94 Days Out: ICANN and NIC.BR Run Live Readiness Drill Today (Tech Times, 8 de julio de 2026)