14°
Portada del artículo: La raíz de DNSSEC cambia de llave el 11 de octubre: medí qué entornos ya confían en la nueva
DNSDNSSECSeguridadRedes

La raíz de DNSSEC cambia de llave el 11 de octubre: medí qué entornos ya confían en la nueva

El 11 de octubre de 2026 la raíz del DNS empieza a firmar con la KSK-2024; medí qué distribuciones, imágenes Docker, routers y resolvers ya confían en ella. Un unbound recién arrancado en Alpine 3.20, Fedora 42 o Amazon Linux 2023 solo confía en la vieja, y en Pi-hole v5 con DNSSEC y en OpenWrt hasta 23.05 la configuración solo trae esa. Si tu resolver no valida, el cambio no lo toca, salvo que dependa de otro que sí valide y no esté listo.

Efrain Garay 8 de octubre de 2026

Reproduciendo el resumen

El domingo 11 de octubre la raíz del DNS cambia la llave con la que firma. Es la segunda vez que pasa: la primera fue en octubre de 2018. Casi nadie lo va a notar: según APNIC, la mayoría de los usuarios está detrás de resolvers que no validan DNSSEC, y Cloudflare, Quad9 y AdGuard, que sí validan, ya confían en la llave nueva. Lo que me interesaba era el resto: lo que yo mismo corro y lo que la gente corre en su casa, un Pi-hole, un router con OpenWrt, un unbound en un contenedor.

Así que lo medí. Revisé los paquetes de 21 versiones de distribuciones, arranqué desde cero once resolvers de esas distribuciones con su configuración por defecto (uno no concluyente), probé 11 imágenes Docker populares, el dnsmasq de 5 versiones de OpenWrt y 11 resolvers públicos, y dejé 10 resolvers corriendo para ver el cambio en vivo.

Con narración: la raíz del DNS cambia de llave el 11 de octubre de 2026. Un bot cerrajero recorre la cadena de confianza de gob.cl con los tiempos medidos, se ve qué entornos siguen con la llave vieja y cómo revisar el tuyo con dos consultas de dig. Todas las cifras son las medidas.Verlo en el visualizador de reels →

Qué es DNSSEC, sobre una consulta real

DNS sin DNSSEC confía en quien responde: si alguien en el camino cambia la respuesta, tu equipo no tiene cómo saberlo. DNSSEC agrega firmas. Cada zona firma sus registros con sus llaves, y la zona de arriba publica un resumen de esas llaves (un registro DS) firmado con las suyas. Así se arma una cadena desde la raíz hasta el nombre que preguntaste.

Quien revisa la cadena es el resolver que valida. Para empezar necesita confiar en algo sin pedir prueba: el ancla de confianza, una copia de la llave que firma la raíz. Si toda la cadena calza, la respuesta sale con la marca AD (datos autenticados). Si algo no calza, sale SERVFAIL.

Esa es la cadena de verdad para gob.cl, preguntada directo a cada servidor el 7 de octubre:

La cadena de confianza de gob.cl, eslabón por eslabónPreguntada a cada autoridad directamente el 7 de octubre de 2026. Ese día la raíz firmaba con la llave 20326.
Cadena de confianza DNSSEC de gob.cl Diagrama de arquitectura: el resolver confía en la llave raíz 20326, que firma el conjunto de llaves de la raíz; la llave de zona 8763 de la raíz firma el DS de .cl, la llave 14901 de .cl firma el DS de gob.cl y la llave 6334 de gob.cl firma la respuesta. La llave raíz 38696 reemplaza a la 20326 el 11 de octubre de 2026. Tu resolver · ancla: 20326 · Architecture component Tu resolver ancla: 20326 Raíz · KSK 20326 · firma el conjunto DNSKEY · Architecture component Raíz · KSK 20326 firma el conjunto DNSKEY Raíz · ZSK 8763 · firma el DS de .cl · Architecture component Raíz · ZSK 8763 firma el DS de .cl .cl · 21199 · ZSK 14901 firma DS · Architecture component .cl · 21199 ZSK 14901 firma DS gob.cl · 6334 · firma su respuesta · Architecture component gob.cl · 6334 firma su respuesta Respuesta con AD · validada · Architecture component Respuesta con AD validada Raíz · KSK 38696 · firma desde el 11 oct · Architecture component Raíz · KSK 38696 firma desde el 11 oct coincide RRSIG DS DS RRSIG la reemplaza
  • tu resolver y su ancla
  • KSK-2017 (20326), firma hoy
  • KSK-2024 (38696), firma desde el 11 oct
  • zonas bajo la raíz
  • camino validado
