Cómo funciona DNSSEC — KSK, ZSK, DS, DNSKEY, RRSIG, NSEC explicados

DNSSEC autentica datos DNS mediante una jerarquía de firmas criptográficas que se encadenan desde un registro de su zona hasta un ancla de confianza codificada en cada resolutor validador. Esta guía recorre las piezas móviles — DNSKEY, DS, RRSIG, NSEC/NSEC3, y los roles KSK/ZSK — a un nivel que le permita razonar sobre despliegues reales sin ser criptógrafo.

Para los procedimientos operativos de rotación (pre-publish ZSK, doble-firma KSK, rotación de algoritmo), continúe en Gestión de claves DNSSEC. Para la introducción de alto nivel sin la mecánica, la página ¿Qué es DNSSEC? es un mejor punto de partida.

Los registros involucrados

DNSSEC introduce cuatro tipos de registros en una zona firmada, más registros DS publicados en la zona padre:

Claves de firma: KSK, ZSK, CSK

DNSSEC ha usado históricamente una división de dos claves: una KSK para operaciones de alto valor y baja frecuencia, y una ZSK para operaciones de alta frecuencia y menor ceremonia. La motivación es puramente operativa — criptográficamente, ambas claves hacen lo mismo (firmar datos con una clave privada, verificar con una pública).

Zone-Signing-Key (ZSK)

La ZSK firma todo en su zona excepto el conjunto de registros DNSKEY. Cuando un resolutor pide los registros A de example.com, la respuesta vuelve con un RRSIG correspondiente firmado por la ZSK. Cada conjunto de registros firmado tiene su propio RRSIG.

Las ZSK típicamente son:

• Más pequeñas (RSA 1024 bits era común en despliegues iniciales; ECDSA P-256 / 256 bits es la norma moderna)
• Rotadas relativamente a menudo (cada 1–3 meses históricamente; algunos operadores ahora omiten rotaciones programadas con almacenamiento de claves fuerte)
• Más fáciles de rotar porque el registro DS de la zona padre no necesita cambiar

Key-Signing-Key (KSK)

La KSK firma solo el conjunto de registros DNSKEY. Ese conjunto contiene la parte pública de cada clave de firma activa en la zona. Al firmar el conjunto DNSKEY con la KSK, vincula cada otra clave en la zona (específicamente, cada ZSK activa) a una clave cuyo hash está publicado en el padre.

Las KSK típicamente son:

• Más grandes (RSA 2048 bits, ECDSA P-256 o Ed25519 son todos comunes)
• Rotadas raramente (cada 1–5 años, o solo ante sospecha de compromiso)
• Más costosas de rotar porque el registro DS en el padre debe actualizarse, lo que involucra al registrador y los tiempos del TLD

Combined Signing Key (CSK)

Una CSK cumple ambos roles en una única clave. La misma clave firma DNSKEY (rol KSK) y otros conjuntos de registros (rol ZSK). Los despliegues modernos usan cada vez más CSK con ECDSA P-256 o Ed25519, porque:

• Las firmas son lo bastante pequeñas para que el coste por consulta sea negligible
• La complejidad operativa es menor (una clave que gestionar, una rotación que coordinar)
• El almacenamiento respaldado por HSM reduce el argumento de seguridad para separar KSK y ZSK

DNScale usa por defecto CSK con ECDSA P-256 para nuevas zonas, que es el estándar para la mayoría de proveedores gestionados modernos.

DNSKEY: Publicar claves públicas en la zona

Cada clave de firma activa tiene su parte pública publicada como registro DNSKEY en el ápice de la zona:

example.com.   3600   IN   DNSKEY   257 3 13 oJMR...                        ; KSK
example.com.   3600   IN   DNSKEY   256 3 13 mZXp...                        ; ZSK

Decodificando los campos:

• Banderas (257 o 256): el bit 7 (SEP — Secure Entry Point) está activado en la KSK, dando 257. La ZSK tiene 256. Ambos formatos comparten el bit 8 (Zone Key), que siempre está activo en DNSKEY.
• Protocolo (3): siempre 3 en DNSSEC válido.
• Algoritmo (13 aquí): 13 = ECDSA P-256, 8 = RSA SHA-256, 15 = Ed25519. Ver algoritmos DNSSEC IANA para la lista completa.
• Clave pública (codificada en base64): el material de clave real.

Un resolutor validador recupera el conjunto DNSKEY al validar cualquier registro de su zona, y usa la clave apropiada (KSK para el RRSIG del DNSKEY mismo, ZSK para todo lo demás).

RRSIG: Las firmas

Cada conjunto de registros firmado en su zona se acompaña de uno o más registros RRSIG — uno por clave de firma activa para ese rol. Un RRSIG se ve así:

