El DNS es la fundación invisible de toda presencia digital. Cuando un servidor DNS autoritativo falla o se sobrecarga, ningún usuario puede acceder al dominio — sin importar cuán robustos sean los servidores de aplicación. Los atacantes lo saben. El DNS Flood y los ataques PRSD explotan exactamente esa dependencia: en lugar de atacar el servicio directamente, atacan la infraestructura que lo hace localizable.
El DNS Flood es un ataque DDoS volumétrico que agota el ancho de banda y la capacidad de procesamiento de un servidor DNS con un volumen masivo de consultas UDP en el puerto 53. Los ataques PRSD (Pseudo Random Subdomain, también llamados DNS Water Torture o NXDOMAIN Flood) son una variante distinta y más sofisticada: en lugar de saturar el ancho de banda, agotan la CPU mediante cache miss compulsorio — cada consulta apunta a un subdominio aleatorio e inexistente, forzando al servidor autoritativo a realizar trabajo computacional real sin ninguna posibilidad de reutilizar resultados cacheados.
DNS Flood volumétrico — agotamiento de ancho de banda en el puerto UDP 53
Un DNS Flood básico envía consultas en volumen masivo al mismo dominio o a dominios válidos. Como el DNS opera sobre UDP sin handshake, el atacante puede generar y enviar cientos de miles de consultas por segundo a un coste computacional mínimo — y, con IP spoofing, sin revelar su origen real.
El impacto es directo: los buffers de recepción UDP del servidor se desbordan, la cola de consultas pendientes se satura y el servidor comienza a descartar consultas por timeout. Los usuarios legítimos reciben SERVFAIL o no obtienen respuesta.
La tabla siguiente resume las características operativas del DNS Flood volumétrico:
| Parámetro | Comportamiento en DNS Flood |
|---|---|
| Protocolo de transporte | UDP, puerto 53 |
| IP de origen | Frecuentemente falsificada (IP spoofing) |
| Tipo de consulta | Cualquier tipo válido (A, AAAA, MX, ANY) |
| Dominio consultado | Generalmente el mismo dominio repetidamente |
| Respuesta del servidor | NOERROR con datos, o SERVFAIL si está sobrecargado |
| Recurso agotado | Ancho de banda de red y capacidad de I/O UDP |
| Detectabilidad | Alta — pico volumétrico visible en métricas de red |
| Efectividad del caché | Parcial — el resolver cachea respuestas y reduce carga en el autoritativo |
Ataque PRSD — agotamiento de CPU por cache miss compulsorio
El ataque PRSD opera con una lógica radicalmente diferente. En lugar de sobrecargar la red con volumen, elimina el caché como mecanismo de protección y fuerza al servidor autoritativo a procesar cada consulta individualmente.
El mecanismo funciona así: el atacante genera consultas para subdominios aleatorios del dominio objetivo — por ejemplo, a7x9k2m.objetivo.com, después b3p8q1n.objetivo.com, después c5w7r4s.objetivo.com. Cada subdominio es único y no existe en el DNS. El resolver recursivo consulta su caché, no encuentra la respuesta (cache miss) y reenvía la consulta al servidor autoritativo. El autoritativo verifica su zona, no encuentra el subdominio y responde con NXDOMAIN. El resultado nunca se cachea de forma útil para la siguiente consulta, porque la siguiente consulta usará un subdominio diferente.
El contraste con el DNS Flood es decisivo:
| Característica | DNS Flood volumétrico | PRSD (Water Torture / NXDOMAIN Flood) |
|---|---|---|
| Objetivo primario | Ancho de banda e I/O del servidor | CPU del servidor autoritativo |
| Dominio consultado | Fijo o limitado | Subdominios aleatorios únicos por consulta |
| Caché como defensa | Parcialmente eficaz | Ineficaz — cada consulta es única |
| Volumen necesario | Alto (cientos de Gbps) | Moderado (decenas de miles de consultas/s) |
| Respuesta típica | NOERROR o SERVFAIL | NXDOMAIN (subdominio inexistente) |
| Detectabilidad | Alta — pico volumétrico visible | Moderada — mezclado con tráfico legítimo |
| Coste por consulta para el servidor | Bajo (respuesta cacheada) | Alto (búsqueda completa de zona por consulta) |
Impacto del PRSD en los resolvers recursivos intermediarios
Un aspecto frecuentemente subestimado del ataque PRSD es su impacto en los resolvers recursivos intermediarios — los servidores DNS de los ISPs, empresas y proveedores de nube que reciben las consultas de los usuarios finales antes de reenviarlas al servidor autoritativo.
Cada consulta PRSD que pasa por el resolver recursivo genera los siguientes efectos acumulativos:
Agotamiento de sockets UDP: el resolver recursivo abre un socket UDP para cada consulta pendiente reenviada al autoritativo. Con decenas de miles de consultas PRSD por segundo, el pool de sockets disponibles en el resolver puede saturarse, impidiendo que nuevas consultas — incluso para otros dominios — sean procesadas.
Acumulación de consultas pendientes: el resolver mantiene un estado de consulta pendiente mientras espera la respuesta del servidor autoritativo. En un ataque PRSD intenso, la tabla de consultas pendientes crece más rápido de lo que se vacía con las respuestas NXDOMAIN, consumiendo memoria y CPU del resolver.
Riesgo de lame server marking: cuando un servidor autoritativo no responde dentro del timeout configurado (generalmente 1,5 a 5 segundos), el resolver recursivo puede marcarlo como “lame server” — un servidor con problemas de autoridad. Un servidor marcado como lame es temporalmente eliminado de la lista de autoritativos consultados, acelerando la propagación de la indisponibilidad a usuarios que ni siquiera están siendo atacados directamente.
Estos tres efectos en cascada sobre el resolver recursivo explican por qué el PRSD puede derribar la resolución DNS de un dominio incluso cuando el volumen de tráfico es insuficiente para saturar el enlace de red del servidor autoritativo.
DNSSEC y el coste computacional del NSEC3 durante ataques PRSD
Si el dominio objetivo usa DNSSEC, el ataque PRSD se vuelve significativamente más costoso para el servidor autoritativo en términos de CPU.
Cuando un resolver recursivo con validación DNSSEC recibe una respuesta NXDOMAIN, necesita una prueba criptográfica de inexistencia — evidencia de que el subdominio genuinamente no existe en la zona y que la ausencia de registro es auténtica. Dos mecanismos DNSSEC fueron diseñados para proporcionar esta prueba:
NSEC (Next Secure): enumera los nombres adyacentes en la zona ordenada. Una respuesta NXDOMAIN con NSEC contiene dos registros que prueban que el nombre no existe y cuáles son los nombres más cercanos que sí existen. El NSEC tiene una limitación crítica: permite la enumeración completa de la zona DNS, lo que se considera un problema de privacidad.
NSEC3 (RFC 5155): resuelve el problema de enumeración usando hashes criptográficos (SHA-1 con salt y un número configurable de iteraciones) de los nombres de zona en lugar de los nombres en texto claro. Una respuesta NXDOMAIN con NSEC3 contiene los hashes de los nombres adyacentes ordenados, probando la inexistencia sin revelar los nombres reales de la zona.
El coste computacional del NSEC3 durante un ataque PRSD es sustancial por dos motivos:
-
Para cada consulta PRSD, el servidor autoritativo debe calcular el hash NSEC3 del subdominio inexistente para determinar qué registros NSEC3 adyacentes incluir en la respuesta. Con decenas de miles de subdominios únicos por segundo, esto representa un volumen masivo de operaciones de hash SHA-1.
-
El número de iteraciones de hash es configurable (el campo
iterationsdel NSEC3PARAM). Configuraciones con iteraciones elevadas aumentan la resistencia a ataques de enumeración offline, pero amplían el coste de CPU por consulta NXDOMAIN durante ataques PRSD.
En términos prácticos, un servidor autoritativo con DNSSEC y NSEC3 configurado puede saturar su CPU con un volumen de consultas PRSD mucho menor que un servidor sin DNSSEC. La recomendación actual (RFC 9276) es usar iterations=0 — sin iteraciones adicionales más allá del hash base — para minimizar el coste computacional sin comprometer la seguridad.
Impacto en cascada de la indisponibilidad DNS
La indisponibilidad del DNS afecta simultáneamente a todos los servicios que dependen de ese dominio:
| Servicio afectado | Impacto observado |
|---|---|
| Sitio web | Timeout — los usuarios no pueden resolver el dominio |
| APIs e integraciones | Fallos en las llamadas — endpoints inaccesibles |
| Correo electrónico | Bounces — registros MX no resueltos |
| CDN | Contenido estático inaccesible — CNAME no resuelve |
| Certificados TLS | Renovación Let’s Encrypt falla — validación DNS-01 bloqueada |
| Servicios de terceros | Webhooks, SSO e integraciones dejan de funcionar |
Técnicas de mitigación
Response Rate Limiting (RRL) — mecanismo de slip con flag TC=1
El RRL limita la tasa de respuestas idénticas o similares enviadas a la misma dirección IP de destino dentro de una ventana de tiempo deslizante. Implementado en BIND (desde 9.9), Knot DNS y PowerDNS, es la principal defensa específica de protocolo contra DNS Flood y ataques de reflexión.
El mecanismo central del RRL es la política de slip: en lugar de descartar simplemente las respuestas que superan el límite de tasa — lo que podría penalizar a los resolvers legítimos de ISPs que sirven a muchos clientes — el servidor responde periódicamente usando el flag de truncamiento TC=1.
El funcionamiento es el siguiente: cuando una respuesta superaría el límite de tasa configurado, el servidor envía periódicamente una respuesta truncada con TC=1 en lugar de descartarla silenciosamente. Un cliente legítimo que recibe TC=1 entiende que la respuesta está incompleta y reintenta la consulta por TCP — un canal confiable prácticamente imposible de falsificar con IP spoofing. Las herramientas de ataque y amplificadores que usan UDP puro no implementan este fallback a TCP y, por tanto, quedan efectivamente bloqueados sin recibir la respuesta completa.
Una configuración típica incluye responses-per-second (límite de respuestas idénticas por ventana), window (duración de la ventana de tiempo, normalmente 15 segundos) y slip (frecuencia de respuestas TC=1 en lugar de descarte, normalmente 2 — una de cada dos respuestas limitadas recibe TC=1).
Caché negativo (NCACHE) y el papel del SOA MINIMUM TTL
Para los ataques PRSD, cada consulta resulta en NXDOMAIN. El RFC 2308 define el mecanismo de caché negativo (NCACHE): los resolvers recursivos pueden almacenar en caché las respuestas NXDOMAIN durante el tiempo definido en el campo MINIMUM del registro SOA de la zona, hasta un máximo de 10.800 segundos (3 horas).
El SOA MINIMUM TTL actúa como el TTL de caché negativo de la zona. Cuando el autoritativo responde NXDOMAIN para a7x9k2m.objetivo.com, el resolver cachea esa respuesta durante hasta SOA MINIMUM segundos. Si el mismo subdominio vuelve a ser consultado dentro de ese período, el resolver responde desde la caché sin contactar al servidor autoritativo.
La limitación crítica para los ataques PRSD es que este mecanismo solo funciona para subdominios repetidos. El PRSD genera subdominios completamente aleatorios y únicos en cada consulta — a7x9k2m, b3p8q1n, c5w7r4s, etc. — garantizando que el resolver nunca encuentre dos veces el mismo subdominio. La caché negativa, por tanto, ofrece protección mínima contra el PRSD cuando los subdominios no se repiten.
Los wildcards DNS (*.objetivo.com) pueden ayudar parcialmente: si el autoritativo tiene un wildcard, la respuesta para cualquier subdominio será un registro válido (no NXDOMAIN), permitiendo el caching normal. Sin embargo, el primer cache miss de cada subdominio único sigue generando una consulta al autoritativo.
BGP Anycast — distribución de carga en múltiples PoPs
El BGP Anycast es la arquitectura más eficaz para resistir DNS Flood y PRSD a escala. El principio es sencillo: el mismo bloque de direcciones IP del servidor DNS se anuncia via BGP desde múltiples Puntos de Presencia (PoPs) geográficamente distribuidos.
El enrutamiento BGP dirige automáticamente cada consulta al PoP más cercano al origen, sin configuración adicional en el cliente. Para ataques volumétricos, el tráfico malicioso se divide entre todos los PoPs, reduciendo proporcionalmente la carga en cada uno:
| Configuración | Capacidad por nodo | Carga de un ataque de 500K consultas/s |
|---|---|---|
| 1 servidor centralizado | 500K consultas/s | 100% — sobrecarga total |
| 10 PoPs Anycast | 500K consultas/s | ~10% por PoP — absorbido sin impacto |
| 100 PoPs Anycast | 500K consultas/s | ~1% por PoP — prácticamente imperceptible |
Para los ataques PRSD, el Anycast distribuye no solo el volumen de consultas, sino también el coste de CPU del procesamiento NXDOMAIN (y el cálculo de hash NSEC3 en zonas DNSSEC) entre los PoPs. Un PoP en Europa absorbe las consultas de botnets europeas; un PoP en Asia absorbe consultas asiáticas. El servidor de origen queda completamente aislado de la carga del ataque.
Filtrado de IP spoofing (BCP38)
El DNS sobre UDP es especialmente vulnerable al IP spoofing. La implementación de BCP38 en los ISPs — que descarta paquetes con direcciones de origen imposibles o inválidas — impide que los atacantes envíen consultas con IPs falsificadas, eliminando una clase entera de ataques reflejados.
Limitación de tasa por IP de origen (ACLs)
Configurar límites de consultas por IP de origen en el servidor autoritativo bloquea las botnets de direcciones concentradas sin afectar a los resolvers recursivos legítimos. Un resolver de ISP típicamente envía consultas en nombre de miles de usuarios, por lo que los límites deben calibrarse para no bloquear resolvers legítimos de alto volumen.
DNS autoritativo en el edge vs. DNS centralizado
| Aspecto | DNS centralizado | DNS autoritativo en el edge (BGP Anycast) |
|---|---|---|
| Resiliencia al DNS Flood | Baja — punto único de ataque | Alta — carga distribuida entre PoPs |
| Resiliencia al PRSD | Baja — CPU agotada por cache misses | Alta — cada PoP absorbe su región geográfica |
| Aislamiento del servidor de origen | Ninguno — origen expuesto directamente | Total — las consultas llegan a los PoPs, nunca al origen |
| Latencia de resolución | Alta para usuarios distantes | Baja — resolución en el PoP más cercano |
| Failover automático | Requiere configuración manual | Transparente via convergencia BGP |
| Capacidad total de consultas/s | Limitada por hardware único | Escalable horizontalmente con cada PoP añadido |
| Coste NSEC3 bajo PRSD | Concentrado en 1 servidor | Distribuido entre 100+ servidores |
Señales de detección
| Indicador | Qué observar | Ataque probable |
|---|---|---|
| Tasa de NXDOMAIN superior al 30% | Proporción de respuestas NXDOMAIN vs. NOERROR | PRSD |
| Alto volumen de subdominios únicos por segundo | Logs mostrando patrón [random].dominio.com | PRSD |
| CPU elevada del servidor DNS sin pico de ancho de banda | Alto procesamiento sin aumento proporcional de tráfico | PRSD con DNSSEC |
| Consultas/segundo en pico sin evento de marketing | Aumento repentino sin causa conocida | DNS Flood o PRSD |
| Resolvers recursivos reportando timeouts | Lame server marking en curso | PRSD severo |
| Tasa de lame delegation en aumento | Logs de resolver mostrando autoritativo marcado como lame | PRSD avanzado |
Errores comunes y soluciones
Error: Depender de un único servidor DNS autoritativo centralizado sin redundancia geográfica. Solución: Un único servidor autoritativo es tanto un punto único de fallo para toda la presencia digital como un objetivo concentrado para ataques. Usa al menos dos servidores en ubicaciones diferentes — idealmente con BGP Anycast para la distribución automática de carga.
Error: No configurar RRL en el servidor DNS autoritativo.
Solución: Por defecto, servidores como BIND no limitan respuestas. Configura RRL con slip (TC=1) para protegerse contra la amplificación reflexiva sin penalizar a los resolvers legítimos. Ajusta responses-per-second según el perfil de tráfico normal de la zona.
Error: Confiar en el NCACHE como protección completa contra el PRSD. Solución: La caché negativa solo protege contra consultas repetidas al mismo subdominio. El PRSD genera subdominios únicos por consulta, haciendo el NCACHE ineficaz para las consultas activas del ataque. Combina NCACHE con Anycast y RRL.
Error: Ignorar el PRSD porque la protección volumétrica está activa.
Solución: El PRSD puede operar por debajo de los umbrales volumétricos mientras satura la CPU del autoritativo. Usa defensas específicas del protocolo DNS (RRL, Anycast, NSEC3 con iterations=0) además de la protección volumétrica.
Error: Configurar NSEC3 con un número alto de iteraciones en zonas en riesgo de PRSD.
Solución: Las iteraciones elevadas aumentan el coste de CPU por consulta NXDOMAIN. Sigue la recomendación del RFC 9276 y usa iterations=0 para minimizar la superficie de ataque sin comprometer la seguridad de la zona.
Preguntas frecuentes
¿Cuál es la diferencia fundamental entre DNS Flood y PRSD? El DNS Flood busca agotar el ancho de banda de red y el I/O UDP del servidor con un volumen masivo de consultas. El PRSD busca agotar la CPU del servidor mediante cache miss compulsorio — cada consulta genera trabajo computacional nuevo y no reutilizable porque apunta a un subdominio único e inexistente. El DNS Flood es detectable por pico volumétrico; el PRSD puede operar a volumen de red modesto mientras satura el procesador.
¿Cómo afecta el PRSD a los resolvers recursivos intermediarios? El PRSD sobrecarga los resolvers recursivos de tres formas simultáneas: agota el pool de sockets UDP disponibles para consultas pendientes; acumula una tabla de consultas pendientes que consume memoria y CPU; y puede causar lame server marking del autoritativo si se superan los timeouts, acelerando la propagación de la indisponibilidad a usuarios que ni siquiera están siendo atacados directamente.
¿Por qué el DNSSEC agrava el impacto del PRSD?
Con DNSSEC activado y NSEC3 configurado, cada respuesta NXDOMAIN requiere el cálculo de hashes SHA-1 para generar las pruebas criptográficas de inexistencia (RFC 5155). Con decenas de miles de subdominios aleatorios por segundo, este coste de hashing multiplica el uso de CPU del servidor autoritativo. Usa iterations=0 en NSEC3PARAM para minimizar el coste sin comprometer la seguridad.
¿Qué es el mecanismo de slip del RRL y cómo protege a los resolvers legítimos? El slip es la política del RRL de responder periódicamente con TC=1 (respuesta truncada) en lugar de descartar silenciosamente. Un cliente legítimo que recibe TC=1 reintenta via TCP — un canal confiable resistente al IP spoofing. Las herramientas de ataque que usan UDP puro no implementan este fallback y quedan efectivamente bloqueadas. El slip garantiza que el RRL no penalice a los resolvers de ISPs que genuinamente necesitan alta tasa de respuestas.
¿El DNS Flood es lo mismo que la Amplificación DNS? No. El DNS Flood sobrecarga el servidor DNS objetivo con un volumen masivo de consultas — el objetivo es el propio servidor DNS. La Amplificación DNS usa servidores DNS abiertos como reflectores para amplificar tráfico UDP contra una víctima diferente. Son vectores distintos con objetivos y mecanismos diferentes.
¿Por qué el PRSD se llama “Water Torture”? El nombre proviene de la tortura de la gota de agua — cada consulta individualmente causa trabajo real pero limitado en el servidor, acumulándose hasta generar indisponibilidad por sobrecarga gradual de CPU. Es más insidioso que el flood volumétrico porque puede operar a volumen de red modesto y es difícil de distinguir del tráfico legítimo.
¿Un TTL de DNS bajo ayuda o perjudica durante un ataque PRSD? Perjudica. Los TTLs bajos obligan a los resolvers a consultar el autoritativo con más frecuencia incluso para registros existentes, aumentando la carga base. Durante ataques PRSD, los TTLs más altos en los registros existentes son beneficiosos — los resolvers cachean las respuestas durante más tiempo, reduciendo la presión sobre el autoritativo para el tráfico legítimo.
Cómo implementar en Azion
Azion protege contra DNS Flood y PRSD con arquitectura de Edge DNS autoritativo distribuido via BGP Anycast global:
- Edge DNS con BGP Anycast en 100+ PoPs: El DNS autoritativo de Azion opera con la misma IP anunciada desde más de 100 data centers via BGP Anycast. El tráfico de ataque es distribuido automáticamente por el enrutamiento BGP entre los PoPs más cercanos a la fuente, sin configuración manual. Ningún PoP individual recibe una fracción significativa del ataque total. El servidor de origen queda completamente aislado — las consultas llegan a los PoPs de Azion, nunca al backend de origen.
- Response Rate Limiting nativo con slip: El Edge DNS de Azion implementa RRL por defecto con el mecanismo de slip (TC=1), protegiendo contra ataques de reflexión y amplificación sin penalizar a los resolvers recursivos legítimos.
- Protección contra NSEC3 flood en zonas DNSSEC: La infraestructura distribuida distribuye el coste de cálculo NSEC3 entre los PoPs, evitando que un único servidor autoritativo sature su CPU con operaciones de hashing durante ataques PRSD intensos contra zonas DNSSEC.
- Protección contra IP spoofing: La red de Azion implementa filtrado de paquetes que descarta consultas con direcciones de origen imposibles, reduciendo el impacto de los ataques DNS Flood basados en IP spoofing.
Aprende más en la documentación de Edge DNS de Azion.