Diagrama compilado con Archify desde un JSON tipado, sobre las llaves que devolvió cada servidor. Si tu resolver solo tiene la 20326 en su ancla, la primera vez que renueve el conjunto de llaves de la raíz después del 11 de octubre se corta el primer eslabón, y con él todo lo que cuelga abajo.

El primer eslabón es el único que cambia el domingo. Todo lo de abajo sigue igual: .cl sigue firmando con su llave 21199 y gob.cl con la 6334.

Qué cambia el domingo

Hasta el 10 de octubre la raíz firma su conjunto de llaves con la KSK-2017, etiqueta 20326. Desde el 11 lo firma la KSK-2024, etiqueta 38696, que está publicada en la zona raíz desde enero de 2025. El 7 de octubre el conjunto tenía cuatro llaves (dos llaves de zona, 8763 y 57780, por un cambio trimestral en curso, más las dos KSK) y una sola firma, de la 20326.

Ese conjunto se guarda en caché hasta 48 horas, que es su TTL. Por eso ICANN no da una hora de falla: un resolver que solo confía en 20326 sigue funcionando con su copia vieja y falla la próxima vez que la renueva. ICANN espera que eso pase dentro de las 48 horas siguientes, aunque un resolver con poco uso puede tardar más. Según Cloudflare, ICANN planea revocar y retirar la KSK-2017 en 2027; el documento de ICANN estima el cambio siguiente para 2029, y con él el paso a ECDSA.

Para ver el mecanismo armé cuatro resolvers unbound 1.26.1 que solo se diferencian en su ancla: uno con la llave vieja, otro con la nueva, otro con las dos y otro que se actualiza solo con RFC 5011 y arrancó el 7 de octubre. La animación recorre los seis saltos de la cadena de gob.cl con el tiempo medido de cada uno (la suma de las seis medianas, preguntadas directo a cada autoridad desde Chile, da 383 ms), y el estado de cada resolver es el que midió la vigilancia el 7 de octubre:

El primer eslabón, en bucle y a la velocidad medidaCuatro resolvers validan gob.cl, cada uno con un ancla distinta. Cambia la fecha: la raíz cambia la llave que firma su conjunto de llaves.

La primera posición es el estado que midió la vigilancia el 7 de octubre (consultas a example.com): el resolver que solo tiene la 38696 ya falla. La segunda es lo que prevé la norma; la vigilancia mantiene los cuatro resolvers corriendo durante el cambio y esta figura se reemplazará con lo que mida. Los tiempos de los tramos son los de la cadena de gob.cl.

Dos cosas que la animación muestra y que no son obvias:

  • Cuando se pierde la raíz falla también lo que no está firmado. Un resolver que valida en modo estricto, para responder un nombre sin firmar, tiene que probar desde la raíz que esa delegación es insegura, y sin raíz no puede. El unbound que solo confía en la 38696 respondió el 7 de octubre SERVFAIL también para efraingaray.com, que no está firmado.
  • RFC 5011 no salva a lo que arrancó tarde. El unbound que se actualiza solo vio la 38696 el 7 de octubre y la dejó en espera de 30 días (ADDPEND). El domingo todavía no confiará en ella, y después tampoco podrá terminar la espera por su cuenta: el conjunto pasará a estar firmado solo por una llave en la que aún no confía.

