¿Qué es DNSSEC? Una guía clara sobre seguridad DNS

DNSSEC — abreviatura de DNS Security Extensions — es la única defensa ampliamente desplegada contra el envenenamiento de caché DNS, el ataque que permite a un adversario de red mentir a los resolutores sobre dónde apunta su dominio. Es estándar desde 2005, todos los TLD principales firman ahora su zona, y todos los proveedores DNS gestionados principales lo soportan. Si su dominio público no tiene DNSSEC activado, está confiando en que nadie entre sus usuarios y su servidor de nombres autoritativo tiene los medios o la motivación para redirigirlos a un lugar malicioso. Es una apuesta que ya no es razonable.

Esta guía es el punto de entrada en lenguaje claro: qué hace DNSSEC realmente, por qué existe, cómo funciona la cadena de confianza a alto nivel, y qué debe esperar de su proveedor DNS. Para la mecánica operativa — roles KSK vs ZSK, rotaciones de claves, elecciones de algoritmos — lea la guía más profunda Gestión de claves DNSSEC cuando tenga los fundamentos.

Lo que DNSSEC hace (y lo que no)

DNSSEC añade firmas digitales a los registros DNS. Cuando su servidor autoritativo devuelve un registro A diciendo que example.com está en 192.0.2.1, también devuelve una firma criptográfica sobre ese registro. Un resolutor que soporta validación DNSSEC puede comprobar la firma contra la clave pública de su zona — y comprobar esa clave pública contra una cadena que llega hasta un ancla de confianza codificada — y rechazar la respuesta si las firmas no validan.

Eso es todo su trabajo. DNSSEC:

• ✅ Demuestra que la respuesta vino del servidor autoritativo correcto. Un atacante man-in-the-middle no puede falsificar un registro sin romper la firma.
• ✅ Detecta manipulación en el cable o en una caché. Aunque la caché de un resolutor esté envenenada, las firmas no validan.
• ✅ Demuestra que un registro no existe (las respuestas negativas también se firman, vía registros NSEC/NSEC3).

DNSSEC no:

• ❌ Cifra consultas o respuestas DNS. Cualquiera que observe la red sigue viendo lo que está consultando. Use DNS over HTTPS o DNS over TLS para eso.
• ❌ Oculta la estructura de su zona. Las firmas DNSSEC son públicas; cualquiera puede recuperarlas.
• ❌ Reemplaza TLS o HTTPS. DNSSEC protege el propio DNS; una vez que tiene una dirección IP, la seguridad de la conexión depende del protocolo de aplicación.
• ❌ Defiende contra servidores autoritativos comprometidos. Si un atacante controla su servidor de nombres, puede firmar lo que quiera con las claves privadas de su zona. DNSSEC confía en el titular de la clave.

Por qué existe DNSSEC — El problema del envenenamiento de caché

El protocolo DNS original de los años 80 fue diseñado para una red donde nadie intentaba activamente engañar. Los resolutores pedían respuestas a los servidores autoritativos en UDP en texto plano, y confiaban en lo que volviera mientras la IP de origen y un identificador de transacción de 16 bits coincidieran.

Ese modelo de confianza aguantó hasta 2008, cuando Dan Kaminsky demostró envenenamiento de caché práctico a gran escala. El ataque funciona así:

1. El atacante hace que un resolutor recursivo busque un nombre que él controla (anything.example.com).
2. Mientras el resolutor espera respuesta del servidor autoritativo, el atacante lo inunda con respuestas falsificadas adivinando el ID de transacción de 16 bits.
3. Si una respuesta falsificada gana la carrera, el resolutor cachea la respuesta del atacante — un registro A falso para example.com — y la sirve a cada consulta posterior durante todo el TTL.

Cada usuario de ese resolutor — potencialmente millones de personas — ahora se redirige silenciosamente a donde el atacante eligió. Tráfico web, correo, actualizaciones de software: todo se envía al servidor del atacante hasta que la entrada de caché expire.

La comunidad DNS respondió con tres capas de mitigación:

1. Aleatorización de puerto origen en los resolutores (RFC 5452, 2009) — hizo la carrera mucho más difícil añadiendo 16 bits más de impredecibilidad.
2. DNS over HTTPS / DNS over TLS en el salto resolutor-cliente — cifró la conversación para que un atacante en la red local no pudiera ver ni alterar las consultas.
3. DNSSEC en el salto autoritativo-resolutor — añadió firmas criptográficas para que una caché envenenada produzca firmas inválidas que un resolutor validador rechaza.

DNSSEC es el único de los tres que realmente resuelve el problema subyacente a nivel autoritativo. La aleatorización de puerto hace el ataque más difícil; DoH/DoT cambia quién puede ver la consulta pero no quién puede mentir sobre la respuesta. DNSSEC verifica la respuesta misma.

La cadena de confianza — Una vista a alto nivel

Lo que hace que DNSSEC funcione a escala de Internet es que los resolutores no necesitan conocer su clave pública específica de antemano. En su lugar, recorren una cadena de confianza desde una clave raíz codificada hasta su zona:

Zona raíz (.)
    │  firma con KSK raíz
    │  publica registro DS para .com en la raíz
    ▼
TLD .com
    │  firma con KSK .com
    │  publica registro DS para example.com en .com
    ▼
example.com
    │  firma todos los registros con sus propias claves
    │  firma sobre el registro solicitado
    ▼
Registro A: example.com → 192.0.2.1

Un resolutor validador sigue esta cadena en sentido inverso:

