Multitud de consultas de subdominios aleatorios e inexistententes de mydomain.com. Objetivo colapso del servidor DNS autoritavo donde esta registrado mydomain.com
watertorture.bat ;Water Torture DNS autoritativo con proceso por lotes Bath MS-DOS:
Consultas subdominios aleatorios de un dominio.
@ECHO OFF
ECHO Water Torture DNS autoritativo. (c) hackingyseguridad 2016. Version 1.
:loop
SET/A ran=%random%
NSLOOKUP %ran%.hackingyseguridad.es 196.200.104.106
goto loop
- ¿Qué es un ataque Water Torture?
- Por qué es efectivo contra el DNS
- Arquitectura DNS y puntos de fallo
- Variantes conocidas
- Cómo detectarlo
- Técnicas de mitigación
- Buenas prácticas para pruebas de resiliencia en laboratorio
- Referencias
Un ataque Water Torture (o Random Subdomain Attack) es una forma de denegación de servicio (DoS/DDoS) dirigida contra el servidor DNS autoritativo de un dominio. En lugar de saturar directamente el ancho de banda del objetivo, el atacante genera un volumen masivo de consultas a subdominios aleatorios e inexistentes dentro de un dominio legítimo (por ejemplo, x7fk29.midominio.com, a91jd3.midominio.com, etc.).
La idea central es explotar una asimetría de coste:
- Generar una consulta aleatoria es prácticamente gratis para el atacante.
- Resolver esa consulta obliga al servidor autoritativo (y a menudo a resolutores recursivos intermedios) a realizar trabajo real: búsquedas en zona, generación de respuestas NXDOMAIN, y en muchos casos consultas en cascada hacia servidores upstream.
Al no existir esos subdominios, cada consulta termina en una respuesta NXDOMAIN, pero el coste de procesamiento ya se ha pagado.
| Factor | Descripción |
|---|---|
| Amplificación por reflexión recursiva | Si las consultas se envían a través de resolutores recursivos abiertos, estos reenvían la consulta al servidor autoritativo, multiplicando el origen del tráfico y dificultando el filtrado por IP de origen. |
| Caché ineficaz | Los sistemas de caché DNS están optimizados para nombres repetidos y populares. Como cada subdominio es único y aleatorio, la caché no puede absorber la carga: cada consulta llega "fresca" al autoritativo. |
| Coste asimétrico | Generar una consulta es trivial; resolverla y construir una respuesta NXDOMAIN firmada (en zonas con DNSSEC) consume CPU y recursos de forma desproporcionada. |
| Dificultad de filtrado | Al no existir un patrón de nombre reconocible ni una IP de origen única (especialmente con múltiples resolutores o spoofing), el tráfico malicioso se mezcla con el legítimo. |
| Efecto colateral en resolutores | Además del autoritativo objetivo, los resolutores recursivos intermedios (ISPs, DNS públicos) también sufren carga adicional, lo que puede convertir el ataque en un problema de terceros. |
Para entender dónde impacta este ataque, conviene repasar la cadena de resolución:
Cliente → Resolutor recursivo (ISP / público) → Servidor raíz (.)
→ Servidor TLD (.com, .es...) → Servidor autoritativo del dominio
Un ataque Water Torture típicamente se dirige al último eslabón: el servidor autoritativo del dominio objetivo. Pero si el volumen es suficientemente alto y no se filtra bien, puede degradar también:
- Los resolutores recursivos intermedios (consumo de memoria de caché, CPU).
- En casos extremos y a mayor escala, incluso servidores TLD o de zona raíz, como ocurrió con la variante NXNSAttack (ver más abajo), que explota el mecanismo de delegación NS para amplificar el efecto.
| Variante | Mecanismo | Impacto adicional |
|---|---|---|
| Random Subdomain Attack (clásico) | Consultas a subdominios aleatorios inexistentes bajo un dominio válido | Sobrecarga directa del autoritativo y de la caché de resolutores |
| NXNSAttack (2020, CVE-2020-8616 y relacionados) | Explota la resolución de delegaciones NS: una única consulta puede generar múltiples consultas adicionales del resolutor hacia servidores NS falsos o inexistentes | Factor de amplificación mucho mayor (se documentaron ratios de amplificación de decenas de veces) |
| Phantom Domain Attack | El resolutor consulta dominios que responden muy lentamente o no responden, agotando los sockets y colas de espera del resolutor | Afecta más a la disponibilidad del resolutor que a la del autoritativo |
| DNSSEC Amplification asociado | Cuando la zona usa DNSSEC, las respuestas NXDOMAIN firmadas (NSEC/NSEC3) son más grandes y costosas de generar, aumentando el coste por consulta | Mayor consumo de CPU y de ancho de banda de salida |
Señales típicas en los logs y métricas del servidor DNS autoritativo:
- Incremento súbito y sostenido de la tasa de consultas (QPS) sin relación con tráfico legítimo esperado.
- Proporción anormalmente alta de respuestas
NXDOMAINfrente al total de respuestas. - Los nombres consultados no siguen ningún patrón reconocible (aleatoriedad alta, entropía elevada en las etiquetas de subdominio).
- Consultas provenientes de un número elevado y disperso de IPs de resolutores, en lugar de clientes finales reconocibles.
- Aumento de latencia en la resolución de nombres legítimos del mismo dominio como efecto colateral.
Herramientas útiles para monitorización: dnstop, dnscap, métricas nativas de BIND (rndc stats), Unbound (unbound-control stats), o soluciones de observabilidad DNS específicas (p. ej. Farsight/DNSDB, Akamai/Cloudflare DNS analytics si el dominio está detrás de un proveedor gestionado).
| Técnica | Qué hace | Dónde se aplica |
|---|---|---|
| Response Rate Limiting (RRL) | Limita la tasa de respuestas idénticas o similares (mismo tipo de respuesta, mismo prefijo de red origen) por unidad de tiempo | Servidor autoritativo (BIND9 rate-limit, Knot DNS, PowerDNS) |
| Negative caching agresivo | Aumenta el TTL de las respuestas NXDOMAIN cacheadas para reducir consultas repetidas al autoritativo | Resolutores recursivos (RFC 2308 / RFC 8198 "aggressive NSEC caching" con DNSSEC) |
| Anycast + escalado horizontal | Distribuye la carga entre múltiples nodos geográficamente dispersos, absorbiendo picos de tráfico | Infraestructura de red del proveedor DNS |
| Filtrado y listas de reputación | Bloqueo o rate-limiting de resolutores abiertos conocidos por ser abusados, o de rangos IP con comportamiento anómalo | Firewall / DNS firewall / ACLs en el servidor autoritativo |
| DNS Cookies (RFC 7873) | Mecanismo ligero de verificación que dificulta el spoofing de IP de origen en consultas UDP | Servidor autoritativo y resolutor (soporte en BIND9, Knot, Unbound recientes) |
| Separar autoritativo de recursivo | Nunca ejecutar un servidor que sea autoritativo y recursivo abierto a la vez, evitando efectos de amplificación cruzada | Diseño de arquitectura |
| Servicios DNS gestionados con protección DDoS | Proveedores como Cloudflare, AWS Route 53, NS1, Akamai incluyen mitigación de este vector por diseño (escala + filtrado + anycast) | Externalización de la zona autoritativa |
| Límite de consultas NS por respuesta (mitigación NXNSAttack) | Los resolutores modernos limitan cuántos servidores NS de una delegación intentan resolver antes de desistir | Configuración del resolutor recursivo |
| Auditoría de zona y delegaciones | Revisar periódicamente que las delegaciones NS del propio dominio no apunten a servidores inexistentes o mal configurados, que podrían ser usados para amplificación indirecta | Gestión de la zona DNS |
- RFC 2308 — Negative Caching of DNS Queries
- RFC 7873 — Domain Name System (DNS) Cookies
- RFC 8198 — Aggressive Use of DNSSEC-Validated Cache
- Afek, Y. et al. (2020) — NXNSAttack: Recursive DNS Inefficiencies and Vulnerabilities
- Documentación oficial de BIND9 sobre Response Rate Limiting
- Documentación de Knot DNS y PowerDNS sobre mitigación de amplificación
Este documento tiene fines exclusivamente educativos y de referencia para la defensa de infraestructura DNS. No sustituye el asesoramiento de un profesional de seguridad ni las recomendaciones específicas del proveedor de tu infraestructura DNS.