Quién valida de verdad

La mayoría no valida. APNIC mide con anuncios qué usuarios están detrás de resolvers que validan: en la ventana de 30 días al 5 de octubre, el 9,1 % en Chile (más un 3,6 % que valida en parte) y el 39,1 % en el mundo. Si tu resolver no valida, el cambio no te toca, aunque puedes depender de uno de más arriba que sí valide.

Mis propias máquinas son un buen ejemplo. En fedora (Fedora 43) y en el VPS (Ubuntu 24.04), systemd-resolved está con DNSSEC=no: no validan, delegan. El Mac usa 8.8.8.8. El VPS tiene configurado el resolver de Hostinger, que sí entrega respuestas validadas. El router de la casa de fedora devolvió el dominio con firmas rotas sin SERVFAIL y sin marcar AD.

Los resolvers públicos los pregunté desde Chile, con los dos nombres del centinela de RFC 8509 y un nombre con firmas rotas a propósito (a Yandex, dos). Lo que se ve desde aquí es lo que responde el nodo anycast que atiende a Chile:

  • Cloudflare, Quad9 y AdGuard validan y su centinela responde como resolvers que ya confían en la 38696.
  • Google, OpenDNS, Control D, CleanBrowsing y DNS.SB validan, pero respondieron las dos preguntas del centinela, así que esta prueba no dice qué anclas tienen.
  • Yandex DNS es el caso raro. En sus tres direcciones y en tres repeticiones (dos de 81 consultas no respondieron), marca AD en lo bien firmado y deja pasar con NOERROR y sin AD dos nombres con firmas rotas a propósito. Su centinela responde como un resolver que confía en la 20326 y no en la 38696, y la pregunta de control por la 20326 sale al revés, como corresponde. Es compatible con validar en modo permisivo: si esa política también se aplica cuando falle la raíz, el domingo podría seguir respondiendo sin marcar AD en vez de caerse. La vigilancia lo va a medir.

Dónde se usa DNSSEC

Del lado de quien firma, la adopción es alta arriba y baja abajo. Conté la zona raíz completa (serial 2026100702): 1.350 de 1.437 TLD tienen DS, incluido .cl. Entre los 1.000 primeros de la lista Tranco del 6 de octubre (un ranking de popularidad que combina varias fuentes), 109 tienen un registro DS propio. En una muestra chilena que elegí a mano, 62 dominios de seis sectores, firman 7: gob.cl, nic.cl, santander.cl, bancointernacional.cl, falabella.com, sodimac.cl y wom.cl. Ninguna de las 8 universidades ni de los 10 medios que elegí.

Presencia de DS propio, medida el 7 de octubre de 2026% · más es mejor
  1. TLD de la zona raíz93,9 %1.350 de 1.437, .cl incluido
  2. Top 1.000 de Tranco10,9 %109 de 1.000 con DS propio
  3. Muestra chilena11,3 %7 de 62; 0 de 8 universidades, 0 de 10 medios

Zona raíz de IANA, serial 2026100702; lista Tranco 26Y29 (6 oct 2026); muestra chilena elegida a mano, no aleatoria. Un DS cuenta solo si es un registro DS del propio nombre.

En los TLD manda RSASHA256, el algoritmo 8: lo publican 1.086, contra 269 que publican ECDSA P-256 (el 13), y 40 publican más de uno. Mi dominio tampoco está firmado: efraingaray.com no publica DNSKEY y .com devuelve una prueba de que no hay DS. Para el cambio del domingo eso da igual: lo que importa es quién valida.

Entorno por entorno

Aquí está la medición que me interesaba. Separé dos preguntas que se suelen mezclar: qué llave trae cada paquete y en qué llave confía el resolver cuando arranca con su configuración por defecto.

