Entiende la cadena de confianza DNSSEC en 5 minutos
Por CaptainDNS
Publicado el 22 de febrero de 2026
Actualizado el 12 de octubre de 2026
- La cadena de confianza DNSSEC conecta la raíz DNS con tu dominio mediante firmas criptográficas anidadas
- Tres tipos de registros aseguran la validación: DNSKEY (claves públicas), RRSIG (firmas) y DS (enlace con la zona padre)
- Cada eslabón verifica al siguiente: la raíz firma el TLD, el TLD firma tu dominio
- Desde el 11 de octubre de 2026, la KSK 38696 firma la raíz DNS: un resolvedor autogestionado que no la tenga entre sus anclas puede devolver SERVFAIL
- Comprueba que tu cadena esté intacta con nuestro DNSSEC Checker (ver plan de acción al final)
DNSSEC no funciona como un certificado TLS que instalas en un servidor. Es un sistema distribuido. La confianza se propaga desde la raíz DNS hasta tu dominio, eslabón por eslabón. Si un solo eslabón se rompe, toda la cadena se desmorona y tus visitantes reciben un error SERVFAIL.
Entender esta cadena es esencial para activar DNSSEC correctamente, diagnosticar errores y evitar interrupciones del servicio. Esta guía te explica cada componente en 5 minutos, con esquemas y ejemplos concretos.
¿Por qué el DNS necesita una cadena de confianza?
El DNS fue diseñado en 1983 (RFC 1034) como un directorio distribuido. Ningún mecanismo permitía verificar que una respuesta provenía del servidor legítimo. Un atacante podía inyectar una respuesta falsa (DNS spoofing) y redirigir el tráfico hacia un servidor malicioso.
DNSSEC (RFC 4033) resuelve este problema añadiendo firmas criptográficas. Pero una firma sola no basta: hace falta un medio para verificar que la clave de firma es legítima. Ese es el papel de la cadena de confianza.
El principio es simple: cada nivel de la jerarquía DNS garantiza la autenticidad del nivel siguiente.
Los tres niveles de la jerarquía DNS
La resolución DNS sigue una estructura de árbol con tres niveles. DNSSEC aprovecha esta jerarquía para construir la cadena de confianza.
Nivel 1: la raíz DNS (root)
La raíz DNS es el punto de partida de toda resolución. Está gestionada por la IANA (Internet Assigned Numbers Authority) y distribuida en 13 clústeres de servidores raíz. La raíz firma los registros DS de cada TLD.
El ancla de confianza (trust anchor) de la raíz se basa en su KSK. El resolvedor validante la conserva en su configuración y debe mantenerla actualizada cuando cambian las claves. Es el punto de partida de la cadena, no una clave integrada de una vez para siempre.
Nivel 2: el TLD (.com, .fr, .org)
El TLD recibe su legitimidad de la raíz a través de un DS record. El registro del TLD (Verisign para .com, AFNIC para .fr) gestiona la firma de su zona. A su vez, el TLD firma los DS records de cada dominio registrado.
Nivel 3: tu dominio (captaindns.com)
Tu dominio es el último eslabón. Tu proveedor DNS firma los registros de tu zona (A, MX, TXT, etc.) y publica las claves públicas. El DS record publicado en el TLD conecta tu zona con la zona padre.
Las claves criptográficas: ZSK y KSK
Cada zona DNSSEC utiliza dos pares de claves. Su separación permite una rotación independiente y limita el impacto de una vulneración.
ZSK (Zone Signing Key)
La ZSK firma los registros DNS de tu zona. Cada tipo de registro (A, MX, TXT, AAAA) recibe su propia firma RRSIG.
- Tamaño típico: 1024-2048 bits (RSA) o 256 bits (ECDSA P-256)
- Rotación: cada 1 a 3 meses
- Publicada en: el registro DNSKEY de tu zona (flag 256)
La rotación frecuente de la ZSK limita los riesgos. Si la clave se ve comprometida, la exposición queda limitada en el tiempo. La rotación de la ZSK no requiere actualizar el DS record en el TLD.
KSK (Key Signing Key)
La KSK de tu dominio firma únicamente el conjunto de DNSKEY (incluida la ZSK). Su hash se publica en el DS record a nivel del TLD. Es el puente entre tu zona y la zona padre.
- Tamaño típico: 2048-4096 bits (RSA) o 384 bits (ECDSA P-384)
- Rotación: cada 1 a 2 años
- Publicada en: el registro DNSKEY de tu zona (flag 257)
La rotación de la KSK de tu dominio es más delicada: requiere actualizar el DS record en el registrar. Una mala coordinación rompe la cadena de confianza.
Los registros DNSSEC explicados
Cuatro tipos de registros DNS aseguran el funcionamiento de la cadena.
DNSKEY: las claves públicas
El registro DNSKEY contiene la clave pública utilizada para verificar las firmas. Tu zona publica como mínimo dos DNSKEY: una para la ZSK (flag 256) y otra para la KSK (flag 257).
dig DNSKEY captaindns.com +short
El resolvedor utiliza estas claves para verificar las firmas RRSIG de los registros de tu zona.
RRSIG: las firmas
Cada registro DNS firmado posee un RRSIG correspondiente. El RRSIG contiene la firma criptográfica, el algoritmo utilizado, el período de validez y el Key Tag de la clave que firmó.
dig A captaindns.com +dnssec
El resolvedor verifica que la firma RRSIG corresponda al registro devuelto y que la clave (DNSKEY) sea válida.
DS: el enlace con la zona padre
El DS record (Delegation Signer) se publica en la zona padre (el TLD). Contiene un hash de la KSK de tu zona. El resolvedor compara este hash con la KSK publicada en tu DNSKEY para confirmar la legitimidad de tus claves.
dig DS captaindns.com +short
El DS record es el eslabón crítico entre dos niveles de la jerarquía. Sin DS record, la cadena se rompe y DNSSEC aparece como INSECURE.
NSEC/NSEC3: la prueba de inexistencia
NSEC y NSEC3 demuestran que un registro solicitado no existe, de forma autenticada. Sin estos registros, un atacante podría forjar respuestas "dominio inexistente" (NXDOMAIN) para desviar el tráfico.
NSEC3 (RFC 5155) añade un hash de los nombres para evitar la enumeración de zona (zone walking).
¿Cómo valida el resolvedor una respuesta?
Este es el proceso completo de validación cuando un resolvedor recibe una consulta para captaindns.com.
Paso 1: obtener el ancla de confianza
El resolvedor parte de un ancla de confianza raíz configurada localmente. Esta confianza inicial no procede de una zona padre; el ancla debe mantenerse actualizada, en particular mediante RFC 5011 cuando este mecanismo es compatible con el resolvedor y funciona.
Actualización del 12 de octubre de 2026: el rollover de la KSK raíz tuvo lugar el 11 de octubre. La sección sobre el rollover de la raíz, más abajo, explica qué cambia para un resolvedor autogestionado.
Paso 2: validar de la raíz al TLD
- El resolvedor solicita el DS record de
.coma la raíz - La raíz devuelve el DS record y su firma RRSIG
- El resolvedor valida el conjunto DNSKEY de la raíz con la KSK raíz y después la firma del DS con la ZSK autenticada de este modo
- El DS record de
.comqueda ahora validado
Paso 3: validar del TLD a tu dominio
- El resolvedor solicita el DS record de
captaindns.comal TLD.com - El TLD devuelve el DS record y su firma RRSIG
- El resolvedor verifica la firma con la DNSKEY del TLD (validada en el paso 2)
- El DS record de
captaindns.comqueda ahora validado
Paso 4: validar tu zona
- El resolvedor solicita el DNSKEY de
captaindns.com - Compara el hash de la KSK con el DS record validado en el paso 3
- Si el hash coincide, las DNSKEY son legítimas
- El resolvedor solicita el registro A y verifica su RRSIG con la ZSK
Si todos los pasos son exitosos, la respuesta se marca como SECURE (flag ad en la respuesta DNS). Si un paso falla, la respuesta es BOGUS y el resolvedor devuelve SERVFAIL.
Rollover de la KSK raíz: situación al 12 de octubre de 2026
Desde el 11 de octubre de 2026, KSK-2024 (key tag 38696) firma el conjunto DNSKEY de la zona raíz en lugar de KSK-2017 (20326): es la única KSK que lo firma. Comprobado el 12 de octubre de 2026: en k.root-servers.net y a.root-servers.net, el conjunto DNSKEY raíz está firmado por 38696, y la IANA indica para KSK-2024 el estado Active, «Signing since 2026-10-11». Este rollover no cambia el algoritmo. Los DS de los TLD siguen firmados por la ZSK.
Publicada el 11 de enero de 2025, la nueva clave debía reconocerse como ancla mediante RFC 5011 ya desde el 10 de febrero de 2025. Este calendario no demuestra que la actualización se haya completado correctamente en tu resolvedor.
La antigua clave 20326 sigue publicada en la zona raíz. Al 12 de octubre de 2026, la IANA le asigna el estado Post-Publication e indica que sigue siendo un ancla de confianza válida: no la retires tú mismo de tu resolvedor. Para su retirada, consulta el calendario actualizado de la IANA.
La recomendación de ICANN es comprobar, sin darlo por hecho, que 38696 sea un ancla de confianza utilizable localmente. Ver esta clave en una respuesta DNS no basta.
Un resolvedor autogestionado que no tenga 38696 entre sus anclas ya no valida el conjunto DNSKEY raíz. Los SERVFAIL aparecen en dominios que funcionan correctamente a medida que expira el conjunto DNSKEY raíz en caché (TTL de 2 días). Si una consulta devuelve SERVFAIL en ese resolvedor pero obtiene una respuesta normal con dig +cd (validación desactivada solo para esta prueba), lo que falla es la validación: comprueba el ancla 38696 antes de tocar la zona o el registrar. Con 1.1.1.1, 8.8.8.8 o 9.9.9.9, no tienes nada que hacer en sus anclas.
¿Cuándo se rompe la cadena?
Una ruptura puede proceder de la zona o del resolvedor que la valida. Estos son cuatro escenarios.
DS record ausente o incorrecto
El DS record en el TLD no corresponde a la KSK publicada en tu zona. Causas:
- El DS record nunca se añadió en el registrar (la zona está firmada pero la cadena no está establecida)
- La KSK se renovó sin actualizar el DS record
- Un error en los valores del DS record (Key Tag, Algorithm, Digest)
Resultado: INSECURE si no hay DS record. BOGUS si el DS record existe pero no coincide.
Firmas RRSIG expiradas
Cada firma RRSIG tiene un período de validez. Si las firmas no se renuevan antes de expirar, el resolvedor las rechaza.
Resultado: BOGUS en todos los registros cuya firma haya expirado.
Prevención: los proveedores DNS gestionados (Cloudflare, Route 53, OVHcloud) renuevan las firmas automáticamente. El riesgo existe sobre todo con BIND o PowerDNS autogestionados.
Algoritmos incompatibles
Si el DS record especifica un algoritmo diferente al utilizado por la DNSKEY, la validación falla.
Resultado: BOGUS.
Ancla raíz desactualizada en el resolvedor
Desde el rollover del 11 de octubre de 2026, un resolvedor autogestionado que no confíe en 38696 puede devolver SERVFAIL para numerosos dominios que funcionan correctamente. El fallo está en el ancla raíz de ese resolvedor, no en el DS de tu dominio. Comprueba esta ancla antes de modificar la zona o la configuración en el registrar.
Verificar tu cadena de confianza
Para confirmar que tu cadena está intacta, usa el siguiente comando:
dig captaindns.com +dnssec +short
El flag ad (Authenticated Data) en la respuesta confirma que la cadena completa está validada:
dig captaindns.com +dnssec | grep flags
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2
Para un análisis completo de cada eslabón, utiliza nuestra herramienta DNS Lookup que detalla los registros DNSKEY, DS y RRSIG.
Plan de acción recomendado
- Comprende tu configuración: identifica quién gestiona la firma de zona (proveedor DNS) y quién gestiona el DS record (registrar)
- Verifica la cadena: confirma que el DS record en el TLD corresponde a tu KSK con
dig DS captaindns.com +short - Monitoriza las expiraciones: vigila la validez de las firmas RRSIG y planifica las rotaciones de claves
- Documenta el procedimiento: anota los pasos de rotación KSK para tu registrar específico
- Prueba tras cada cambio: verifica la propagación DNS tras cualquier modificación DNSSEC
- Resolvedor autogestionado: comprueba que 38696 sea efectivamente un ancla de confianza de tu resolvedor; si una consulta devuelve SERVFAIL en ese resolvedor pero una respuesta normal con
dig +cd, lo que falla es la validación; si solo utilizas 1.1.1.1, 8.8.8.8 o 9.9.9.9, no tienes que intervenir en sus anclas
Lanza un diagnóstico DNSSEC completo de tu dominio para verificar sus DS, DNSKEY y RRSIG. El DNSSEC Checker no comprueba el ancla local de tu resolvedor.
Guías de DNSSEC relacionadas
- Activar DNSSEC: guía paso a paso por registrar
- DANE/TLSA: la guía completa para autenticar certificados de correo electrónico mediante DNS
- SERVFAIL tras activar DNSSEC: diagnóstico y corrección
FAQ
¿Qué es la cadena de confianza DNSSEC?
La cadena de confianza DNSSEC es el mecanismo por el cual cada nivel de la jerarquía DNS (raíz, TLD, dominio) garantiza la autenticidad del nivel siguiente mediante firmas criptográficas. El resolvedor recorre esta cadena desde el ancla de confianza (KSK raíz) hasta tu dominio.
¿Qué es un trust anchor?
Un trust anchor (ancla de confianza) es una clave o una referencia a una clave que el resolvedor considera fiable para iniciar la validación. Para la raíz DNS, se basa en la KSK raíz y debe mantenerse actualizada, especialmente durante un rollover. RFC 5011 contempla esta actualización automática, cuyo funcionamiento debe comprobarse.
¿Mi resolvedor autogestionado se ve afectado por el rollover de la KSK raíz?
Sí, si valida DNSSEC. Desde el 11 de octubre de 2026, la KSK 38696 firma el conjunto DNSKEY raíz: un resolvedor autogestionado que no la tenga entre sus anclas puede devolver SERVFAIL en dominios que funcionan correctamente. Comprueba que 38696 se reconozca como ancla de confianza, sin dar por hecho que RFC 5011 haya funcionado. Con 1.1.1.1, 8.8.8.8 o 9.9.9.9, no tienes que intervenir en sus anclas.
¿Cuál es la diferencia entre ZSK y KSK?
La ZSK (Zone Signing Key) firma los registros DNS de tu zona (A, MX, TXT). La KSK (Key Signing Key) firma únicamente las DNSKEY. Su separación permite renovar la ZSK frecuentemente sin tocar el DS record del registrar.
¿Qué ocurre si la cadena de confianza se rompe?
Si un eslabón de la cadena es inválido (DS incorrecto, firma expirada, clave incompatible), el resolvedor marca la respuesta como BOGUS y devuelve SERVFAIL al cliente. Tus visitantes no podrán acceder a tu sitio hasta que se corrija el problema.
¿Cómo funciona DNSSEC?
DNSSEC añade firmas criptográficas a cada registro DNS. Tu proveedor DNS firma los registros con una clave privada (ZSK). El resolvedor verifica las firmas con la clave pública (DNSKEY). La legitimidad de las claves está garantizada por un DS record publicado en el TLD, formando una cadena de confianza hasta la raíz.
¿Cómo verificar que DNSSEC funciona en mi dominio?
Ejecuta dig captaindns.com +dnssec | grep flags. Si el flag ad (Authenticated Data) está presente, la cadena de confianza está validada. También puedes usar una herramienta en línea que verifique el DS record, las DNSKEY y las firmas RRSIG.
¿Por qué la rotación de la KSK es arriesgada?
La rotación de la KSK de tu dominio requiere actualizar el DS record en el registrar. Durante la transición, los dos DS records (antiguo y nuevo) deben coexistir. Una mala coordinación (DS antiguo eliminado antes de la propagación del nuevo) rompe la cadena y provoca SERVFAIL.
¿DNSSEC funciona con todos los resolvedores?
No. Solo los resolvedores validantes verifican las firmas DNSSEC. Los principales resolvedores públicos (Cloudflare 1.1.1.1, Google 8.8.8.8, Quad9 9.9.9.9) validan DNSSEC. Algunos resolvedores de operadores no lo hacen. Según APNIC, alrededor del 38 % de las consultas DNS mundiales se validan con DNSSEC en 2026.
Glosario
- Trust anchor (ancla de confianza): clave o referencia a una clave reconocida como fiable para iniciar la validación DNSSEC; el ancla raíz debe mantenerse actualizada cuando cambia la KSK.
- DS record (Delegation Signer): registro publicado en la zona padre que contiene un hash de la KSK. Enlace entre dos niveles de la jerarquía.
- DNSKEY: registro que contiene la clave pública de firma. Flag 256 para la ZSK, flag 257 para la KSK.
- RRSIG: firma criptográfica de un registro DNS. Contiene el algoritmo, el período de validez y el Key Tag.
- NSEC/NSEC3: registros de prueba de inexistencia autenticada. NSEC3 añade un hash para evitar la enumeración de zona.
- BOGUS: estado de una respuesta DNS cuya validación DNSSEC ha fallado. El resolvedor devuelve SERVFAIL.