1. Recibe el registro A firmado de su servidor autoritativo.
2. Recupera el registro DS de example.com desde los servidores de nombres .com y comprueba que el hash coincide con la KSK de su zona.
3. Recupera el registro DS de .com desde los servidores raíz y comprueba el hash contra la KSK de la zona .com.
4. Comprueba la firma de la zona raíz contra el ancla de confianza codificada (la KSK raíz, también publicada por IANA en https://data.iana.org/root-anchors/).

Si cualquier eslabón de la cadena falla al verificar, la respuesta se trata como no fiable. La mayoría de resolutores validadores devuelven SERVFAIL en lugar de servir una respuesta potencialmente manipulada.

No necesita entender la mecánica para usar DNSSEC. Su proveedor DNS genera y rota las claves por usted; su único trabajo es publicar una pieza — el registro DS — en su registrador para que la cadena alcance su zona.

Para el desglose mecánico completo — roles KSK vs ZSK, registros RRSIG, NSEC/NSEC3 para negación autenticada — vea Cómo funciona DNSSEC.

Cómo saber si un dominio tiene DNSSEC

Ejecute dig con la bandera +dnssec contra un resolutor validador:

dig +dnssec example.com @1.1.1.1

Busque dos cosas:

1. Registros RRSIG en la sección de respuesta, emparejados con cada conjunto de registros consultado. Esas son las firmas.
2. La bandera AD (Authenticated Data) en la cabecera de respuesta, indicando que el resolutor validó con éxito la cadena.

;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
                                ^^
                                 │
                          bandera AD activada = validación correcta
 
;; ANSWER SECTION:
example.com.         300  IN  A      192.0.2.1
example.com.         300  IN  RRSIG  A 13 2 300 20260601000000 ...
                                         ^^
                                          │
                                   registro de firma

Si ve los RRSIGs pero no la bandera AD, el resolutor no está validando — pruebe 1.1.1.1 o 9.9.9.9, que validan por defecto. Si no ve RRSIGs, la zona no está firmada.

Para visualización, DNSViz y el DNSSEC Debugger de Verisign dibujan la cadena de confianza completa y resaltan las roturas.

Cuándo activar DNSSEC

En resumen: siempre, para cualquier dominio público.

Casos especialmente importantes:

• Servicios de alta confianza — banca, comercio electrónico, proveedores de identidad, gobierno — donde un envenenamiento de caché exitoso tiene consecuencias directas.
• Correo electrónico — DNSSEC es prerequisito para DANE/TLSA, que protege el TLS SMTP contra ataques de degradación. MTA-STS es una alternativa parcial para organizaciones aún no listas para DANE.
• Entidades UE reguladas bajo NIS2 — el Artículo 21(2)(h) requiere "políticas y procedimientos sobre el uso de la criptografía". Un proveedor DNS que no ofrezca DNSSEC, o un despliegue que no lo haya activado, corre el riesgo de ser juzgado no conforme. Vea la guía NIS2 y DNS para el mapeo completo.
• Entornos guiados por cumplimiento — PCI DSS, HIPAA, ISO 27001 y varios marcos nacionales listan DNSSEC como control recomendado o esperado.

Esencialmente no hay situaciones donde DNSSEC sea mala idea para una zona pública. Las objeciones históricas — complejidad operativa, riesgo de gestión de claves, compatibilidad de resolutores — están en gran parte resueltas por proveedores DNS gestionados que manejan generación, rotación y publicación DS automáticamente.

Qué buscar en un proveedor DNS con DNSSEC

Al evaluar el soporte DNSSEC de un proveedor DNS, pregunte:

Activar DNSSEC en DNScale

DNScale activa DNSSEC con un clic por zona:

1. Desde el panel, abra la zona.
2. Haga clic en Activar DNSSEC. DNScale genera una CSK (Combined Signing Key) usando ECDSA P-256.
3. Copie el registro DS mostrado a su registrador. Algunos registradores lo aceptan directamente; otros vía API; otros aún requieren entrada manual.
4. Espere 24–48 horas a que el DS se propague en el TLD.
5. Verifique con dig +dnssec sudominio @1.1.1.1 y confirme la bandera AD.

La rotación de claves, el refresco de firmas y la sincronización con la zona padre se realizan automáticamente. Las actualizaciones de algoritmo son rolls coordinados que DNScale ejecuta sin tiempo de inactividad visible para el cliente.

Para el paso a paso completo incluyendo instrucciones específicas del registrador, vea Guía de configuración DNSSEC para DNScale. Para la mecánica subyacente, vea Cómo funciona DNSSEC y Gestión de claves DNSSEC.

Referencias

• RFC 4033 — Introducción y requisitos de DNS Security
• RFC 4034 — Resource Records para DNS Security Extensions
• RFC 4035 — Modificaciones del protocolo para DNS Security Extensions
• RFC 5155 — DNS Security (DNSSEC) Hashed Authenticated Denial of Existence (NSEC3)
• RFC 6781 — DNSSEC Operational Practices, Version 2
• RFC 8901 — Modelos DNSSEC multi-firmante
• Anclas de confianza raíz IANA
• DNSViz — visualizador para cadenas de confianza DNSSEC
• DNSSEC Debugger de Verisign

Lecturas relacionadas

• Cómo funciona DNSSEC — mecánica KSK/ZSK/DS/DNSKEY
• 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
• NIS2 y cumplimiento DNS — mapeo regulatorio
• Envenenamiento de caché DNS — el ataque que DNSSEC derrota