Entorno por entorno: qué llave raíz trae cada unoMedido el 7 de octubre de 2026. Elige una vista.
systemd-resolvedunbound-anchordns-root-dataunbound root.keydnssec-rootBINDdnsmasq
debian:10no encontrado2010 y 20172017no encontradono encontrado2010 y 20172010 y 2017
debian:11201720172017 y 2024no encontradono encontrado20172017
debian:122017 y 202420172017 y 2024no encontradono encontrado2017 y 20242017
debian:132017 y 20242017 y 20242017 y 2024no encontradono encontrado2017 y 20242017 y 2024
ubuntu:18.042010 y 20172010 y 20172010 y 2017no encontradono encontrado2010 y 2017no encontrado
ubuntu:20.0420172010 y 20172017 y 2024no encontradono encontrado20172017
ubuntu:22.04201720172017 y 2024no encontradono encontrado2017 y 20242017 y 2024
ubuntu:24.04201720172017 y 2024no encontradono encontrado2017 y 20242017 y 2024
ubuntu:26.042017 y 20242017 y 20242017 y 2024no encontradono encontrado2017 y 20242017 y 2024
fedora:422017 y 20242017 y 2024no encontrado2017no encontrado2017 y 20242017
fedora:432017 y 20242017 y 20242017 y 20242017 y 2024no encontrado2017 y 20242017 y 2024
fedora:442017 y 20242017 y 20242017 y 20242017 y 2024no encontrado2017 y 20242017 y 2024
rockylinux:82010 y 20172017 y 2024no encontradono encontradono encontrado2017 y 2024no encontrado
rockylinux:920172017 y 2024no encontrado2017 y 2024no encontrado2017 y 20242017 y 2024
rockylinux:102017 y 20242017 y 2024no encontrado2017 y 2024no encontrado2017 y 20242017 y 2024
amazonlinux:2ninguna2017no encontrado2017no encontrado2010 y 2017no encontrado
amazonlinux:202320172017no encontradono encontradono encontrado2017 y 2024no encontrado
alpine:3.18no encontrado2017no encontradono encontrado20172017 y 20242017
alpine:3.20no encontrado2017no encontradono encontrado20172017 y 20242017
alpine:3.22no encontrado2017 y 2024no encontradono encontrado2017 y 20242017 y 20242017 y 2024
alpine:3.24no encontrado2017 y 2024no encontradono encontrado2017 y 20242017 y 20242017 y 2024

Llaves que trae cada paquete tal como se ofrecía el 7 de octubre de 2026, instalado en la imagen oficial de cada versión, por año de la llave (2010 = 19036, 2017 = 20326, 2024 = 38696). "No encontrado": el escaneo no encontró ese componente en esa versión. Esto es lo que trae el paquete, no en qué confía un resolver andando: eso está en la vista siguiente. En las 13 imágenes donde se pudo leer su resolved.conf, el valor por defecto que documenta para systemd-resolved es DNSSEC=no.

Resolver y versiónVersión¿Confía en 38696 recién arrancado?
debian:11 bind99.16.50-1~deb11u6sí
ubuntu:20.04 bind99.18.30-0ubuntu0.20.04.2sí
ubuntu:24.04 bind99.18.39-0ubuntu0.24.04.7sí
debian:12 unbound1.17.1-2+deb12u4sí
ubuntu:24.04 unbound1.19.2-1ubuntu3.10sí
amazonlinux:2023 unbound1.17.1-1.amzn2023.0.15no
alpine:3.20 unbound1.20.0-r2no
ubuntu:24.04 systemd-resolved DNSSEC=yes255.4-1ubuntu8.17no se puede saber
alpine:3.22 unbound1.25.2-r1sí
fedora:42 unbound1.24.2-1.fc42no

Configuración por defecto, primer arranque, preguntado con el centinela de RFC 8509. En estas pruebas BIND confió en todas las llaves del conjunto raíz firmadas por su ancla al iniciar su almacén vacío; unbound con RFC 5011 deja 30 días en espera una llave que acaba de ver, y con un ancla fija solo confía en lo que trae ese archivo. systemd-resolved no implementa el centinela.

