DNSSEC:
firmar la zona, la cadena de confianza y por qué tanta gente lo hace mal
Redes y privacidad | unfantasmaenelsistema.com
El DNS que usamos a diario no tiene forma de demostrar que una respuesta es auténtica. Cuando tu resolutor pregunta por la dirección de un dominio y recibe una respuesta, la acepta si llega con el identificador de transacción correcto y por el puerto esperado. Un atacante bien situado, o uno que acierte con esos valores, puede colar una respuesta falsa y dirigir a los usuarios a donde quiera. DNSSEC existe para cerrar ese hueco: añade firmas criptográficas a los datos del DNS para que el resolutor pueda verificar que vienen de quien dice y que nadie los ha tocado por el camino.
Este artículo explica qué problema resuelve DNSSEC y cuál no, los registros nuevos que introduce, cómo se construye la cadena de confianza desde la raíz, la diferencia entre KSK y ZSK y el temido rollover, cómo valida un resolutor, y los fallos de operación que hacen que DNSSEC se lleve fama de frágil. Es el complemento de nuestro artículo sobre DNS cifrado: allí hablamos de confidencialidad, aquí de autenticidad e integridad.
Qué aprenderas en este articulo
Qué ataque para DNSSEC (envenenamiento de caché, respuestas falsas) y qué no (no cifra nada) · Para qué sirven los registros RRSIG, DNSKEY, DS y NSEC/NSEC3 · Cómo la raíz, el TLD y tu dominio forman una cadena de confianza mediante el registro DS · Qué son la KSK y la ZSK y por qué un rollover mal hecho tumba el dominio · Los errores de operación más comunes y cómo comprobarlos con dig y delv
1. Qué resuelve DNSSEC y qué no
DNSSEC (DNS Security Extensions) aporta autenticación del origen de los datos e integridad: la garantía de que la respuesta procede de la zona legítima y de que no ha sido modificada. También permite la negación autenticada de existencia: probar de forma verificable que un nombre no existe.
DNSSEC no cifra
Las consultas y respuestas siguen viajando en claro: cualquiera en la ruta ve qué dominios resuelves. Para eso están DoH, DoT y DNSCrypt, que cubrimos en otro artículo · DNSSEC tampoco autentica el canal entre tu dispositivo y el resolutor: valida los datos, no el transporte. Ambos mecanismos son complementarios, no alternativos · Y no impide que un dominio malicioso firme sus propios registros: DNSSEC dice «esto viene de quien dice», no «quien dice esto es de fiar»
El ataque que sí frena es real y clásico: el envenenamiento de caché (Kaminsky, 2008) y cualquier variante en la que un tercero inyecta datos DNS falsos. Sin DNSSEC, la única defensa es hacer difícil de adivinar la transacción (puerto de origen aleatorio, 0x20). Con DNSSEC, la respuesta falsa no lleva una firma válida y el resolutor la descarta.
2. Los registros nuevos
| Registro | Qué contiene | Quién lo publica |
|---|---|---|
| DNSKEY | La clave pública de la zona (habitualmente dos: KSK y ZSK) | El operador de la zona, en la propia zona |
| RRSIG | La firma de un conjunto de registros (RRset), con su periodo de validez | Se genera al firmar la zona; acompaña a cada RRset |
| DS | Un hash de la DNSKEY de la zona hija (la KSK) | La zona PADRE (el TLD publica el DS de tu dominio) |
| NSEC / NSEC3 | Indica qué nombres existen entre dos puntos, para negar existencia de forma autenticada | El operador de la zona, al firmarla |
| CDS / CDNSKEY | DS/DNSKEY «hijo» que el padre puede leer para automatizar el rollover | La zona hija, opcionalmente |
La idea de fondo: cada conjunto de registros de un tipo (todos los A de `www`, por ejemplo) va acompañado de un RRSIG que lo firma. El resolutor obtiene la DNSKEY de la zona para verificar ese RRSIG. Y para confiar en esa DNSKEY, comprueba que su hash coincide con el DS que publica el padre. Así, eslabón a eslabón, hasta la raíz.
3. La cadena de confianza
DNSSEC funciona porque hay un punto de partida en el que todo el mundo confía sin preguntar: la clave de la zona raíz, cuyo hash (el trust anchor) viene preconfigurado en todos los resolutores validadores y se gestiona mediante ceremonias públicas de firma.
- La raíz firma el conjunto de registros DS de cada TLD. Al validar `.com`, el resolutor comprueba el DS de `.com` contra la DNSKEY de la raíz, en la que ya confía
- El TLD (`.com`, `.es`, `.org`) firma el DS de cada dominio registrado bajo él. Ese DS es un hash de tu KSK y lo pones tú a través de tu registrador
- Tu dominio firma sus propios RRset (A, AAAA, MX, TXT…) con su ZSK, y firma su DNSKEY con su KSK
- Resultado: raíz -> TLD -> tu dominio, una cadena de firmas verificable de extremo a extremo. Si falta un eslabón (por ejemplo, no has subido el DS a tu registrador), la zona simplemente no está firmada a ojos del validador y no gana nada
El registro DS en el registrador es el paso que todo el mundo olvida
Puedes firmar tu zona perfectamente en tu servidor DNS y no obtener ninguna protección: si el TLD no publica tu DS, la cadena se rompe en el padre y los validadores tratan la zona como no firmada · El DS se entrega al registrador (no al operador DNS, si son distintos), y algunos registradores no ofrecen esa opción en su panel: conviene comprobarlo antes de elegir · Al revés es peor: si retiras la firma de la zona pero dejas el DS publicado en el padre, los validadores esperan firmas que ya no existen y tu dominio deja de resolver para ellos
4. KSK, ZSK y el rollover
Casi todas las zonas usan dos claves por una razón práctica:
- La ZSK (Zone Signing Key) firma los registros normales de la zona. Es más corta y se rota a menudo (cada 1-3 meses), lo que se puede hacer sin tocar al padre
- La KSK (Key Signing Key) solo firma el conjunto de DNSKEY. Es más larga y se rota rara vez (una vez al año o menos), porque cada rotación exige actualizar el DS en el padre
El rollover (cambio de clave) es donde se concentran los incidentes. La clave nueva y la vieja tienen que convivir el tiempo suficiente para que expire todo lo que los resolutores de medio mundo tienen en caché firmado con la vieja. Ir demasiado rápido significa que hay resolutores con una firma en caché cuya clave ya no está publicada: fallo de validación, dominio caído para esos usuarios.
- Para la ZSK se usa el método de pre-publicación: publicas la ZSK nueva un tiempo antes de empezar a firmar con ella
- Para la KSK, el método de doble firma o doble DS, coordinado con el TTL del DS en el padre
- Automatízalo. Los DNS modernos (BIND con `dnssec-policy`, Knot, PowerDNS, OpenDNSSEC) gestionan los rollovers solos. Y si el padre soporta CDS/CDNSKEY (RFC 7344) o el registro acepta la automatización, el DS se actualiza sin intervención manual
5. Cómo valida un resolutor
La validación la hace el resolutor recursivo, no tu navegador ni tu sistema operativo (salvo que corras un validador local). El proceso, resumido:
- Pide el RRset y su RRSIG. Comprueba que la firma es criptográficamente correcta y que la fecha actual está dentro del periodo de validez del RRSIG
- Obtiene la DNSKEY de la zona y verifica que valida ese RRSIG
- Pide el DS al padre, comprueba que su hash coincide con la KSK, y valida ese DS con la DNSKEY del padre… y así sube hasta la raíz
- Si todo cuadra, marca la respuesta con el bit AD (Authenticated Data). Si algo falla, devuelve SERVFAIL — no una respuesta insegura, sino ningún dato
Ese SERVFAIL es la cara visible de casi todos los problemas de DNSSEC: para el usuario, el dominio «no funciona», sin más pista. De ahí la importancia de monitorizar la expiración de las firmas y de probar los cambios antes de aplicarlos.
# Ver los registros DNSSEC y si la respuesta esta autenticada (flag 'ad') dig +dnssec +multiline example.com A # Traza de validacion completa desde la raiz, con el detalle de cada eslabon delv +vtrace example.com A # Consultar el DS que publica el padre para tu dominio dig DS example.com +short # Comprobar la fecha de expiracion de las firmas RRSIG de la zona dig +dnssec example.com SOA | grep RRSIG
6. Los fallos habituales
| Fallo | Síntoma | Prevención |
|---|---|---|
| DS en el padre que no cuadra con la KSK (tras un rollover mal hecho) | SERVFAIL en todos los resolutores validadores | Automatizar el rollover; coordinar con el TTL del DS; verificar con delv antes de dar por hecho el cambio |
| Firmas RRSIG caducadas | El dominio deja de resolver de golpe en una fecha concreta | Refirmado automático con margen; alertas sobre la fecha de expiración más próxima |
| Zona sin firmar pero DS aún publicado en el padre | SERVFAIL; ocurre al «desactivar» DNSSEC sin retirar el DS primero | Retirar el DS en el registrador y esperar su TTL ANTES de quitar las firmas |
| Cambio de operador DNS sin migrar las claves | Ventana de SERVFAIL durante la migración | Rollover de KSK coordinado entre ambos operadores, o proceso de ‘unsign / re-sign’ planificado |
| Algoritmo o tamaño de clave obsoleto (RSA/SHA-1) | Validadores estrictos rechazan; pérdida gradual de alcance | Usar ECDSA P-256 (algoritmo 13) o Ed25519 (15); migrar las zonas antiguas |
| NSEC permite enumerar toda la zona (zone walking) | Un tercero lista todos tus nombres de host | Usar NSEC3 con parámetros adecuados, o NSEC3 opt-out / ‘black lies’ según el DNS |
El patrón común: DNSSEC falla de forma binaria y silenciosa. No hay degradación elegante; o valida o el dominio desaparece para una parte de internet. Por eso la recomendación unánime es no operarlo a mano.
7. DNSSEC como base: DANE y el correo
Una vez que los datos DNS son verificables, se pueden publicar en ellos cosas de seguridad que antes no tenían dónde apoyarse. La principal es DANE (DNS-Based Authentication of Named Entities), que usa un registro TLSA firmado para fijar qué certificado o qué CA debe presentar un servicio TLS, sin depender solo del sistema de CA del navegador.
- DANE para SMTP (RFC 7672) es su uso más extendido: permite que el correo entre servidores se cifre de forma obligatoria y autenticada. Grandes proveedores de correo europeos lo exigen o lo prefieren
- MTA-STS es la alternativa que no necesita DNSSEC (se apoya en HTTPS y en una política publicada); muchas organizaciones despliegan ambos
- DANE para HTTPS en navegadores no ha cuajado; su terreno real es el correo y algunos protocolos de servidor a servidor
Pruebas solo sobre dominios propios
Consultar registros DNSSEC públicos con dig o delv es tráfico normal y legítimo; el problema aparece si se manipulan zonas, resolutores o el tráfico DNS de terceros · Modificar respuestas DNS de una red o un servicio que no administras, o montar un resolutor que sirva datos falsos a usuarios ajenos, puede constituir un delito de daños o de descubrimiento y revelación de secretos (en España, arts. 197 y siguientes y art. 264 del Código Penal) · Practica firmando tus propios dominios o un dominio de laboratorio y validando desde tu propio resolutor
Referencias
RFC 9364 (BCP 237) — DNSSEC, documento paraguas; RFC 4033/4034/4035 — especificación base · dnsviz.net — Visualiza y diagnostica la cadena de confianza de cualquier dominio · internet.nl — Test de DNSSEC, DANE y otros controles, orientado a operadores · Documentación de dnssec-policy en BIND 9, y de DNSSEC automático en Knot y PowerDNS · Nuestro artículo sobre DNS cifrado (DoH, DoT, DNSCrypt) para la parte de confidencialidad
Conclusión
DNSSEC hace por el DNS lo que las firmas digitales hacen por el software: no lo oculta, lo vuelve verificable. Cierra el envenenamiento de caché y las respuestas falsas, y da una base de confianza sobre la que se apoya DANE para blindar el correo entre servidores. Lo que no hace es cifrar: esa mitad la ponen DoH y DoT.
Su mala fama viene casi toda de la operación manual: firmas que caducan, rollovers descoordinados, un registro DS que se sube tarde o se retira pronto, y un dominio que desaparece sin avisar para media internet. La recomendación práctica cabe en una línea: actívalo con un DNS moderno que gestione las claves y los rollovers por ti, comprueba la cadena con dnsviz o delv, y no lo toques a mano.
unfantasmaenelsistema.com | Seguridad, sistemas y todo lo que no debería funcionar (pero funciona)