example.com.   3600   IN   A      192.0.2.1
example.com.   3600   IN   RRSIG  A 13 2 3600 20260601000000 20260501000000 12345 example.com. 4kQp...

Los campos RRSIG:

• Tipo cubierto (A): el tipo del conjunto de registros que se firma.
• Algoritmo (13): debe coincidir con el algoritmo DNSKEY.
• Etiquetas (2): número de etiquetas en el nombre firmado original.
• TTL original (3600): el TTL que el conjunto tenía cuando se firmó.
• Expiración de firma (20260601000000) e inicio (20260501000000): timestamps UTC. La firma solo es válida en esa ventana.
• Etiqueta de clave (12345): identificador corto de qué DNSKEY de la zona produjo esta firma. Coincide con la etiqueta de clave del DNSKEY correspondiente.
• Nombre del firmante (example.com.): la zona cuya clave firmó esto.
• Firma (codificada en base64): la firma criptográfica real.

Las ventanas de expiración de firmas son la razón por la que DNSSEC no es trivial operativamente. Si su servidor autoritativo deja de re-firmar la zona — incluso brevemente —, las firmas empezarán a expirar, los resolutores validadores empezarán a devolver SERVFAIL, y su dominio quedará efectivamente fuera de línea. Los proveedores DNS gestionados re-firman automáticamente; el DNSSEC autoalojado requiere un pipeline de firma funcional.

Registros DS: El enlace al padre

El registro DS (Delegation Signer) es la bisagra que conecta su zona a la cadena de confianza global. Vive en la zona padre (.com, .eu, .de, etc.) y contiene un hash de su KSK. No lo añade a su propia zona — lo publica en su registrador, que lo pasa al registro del TLD.

Un registro DS en la zona padre se ve así:

example.com.   86400   IN   DS   12345 13 2 7c89...

Campos:

• Etiqueta de clave (12345): identificador de qué KSK hashea este DS (coincide con la etiqueta de clave DNSKEY).
• Algoritmo (13): debe coincidir con el algoritmo DNSKEY.
• Tipo de digest (2): SHA-256 (2) o SHA-384 (4) — SHA-1 (1) está obsoleto.
• Digest (codificado en hex): el hash real.

Cuando un resolutor validador quiere autenticar su zona, recupera el registro DS desde el padre (por ejemplo, desde los servidores .com), luego recupera su conjunto DNSKEY, calcula el hash de la KSK correspondiente, y comprueba que iguala el digest del DS. Si coinciden, el resolutor confía en el conjunto DNSKEY de su zona, y por extensión en los RRSIGs firmados con esas claves.

Este es el único enlace automatizado desde fuera de su zona hacia el material de clave de su zona. Si el DS está mal, la validación DNSSEC falla — o peor, su dominio se vuelve irresoluble para clientes validadores.

NSEC y NSEC3: Negación autenticada

Un problema sutil pero importante: DNSSEC no puede solo firmar los registros que existen. También necesita demostrar, cuando un resolutor pide nonexistent.example.com, que el nombre realmente no existe en lugar de que la respuesta se descarte silenciosamente o se falsifique.

El mecanismo es NSEC (RFC 4034) o NSEC3 (RFC 5155).

NSEC

Los registros NSEC se ordenan alfabéticamente y encadenan los nombres que existen en la zona. Por ejemplo:

alpha.example.com.    NSEC  gamma.example.com.   A NSEC RRSIG
gamma.example.com.    NSEC  zulu.example.com.    A NSEC RRSIG
zulu.example.com.     NSEC  alpha.example.com.   A NSEC RRSIG     ; vuelve al inicio

Un resolutor que pida beta.example.com recibe el NSEC firmado para alpha.example.com, que demuestra que no hay nada entre alpha y gamma — por tanto beta no existe. La firma sobre el NSEC autentica la respuesta negativa.

La desventaja: los registros NSEC enumeran públicamente cada nombre en la zona. Cualquiera que recorra la cadena NSEC puede construir una lista completa de cada nombre de registro. Esto es "zone walking" y a veces se considera una fuga de privacidad.

NSEC3

NSEC3 registra la misma cadena pero usa nombres hasheados en lugar de nombres en claro, más una cuenta de iteraciones y un salt:

< hash de alpha >.example.com.    NSEC3 1 0 10 abcd123...    < hash de gamma > A RRSIG NSEC3

Los resolutores pueden verificar la negación como antes (calcular el hash del nombre consultado, encontrar qué NSEC3 lo cubre), pero un atacante no puede recorrer trivialmente la zona — tendría que romper cada hash. NSEC3 también soporta opt-out, que permite a los registros saltarse la firma de delegaciones no firmadas para evitar tener que firmar cada subzona inexistente.