ImagenCreada¿Confía en 38696?
mvance/unbound:1.17.12023-10-05no
mvance/unbound:1.20.02024-06-08no
mvance/unbound:latest2024-10-19sí
klutchell/unbound:1.17.12023-01-13no
klutchell/unbound:latest2026-09-18sí
isc/bind9:9.182026-06-17sí
isc/bind9:9.202026-09-30sí
cznic/knot-resolver:v5.7.42024-07-23sí
cznic/knot-resolver:v5.7.82026-10-06sí
pihole/pihole:2024.07.02024-07-05configuración: 2017 confianza no medida: dnsmasq no tiene centinela
pihole/pihole:latest2026-09-19configuración: 2017 y 2024 confianza no medida: dnsmasq no tiene centinela
OpenWrt: lo que trae el paquete dnsmasq-full (contenido, no prueba en marcha)
OpenWrt 19.07.102.80-16.32010 y 2017
OpenWrt 21.02.72.85-92017
OpenWrt 22.03.72.86-162017
OpenWrt 23.05.62.90-22017
OpenWrt 24.10.82.93-r12017 y 2024

Imágenes arrancadas con su configuración por defecto (BIND forzado a IPv4 y Knot en modo no interactivo, por Docker; Pi-hole con DNSSEC activado). Pi-hole y dnsmasq no implementan el centinela, así que en ellos se leyeron las líneas trust-anchor activas de la configuración generada.

Resolver¿Valida?¿Confía en 38696?
Cloudflare 1.1.1.1sísí
Google 8.8.8.8síno se puede saber
Quad9 9.9.9.9sísí
OpenDNS 208.67.222.222síno se puede saber
AdGuard 94.140.14.14sísí
Control D 76.76.2.0síno se puede saber
CleanBrowsing 185.228.168.9síno se puede saber
Yandex 77.88.8.8permisivono
DNS.SB 185.222.222.222síno se puede saber
Quad101 101.101.101.101no responde·
Lumen 4.2.2.2no·

Consultados desde Chile, un nodo anycast. "No se puede saber": el resolver valida y respondió las dos preguntas del centinela, así que esta prueba no dice qué anclas tiene. Permisivo: marca con AD lo bien firmado pero en esta prueba dejó pasar las firmas rotas.

Lo que sale de las cuatro vistas:

  • Que un paquete traiga la llave no quiere decir que el resolver confíe en ella. Manda el archivo al que apunta la configuración. unbound recién instalado no confía en la 38696 en Amazon Linux 2023 (arranca de su ancla integrada, con solo la vieja), en Fedora 42 (su root.key trae solo la 20326) ni en Alpine 3.20, donde la configuración por defecto usa un ancla fija, sin actualización: el trusted-key.key del paquete dnssec-root (versión 20190225), que solo trae la vieja. En Alpine 3.22 sí confía.
  • Las versiones viejas traen hasta la llave de 2010. Debian 10, Ubuntu 18.04 y Amazon Linux 2 conservan la 19036, retirada en 2019, y ninguno trae la 38696.
  • En Debian 12 y Ubuntu 24.04, unbound sale bien por un paso del servicio. Antes de arrancar, unbound copia el root.key de dns-root-data, que trae las dos llaves aunque su ancla integrada sea vieja.
  • BIND aprende al arrancar. Debian 11 trae BIND 9.16.50 con solo la 20326 en sus archivos, y aun así, recién arrancado, rndc managed-keys status muestra las dos llaves de confianza desde el primer segundo: al iniciar su almacén de llaves vacío valida el conjunto DNSKEY con la que trae e instala las vigentes. Una llave que aparece después sí espera 30 días.
  • Lo estático no se actualiza solo. dnsmasq no hace RFC 5011: confía en las líneas trust-anchor= de su configuración. En la configuración de Pi-hole v5.18.3 con DNSSEC, las líneas trust-anchor activas que encontré solo tienen la 20326; en la de v6.4.3 están las dos. El paquete dnsmasq-full de OpenWrt 21.02, 22.03 y 23.05 trae solo la vieja, y el de 19.07 trae además la de 2010, retirada en 2019; 24.10 trae las dos.
  • systemd-resolved valida solo si se lo pides, y entonces no se actualiza. En las 13 imágenes donde pude leer su resolved.conf, el valor por defecto que documenta es DNSSEC=no. Con DNSSEC=yes usa su ancla integrada. La 38696 llegó al código de systemd en el commit 8113361, publicado en la versión 258. Los paquetes de Debian 12 y 13 y Fedora 42 ya la traen en versiones anteriores; los de Ubuntu 22.04 y 24.04, Rocky 9 y Amazon Linux 2023, no.
  • Tres imágenes de unbound de 2023 y junio de 2024 arrancan sin confiar en la nueva: mvance/unbound 1.17.1 y 1.20.0 y klutchell/unbound 1.17.1. Sus versiones actuales, sí.

