Qué cambió el 11 de octubre de 2026
DNSSEC se apoya en una única raíz de confianza: la clave de firma de claves (KSK) de la zona raíz. Cada resolver validador guarda una copia local, llamada ancla de confianza, y verifica todo lo demás a partir de ella. Según IANA, KSK-2024 (key tag 38696) se publicó en la zona raíz el 11 de enero de 2025 y empezó a firmar la raíz el 11 de octubre de 2026, en lugar de KSK-2017 (key tag 20326).
El 15 de octubre de 2026, ICANN anunció que el cambio de clave había concluido según lo previsto. El anuncio menciona informes que afectan a un número limitado de sistemas y precisa que ICANN aún evalúa si están relacionados con el cambio: no da ni cifra ni causa, y esta guía tampoco las sugiere. El calendario no ha terminado: IANA prevé revocar KSK-2017 el 11 de enero de 2027 y retirarla de la zona el 22 de marzo de 2027.
Lo que hay que recordar
- La clave que buscar — KSK-2024, key tag 38696, algoritmo 8 (RSA/SHA-256). La anterior, KSK-2017, tiene el key tag 20326.
- El síntoma — un resolver que solo confía en 20326 ya no puede validar la raíz. Verisign e ICANN advierten que entonces deja de resolver, esté firmado o no el nombre solicitado.
- El mecanismo normal — el RFC 5011 permite a un resolver adoptar por sí solo una nueva clave tras observarla 30 días, siempre que esté en marcha y pueda escribir su archivo de ancla.
- Los casos de riesgo — una imagen de sistema o una instantánea más antigua que la clave, un archivo de ancla de solo lectura, un ancla estática en dnsmasq o en BIND.
- Lo que no cambia — el registro DS de su dominio en el registro: el cambio afecta a la clave de la raíz, no a la de su zona.
- Lo que viene — revocación de KSK-2017 prevista para el 11 de enero de 2027, retirada el 22 de marzo de 2027. Un resolver que ya confía en 38696 valida la raíz firmada con esa clave.
Propietario de dominio o administrador de servidor: quién debe actuar
Dos funciones se confunden a menudo en los tickets. El propietario de un dominio firmado publica un registro DS en el registro, que designa la clave de SU zona. Ese DS no depende de la clave de la raíz: no hay nada que cambiar por este rollover, ni en la zona de example.com ni en su registrador. Si solo gestiona sus registros (consulte añadir un registro DNS), no le afecta.
Al administrador de un servidor que ejecuta un resolver validador, sí. Unbound detrás de un servidor de correo, BIND en un servidor de supervisión, Knot Resolver en un contenedor, systemd-resolved con DNSSEC activado, dnsmasq o Pi-hole con la validación activada: cada uno lleva su propia ancla. En un VPS con acceso root, ese administrador es usted. Un servidor que simplemente reenvía sus consultas a un resolver público sin validar depende del ancla de ese resolver, no de la suya.
Requisitos previos del diagnóstico
Reserve diez minutos y acceso root o sudo al servidor. Bastan dos herramientas: dig y delv, incluidas en Debian y Ubuntu en el paquete bind9-dnsutils (sudo apt install bind9-dnsutils), y en AlmaLinux o Rocky Linux en bind-utils. No se necesitan recursos particulares: las consultas pesan unos pocos kilobytes.
Anote la dirección de escucha de su resolver, normalmente 127.0.0.1, o 127.0.0.53 para systemd-resolved, y tenga a mano la dirección de un resolver público validador para comparar, por ejemplo 9.9.9.9. Las salidas descritas a continuación son ejemplos de forma, no mediciones de su servidor: solo cuentan los campos nombrados. Las pruebas apuntan a la raíz y a com., dos zonas firmadas, así que no dependen de ningún dominio concreto.
Diagnosticar su resolver en siete pasos
Identificar el resolver que responde
cat /etc/resolv.confmuestra la dirección que consulta el sistema,resolvectl statusindica si systemd-resolved se interpone, ysudo ss -lunp 'sport = :53'nombra el proceso que escucha en el puerto 53:unbound,named,kresd,dnsmasqopihole-FTL. Ese es el proceso que va a examinar.Consultar la raíz con dig +dnssec
Ejecute
dig +dnssec . SOA @127.0.0.1y despuésdig +dnssec com. SOA @127.0.0.1. Fíjese en dos campos de la cabecera:status:yflags:. Unstatus: NOERRORcon la banderaadsignifica que la respuesta se ha validado. Unstatus: SERVFAILen la propia raíz es la señal más clara de un ancla obsoleta.Aislar la validación con +cd
dig +dnssec +cd com. SOA @127.0.0.1pide al resolver que responda sin validar (checking disabled). Si esta consulta devuelveNOERRORmientras la anterior falla conSERVFAIL, la red y los servidores superiores funcionan: lo que bloquea es la validación DNSSEC, es decir, el ancla o el reloj.Comparar con un resolver público validador
dig +dnssec com. SOA @9.9.9.9debe responderNOERRORconad. Si el resolver público valida y el suyo no, el problema es local. Compruebe de paso la hora del servidor contimedatectl: un reloj desfasado también hace fallar la verificación de las firmas y produce el mismo SERVFAIL.Ver qué clave firma la raíz
dig +dnssec +multi . DNSKEY @9.9.9.9muestra las claves publicadas. Las de flag257son las KSK; con+multi, dig añade sukey idcomo comentario. En la fase actual, KSK-2017 sigue publicada, pero la firma (RRSIG) del conjunto de claves lleva el key tag 38696: esa es la clave que su ancla debe conocer.Leer el ancla realmente cargada
Unbound:
sudo grep 'id = 38696' /var/lib/unbound/root.key(ruta de Debian; en otros sistemas,unbound-checkconf -o auto-trust-anchor-fileda la suya) debe devolver una línea marcadaVALID. BIND:sudo rndc secroots -debe listar./RSASHA256/38696 ; managed, ysudo rndc managed-keys statusuna entradakeyid: 38696seguida detrusted since. Knot Resolver: llame atrust_anchors.summary()desde su consola de control. dnsmasq: busque una líneatrust-anchor=.,38696,8,2,…en la configuración cargada.Confirmar con delv
delv @127.0.0.1 com. SOAvalida la respuesta por sí mismo y muestra; fully validatedcuando la cadena está completa. Atención: delv usa el ancla compilada en su propio binario, no la de su resolver. Un delv antiguo puede, por tanto, fallar por su cuenta: actualice el paquete antes de sacar conclusiones sobre el resolver.
Dónde vive el ancla de confianza, resolver por resolver
Desplace la tabla
| Resolver | Dónde mirar | Actualización de la clave |
|---|---|---|
| Unbound | Directiva `auto-trust-anchor-file` (Debian: `/var/lib/unbound/root.key`) | RFC 5011 si el archivo y su directorio admiten escritura; si no, `unbound-anchor` |
| BIND | `rndc secroots -` y `managed-keys.bind`; ancla integrada con `dnssec-validation auto` | RFC 5011 con `auto`, `initial-key` o `initial-ds`; ninguna con `static-key` |
| Knot Resolver | `trust_anchors.add_file()` en v5, `dnssec/trust-anchors-files` en v6 | RFC 5011, salvo si el archivo se declara de solo lectura |
| systemd-resolved | Ancla integrada en el binario; archivos `*.positive` de `/etc/dnssec-trust-anchors.d/` | Ninguna por DNS: hace falta un paquete systemd actualizado |
| dnsmasq | Líneas `trust-anchor=` de la configuración cargada | Ninguna: línea estática que se edita a mano |
| Pi-hole v6 | `/etc/pihole/dnsmasq.conf`, generado por FTL | Reescrito por FTL, que inscribe las claves 20326 y 38696 |
| delv (herramienta) | Ancla compilada en el binario | Actualización del paquete que lo proporciona |
Corregir según su resolver
Unbound: refrescar el ancla
Actualice primero el sistema (
sudo apt update && sudo apt upgrade). En Debian, el paquetedns-root-dataproporciona/usr/share/dns/root.key, y el script de arranque de Unbound copia ese archivo a/var/lib/unbound/root.keycuando es más reciente; la versión2024071801~deb12u1publicada para Debian 12 ya contiene KSK-2024. Después fuerce la comprobación consudo -u unbound unbound-anchor -a /var/lib/unbound/root.key -vysudo systemctl restart unbound. La clave integrada enunbound-anchorincluye KSK-2024 desde Unbound 1.21.0.Unbound: hacer posible el RFC 5011
Si la clave sigue faltando, compruebe que el usuario
unboundpuede escribir el archivo Y su directorio: la documentación lo exige para crear un archivo temporal.ls -ld /var/lib/unbound /var/lib/unbound/root.keybasta para verlo. Un archivo montado en solo lectura en un contenedor bloquea la actualización automática sin ningún error visible para el cliente.BIND: auto o ancla declarada
Con
dnssec-validation auto;, BIND parte del ancla incluida en el software y la mantiene al día mediante el RFC 5011 enmanaged-keys.bind. Actualice el paquete, compruebe quenamedpuede escribir enmanaged-keys-directoryy ejecutesudo rndc managed-keys refresh. Condnssec-validation yes;y un ancla declarada a mano, añada al bloquetrust-anchorsla línea. initial-ds 38696 8 2 "683D2D0ACB8C9B712A1948B27F741219298D0A450D612C483AF444A4C0FB2B16";y retire cualquier anclastatic-keyque solo conozca 20326.Knot Resolver: revisar el archivo de ancla
Actualice el paquete y mire cómo se declara el archivo de ancla. Si es de solo lectura (segundo argumento
truedetrust_anchors.add_file()en v5,read-only: trueen v6), el resolver nunca lo modifica: es el paquete de su distribución el que debe aportar la clave. Si no, compruebe quekresdpuede escribir el archivo. La documentación indica que, si el archivo no existe, el resolver intenta inicializar por sí mismo el ancla de la raíz.systemd-resolved: actualizar systemd
systemd-resolved no actualiza su ancla por DNS: solo una actualización del paquete aporta la nueva clave. El código original la integra, en particular desde systemd 256.12 y 257.4, y el paquete
systemd-resolvedactual de Debian 12 también la contiene. Revise/etc/dnssec-trust-anchors.d/: un archivo*.positiveque declara una clave raíz desactiva el ancla integrada. Elimínelo o añádale la clave 38696, y después ejecutesudo systemctl restart systemd-resolvedyresolvectl flush-caches.dnsmasq: añadir la línea estática
dnsmasq no aplica el RFC 5011: el ancla es una línea fija. Añada
trust-anchor=.,38696,8,2,683D2D0ACB8C9B712A1948B27F741219298D0A450D612C483AF444A4C0FB2B16junto a la línea 20326 y reinicie el servicio. En Debian 12, el archivo/usr/share/dnsmasq-base/trust-anchors.confdel paquetednsmasq-base2.90-4~deb12u2 solo contiene la clave 20326, mientras que el de Debian 13 contiene las dos: compruebe qué archivo carga realmente su configuración. Pi-hole v6 escribe él mismo las dos líneas en/etc/pihole/dnsmasq.confcuando la validación DNSSEC está activada.Automatizar para la próxima vez
Un ancla solo caduca en un servidor que ha dejado de actualizarse. Active las actualizaciones automáticas de seguridad de los paquetes de resolver (consulte actualizaciones automáticas en Debian y Ubuntu) y añada a su supervisión una sonda
dig +dnssec com. SOA @127.0.0.1que alerte ante unSERVFAIL. Si su DNS local pasa por Pi-hole, la guía Pi-hole v6 en un VPS muestra cómo colocar Unbound por encima.
Después de la corrección: qué vigilar
Una vez que la bandera ad vuelve a las respuestas, tres puntos merecen una comprobación.
Primero, las imágenes y las instantáneas. Una máquina restaurada desde una copia de seguridad antigua arranca con el archivo de ancla de entonces. Si ese archivo solo conoce 20326, el RFC 5011 ya no puede ponerlo al día: solo acepta una nueva clave si el conjunto de claves está firmado por una clave ya aprobada, y la raíz ya no está firmada por 20326. Hay que refrescar el ancla a mano, como se indica más arriba.
Después, las imágenes de contenedores. Una imagen construida con un ancla estática la conserva en cada redespliegue: reconstrúyala a partir de una base actualizada.
Por último, la revocación. El 11 de enero de 2027 está previsto publicar KSK-2017 con el bit de revocación. Un resolver que sigue el RFC 5011 la marcará como revocada: en el archivo de Unbound, la línea 20326 pasará al estado REVOKED. Es el estado esperado, no una avería.
No desactive la validación para silenciar el error
Pasar a dnssec-validation no, val-permissive-mode: yes o DNSSEC=no hace desaparecer el SERVFAIL, pero también elimina toda protección contra respuestas falsificadas. Corrija el ancla y después pruebe. No pegue nunca una clave encontrada en un foro: la fuente de referencia es https://data.iana.org/root-anchors/root-anchors.xml, cuya firma se verifica con root-anchors.p7s e icannbundle.pem, publicados en el mismo lugar por IANA. El resumen SHA-256 de KSK-2024 figura allí: 683D2D0ACB8C9B712A1948B27F741219298D0A450D612C483AF444A4C0FB2B16.
Solución de problemas: los mensajes que verá
Los mensajes siguientes proceden del código fuente o de la documentación de los programas afectados. Permiten distinguir un ancla obsoleta de un problema de red, de un reloj desfasado o de una herramienta de diagnóstico demasiado antigua. En Unbound, aumente primero el detalle de los registros con val-log-level: 2 en la sección server: y reinicie: cada consulta rechazada quedará registrada con su motivo y el servidor que proporcionó el dato erróneo.
Mensajes de error y soluciones
failed to prime trust anchor -- DNSKEY rrset is not secure(registro de Unbound, seguido de. DNSKEY IN) — Unbound obtuvo las claves de la raíz pero no pudo validarlas con su ancla: ancla obsoleta o reloj incorrecto. Refresqueroot.key.failed to prime trust anchor -- could not fetch DNSKEY rrset— Unbound ni siquiera obtiene las claves de la raíz: red, cortafuegos o fragmentación UDP, no el ancla. Pruebedig +dnssec . DNSKEYcontra el servidor superior.status: SERVFAILcon+dnssec,NOERRORcon+cd— la firma de un fallo de validación. Conede: yesen Unbound, el cliente recibe además un código de error extendido (RFC 8914).resolution failed: broken trust chainono valid RRSIG(delv) — delv no pudo remontar hasta un ancla válida. Compruebe primero que delv está actualizado.; initializing managedenrndc secroots -— BIND conoce la clave pero nunca la confirmó con una consulta de actualización. Ejecuterndc managed-keys refreshy revise los permisos demanaged-keys-directory.unbound-anchortermina con el código 0 sin cambiar nada — según su página de manual, 0 significa tanto «no hacía falta actualizar» como «error». Vuelva a ejecutarlo con-vy relea el archivo.
En resumen
El cambio de clave de la raíz no exige nada a los propietarios de dominios, ni a los servidores cuyos paquetes siguen las actualizaciones. Penaliza a los resolvers congelados: una imagen antigua, un archivo de ancla sin permiso de escritura, un ancla estática en dnsmasq o BIND. Tres acciones bastan para decidir: dig +dnssec com. SOA contra su resolver, la misma consulta con +cd y la lectura del ancla cargada. Tenga presente la fecha del 11 de enero de 2027: la revocación de KSK-2017 aparecerá en sus archivos de ancla, y es un estado esperado. En un servidor con acceso root, esta comprobación lleva diez minutos y se programa de una vez por todas en su supervisión.