Recomendación moderna: NSEC3 con iteraciones=0 y un salt fijo (o sin salt). Cuentas de iteraciones altas añaden coste de CPU sin beneficio significativo de privacidad porque atacantes con GPUs pueden romper cualquier cuenta no-cero. El enfoque "white lies" (RFC 4470) es otra forma de reducir el riesgo de zone walking manteniendo la simplicidad de NSEC.

El flujo de validación — Paso a paso

¿Qué pasa realmente cuando un resolutor validador recibe una respuesta firmada con DNSSEC? Recorriendo dig +dnssec example.com @1.1.1.1:

1. El resolutor recibe el registro A + RRSIG de su servidor autoritativo.
2. El resolutor recupera el conjunto DNSKEY de su zona + RRSIG. Ahora tiene tanto los datos como las claves (en forma pública) necesarias para verificar todo.
3. El resolutor verifica el RRSIG de datos contra la ZSK en el conjunto DNSKEY. Si la firma es inválida, la validación falla inmediatamente.
4. El resolutor verifica el RRSIG del DNSKEY contra la KSK en el conjunto DNSKEY. La KSK ha firmado el conjunto DNSKEY, incluyendo la ZSK. Este paso vincula la ZSK a la KSK.
5. El resolutor recupera el registro DS de la zona padre (por ejemplo, desde los servidores .com). El DS contiene un hash de la KSK.
6. El resolutor calcula el hash de la KSK y lo compara con el DS. Si coinciden, el padre ha confirmado qué KSK es autoritativa para su zona.
7. El resolutor repite la cadena en el padre. El registro DS mismo está firmado por la ZSK de la zona padre; el conjunto DNSKEY del padre está firmado por la KSK del padre; la KSK del padre se hashea en el DS de la zona abuela, y así sucesivamente, hasta la raíz.
8. En la raíz, el resolutor compara el hash de la KSK raíz con el ancla de confianza que tiene codificada (o auto-actualizada vía RFC 5011). La KSK raíz actual está publicada en https://data.iana.org/root-anchors/.

Si cada firma verifica y la raíz se encadena hasta el ancla de confianza, el resolutor devuelve la respuesta con la bandera AD (Authenticated Data) activada. Cualquier fallo en el camino y el resolutor devuelve SERVFAIL — mejor romper que servir una respuesta potencialmente manipulada.

Lo que puede salir mal

Los dos primeros — DS desactualizado y firmas expiradas — causan la gran mayoría de las caídas DNSSEC reales. Los proveedores gestionados manejan la re-firma automáticamente; el registro DS en el registrador es el punto de fallo manipulable por humanos.

Uniéndolo todo — Un modelo mental

La aparente complejidad de DNSSEC es en su mayoría contabilidad. La verdadera pregunta criptográfica es simple: ¿vino esta respuesta de alguien que controla la clave privada de la zona? La cadena de confianza es una serie de vinculaciones de clave pública, cada una un paso normal "clave A firma clave B" o "clave A firma datos D":

• La KSK raíz firma el conjunto DNSKEY raíz (que incluye la ZSK raíz).
• La ZSK raíz firma los registros DS de los TLD.
• La KSK de un TLD firma el conjunto DNSKEY del TLD (que incluye la ZSK del TLD).
• La ZSK del TLD firma los registros DS de las zonas registradas.
• La KSK de su zona firma su conjunto DNSKEY (que incluye su ZSK).
• Su ZSK firma cada conjunto de registros en su zona — incluyendo los registros NSEC/NSEC3 que manejan la negación.

Cada eslabón es solo una firma; la magia es que el resolutor solo necesita la clave raíz para verificarlas todas.

Referencias

• RFC 4033 — Introducción y requisitos de DNS Security
• RFC 4034 — Resource Records para DNS Security Extensions (DNSKEY, DS, NSEC, RRSIG)
• RFC 4035 — Modificaciones del protocolo para DNS Security Extensions
• RFC 5155 — DNSSEC Hashed Authenticated Denial of Existence (NSEC3)
• RFC 6781 — DNSSEC Operational Practices, Version 2
• RFC 7344 / 8078 — Automating DNSSEC Delegation Trust Maintenance (CDS / CDNSKEY)
• RFC 8624 — Algorithm Implementation Requirements and Usage Guidance for DNSSEC
• RFC 8901 — Modelos DNSSEC multi-firmante
• Números de algoritmos DNSSEC IANA
• Anclas de confianza raíz IANA

Lecturas relacionadas

• ¿Qué es DNSSEC? — introducción top-of-funnel
• Gestión de claves DNSSEC — procedimientos operativos de rotación
• Guía de configuración DNSSEC para DNScale — paso a paso del producto
• DNSSEC vs DNS over HTTPS — integridad vs privacidad
• Envenenamiento de caché DNS — el ataque que DNSSEC derrota
• NIS2 y cumplimiento DNS — DNSSEC como control regulatorio