Hay también caminos de reparación que no medí después del cambio y que dejo con su fuente. Según su manual, unbound-anchor (el servicio que corre antes de unbound en Fedora, RHEL y Amazon Linux) puede recuperar el ancla descargando root-anchors.xml de IANA por HTTPS y verificándolo, si se ejecuta y la verificación pasa. En Debian y Ubuntu el servicio vuelve a copiar dns-root-data al arrancar, lo que sirve si ese paquete está al día. Un ancla fija necesita que alguien la cambie.

La vigilia: diez resolvers cruzando el cambio

Desde el 7 de octubre corren en mi Mac diez resolvers: los cuatro unbound de la animación, mvance/unbound 1.17.1 y su versión actual, Pi-hole v5 y v6 con DNSSEC activado, y systemd-resolved de Ubuntu 24.04 y 26.04 con DNSSEC=yes. Cada cinco minutos un script les pregunta un nombre firmado, uno sin firmar y las dos preguntas del centinela, y anota qué llave firma la raíz según a.root-servers.net. A la misma tanda suma Cloudflare, Google, Quad9 y Yandex.

El 7 de octubre respondían todos salvo el que solo confía en la llave nueva. Lo que espero ver después del domingo es que caigan el de la llave vieja, el RFC 5011 que arrancó tarde, mvance/unbound 1.17.1, Pi-hole v5 y systemd-resolved de Ubuntu 24.04. Este artículo se actualiza con lo que mida, incluida la hora en que cada uno empezó a fallar.

Cómo revisar el tuyo (y cómo arreglarlo)

Primero, pregúntale el centinela a tu resolver:

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

Si el primero responde y el segundo da SERVFAIL, ya confía en la 38696. Si es al revés, no confía. Si responden los dos, la prueba no concluye: puede que no valide, que no implemente el centinela (dnsmasq, Pi-hole y systemd-resolved no lo implementan) o que cada pregunta la conteste un servidor distinto. En lo que corres tú, revisa sus anclas:

  • unbound: si usa auto-trust-anchor-file (lo dice unbound-checkconf -o auto-trust-anchor-file), busca la 38696 en ese archivo y revisa que diga VALID, no ADDPEND. Si usa un ancla fija (trust-anchor-file o trust-anchor:), ese archivo o esa línea tiene que traer la 38696.
  • BIND: rndc managed-keys status tiene que mostrar keyid: 38696 con trusted since.
  • dnsmasq y Pi-hole v5: grep -r '^trust-anchor=' /etc/dnsmasq.d /etc/dnsmasq.conf.
  • systemd-resolved con DNSSEC=yes: si no hay archivos *.positive en /etc/dnssec-trust-anchors.d/, /run/dnssec-trust-anchors.d/, /usr/local/lib/dnssec-trust-anchors.d/ ni /usr/lib/dnssec-trust-anchors.d/, usa su ancla integrada.

Para arreglarlo, se agrega la llave nueva sin quitar la vieja hasta el cambio. Una etiqueta de llave es solo un número de 16 bits, así que conviene comparar el registro DS completo con el que publica IANA. El de la KSK-2024 es este:

. IN DS 38696 8 2 683D2D0ACB8C9B712A1948B27F741219298D0A450D612C483AF444A4C0FB2B16

En dnsmasq y Pi-hole v5 va como trust-anchor=.,38696,8,2,683D2D0A... con el digest completo, o actualizas a Pi-hole v6. En systemd-resolved va en un archivo /etc/dnssec-trust-anchors.d/root.positive con las dos líneas DS, la de 20326 y la de 38696: según su manual, apenas defines un ancla para la raíz deja de usar la integrada, y no se actualiza sola. En unbound, actualiza el paquete que trae el ancla (dns-root-data en Debian y Ubuntu, dnssec-root en Alpine) o deja que unbound-anchor la renueve. En BIND, actualizar el paquete no cambia un almacén de llaves ya creado: si rndc managed-keys status no muestra la 38696 como confiable, sigue la guía de ISC para ese caso.

Si el domingo algo se cae, la salida de emergencia que da ICANN es desactivar un momento la validación o poner un ancla negativa para la raíz (RFC 7646), instalar la KSK-2024 y volver a validar.

Lo que no puedo afirmar

  • Lo que pasa después del domingo. Todo lo de este artículo es del 7 de octubre. Lo previsto está marcado como previsto; la vigilancia lo va a confirmar o desmentir.
  • El estado global de los resolvers públicos. Medí desde un solo lugar, Santiago, y veo el nodo anycast que me atiende a mí.
  • Qué anclas tienen los que no implementan el centinela. Google, OpenDNS, Control D, CleanBrowsing, DNS.SB y el resolver de Hostinger validan, pero con esta prueba no se ve en qué confían.
  • Las instalaciones que ya llevan tiempo corriendo. Medí arranques desde cero. Un BIND o un unbound con RFC 5011 funcionando, estado guardado y la espera de 30 días cumplida ya confía en la 38696 aunque su paquete original solo trajera la vieja. El riesgo está en perder ese estado (contenedores sin volumen, reinstalaciones, imágenes viejas recreadas), en las anclas fijas viejas y en las actualizaciones que fallan.
  • Fedora 43 recién arrancado. Su root.key trae las dos llaves en estado VALID, pero dentro de Docker su unbound respondió SERVFAIL hasta para example.com, así que esa prueba no cuenta.

Mi opinión

El domingo va a pasar sin que la mayoría lo note, y eso es mérito de quienes publicaron la llave nueva con 21 meses de anticipación. Pero la gente que valida DNSSEC por su cuenta es justo la que monta un Pi-hole, un OpenWrt o un unbound en un contenedor, y ahí encontré anclas viejas en versiones que todavía circulan. Lo que más me sorprendió fue lo distinto que se comporta cada software con la misma llave: en estas pruebas BIND confió en la llave nueva desde el primer arranque, unbound con RFC 5011 la dejó 30 días en espera y dnsmasq no la actualiza solo.

Cuándo preocuparse y cuándo no

  • No tienes que hacer nada en tu equipo si usas el DNS de tu proveedor, de tu router de fábrica o uno público, o si tu systemd-resolved está con DNSSEC=no: la validación, si la hay, la hace el resolver de arriba.
  • Revisa hoy si tienes Pi-hole v5 con DNSSEC, OpenWrt hasta 23.05 con dnsmasq-full y DNSSEC, unbound o BIND en contenedores que se recrean, Alpine 3.20 o anterior con unbound, o systemd-resolved con DNSSEC=yes en Ubuntu 22.04 o 24.04.
  • Ten a mano la salida de emergencia si administras un resolver para más gente: el ancla negativa de RFC 7646 o desactivar la validación un momento, y después instalar la KSK-2024.

Medido el 7 de octubre de 2026 desde Santiago de Chile. Contenedores en Docker 29.3.1 sobre un Mac x86_64; resolvers de prueba unbound 1.26.1-0+deb13u1 sobre debian:13-slim. Paquetes de cada distribución instalados ese día desde sus repositorios (Debian 10 y 11 desde archive.debian.org). Lista Tranco 26Y29; zona raíz con serial 2026100702; datos de APNIC con ventana de 30 días al 5 de octubre.

Preguntas frecuentes

¿Qué cambia el 11 de octubre de 2026?

La raíz del DNS empieza a firmar su conjunto de llaves con una llave nueva, la KSK-2024 (etiqueta 38696), en lugar de la KSK-2017 (etiqueta 20326) que firma desde 2018. La nueva está publicada en la zona raíz desde enero de 2025. Un resolver que valida DNSSEC y solo confía en la vieja deja de poder validar la raíz cuando renueva su conjunto de llaves, y desde ahí responde SERVFAIL, también para nombres sin firmar.

¿Me afecta si uso el DNS de mi proveedor, Cloudflare o Google?

No tienes que hacer nada en tu equipo: la validación la hace ese resolver, y si no estuviera listo, el arreglo le corresponde a quien lo administra. Medí desde Chile que Cloudflare, Quad9 y AdGuard ya confían en la llave nueva; Google, OpenDNS, Control D, CleanBrowsing y DNS.SB validan, pero esta prueba no permite ver qué anclas tienen. Según APNIC, en Chile solo el 9,1 % de los usuarios está detrás de un resolver que valida.

¿Cómo sé si mi resolver ya confía en la llave nueva?

Pregúntale dos nombres de prueba de RFC 8509: dig @tu-resolver root-key-sentinel-is-ta-38696.dnstest.dev y dig @tu-resolver root-key-sentinel-not-ta-38696.dnstest.dev. Si el primero responde y el segundo da SERVFAIL, confía en ella. Si es al revés, no confía. Si los dos responden, la prueba no concluye: puede que no valide, que no implemente la prueba (pasa con dnsmasq, Pi-hole y systemd-resolved) o que cada pregunta la conteste un servidor distinto, y hay que mirar sus anclas a mano.

Tengo Pi-hole con DNSSEC activado, ¿qué hago?

Si es Pi-hole v5 (la imagen 2024.07.0 trae la v5.18.3), las líneas trust-anchor activas de su configuración solo tienen la 20326, y dnsmasq no se actualiza solo: actualiza a v6, que escribe las dos, o agrega la línea trust-anchor de la 38696 sin quitar la vieja. Con DNSSEC desactivado, Pi-hole no valida y el cambio no lo afecta directamente; depende de que su resolver de arriba esté listo.

¿Por qué puede fallar también lo que no está firmado?

Porque un resolver que valida en modo estricto, para responder un nombre sin firmar, tiene que probar desde la raíz hacia abajo que esa delegación es insegura, y cuando necesita volver a validar la raíz ya no puede. Lo medí: un unbound que solo confía en la llave nueva respondió el 7 de octubre SERVFAIL también para efraingaray.com, que no está firmado.

¿Qué hago si el domingo se me cae el DNS?

ICANN recomienda, como salida de emergencia, desactivar un momento la validación o configurar un ancla negativa para la raíz (RFC 7646), y después instalar la KSK-2024 como ancla y volver a validar. Lo que no hay que hacer es dejar solo la 38696 antes del cambio: eso también falla, lo medí el 7 de octubre.

¿Mi sitio web tiene que hacer algo?

No. El cambio afecta a quienes validan; quienes firman o publican no tienen que hacer nada. Mi propio dominio, efraingaray.com, ni siquiera está firmado: no publica DNSKEY y .com devuelve una prueba de que no hay DS.

Fuentes

Comentarios

Todavía no hay comentarios. El primero es tuyo.

Se revisa antes de publicarse. El correo no se guarda ni aparece en ninguna parte.