¿Qué es un ataque de inundación DNS?
Una inundación DNS es un tipo de ataque de Denegación Distribuida de Servicio (DDoS) que abruma la infraestructura DNS enviando volúmenes masivos de consultas DNS a servidores DNS (servidores de nombres autoritarios o resolutores recursivos). El objetivo es agotar los recursos del servidor, haciendo que el servicio DNS no esté disponible e impidiendo que los usuarios legítimos resuelvan nombres de dominio.
Impacto de los ataques de inundación DNS
Cuando los servidores DNS se ven abrumados:
Normal operation:
User → DNS query → DNS server → Response → Website loads
During DNS flood:
User → DNS query → DNS server (overwhelmed, no response)
→ Website doesn't load (even though web server is fine)
Efectos:
- Los sitios web se vuelven inaccesibles (aunque los servidores web estén operativos)
- La entrega de correo electrónico falla (las búsquedas de registros MX fallan)
- Las APIs y servicios que dependen de DNS se vuelven inaccesibles
- Daños colaterales a la infraestructura DNS compartida
Tipos de ataques de inundación DNS
Inundación directa de consultas DNS
El atacante envía consultas DNS legítimas en volumen alto:
Botnet → Millions of DNS queries → Target DNS server
Query examples:
example.com A
www.example.com A
random1.example.com A
random2.example.com A
...millions more...
Características:
- Consultas DNS válidas (difíciles de filtrar)
- A menudo para subdominios aleatorios (omitir caché)
- Utiliza botnets para ataque distribuido
Ataque de amplificación DNS
Explota resolutores recursivos para amplificar el tráfico de ataque:
1. Attacker sends small query to open resolver
2. Spoofs source IP as victim's IP
3. Resolver sends large response to victim
4. Attacker amplifies bandwidth 28-54x
Ejemplo:
Attacker sends: 60-byte query for TXT record (ANY query)
Resolver sends: 3000-byte response to victim
Amplification: 50x
Inundación NXDOMAIN
Consultas de dominios inexistentes para omitir el caché:
Query: random-12345.example.com (doesn't exist)
Server must check authoritative zone every time
Cannot be cached (NXDOMAIN responses often have low TTL)
Consumes more server resources than cached responses
Ataque de dominio fantasma
Consultas de dominios legítimos que no responden:
Attacker: Queries resolver for slow/non-responsive domains
Resolver: Waits for timeout, consumes resources
Result: Resolver resource exhaustion
Ataque de subdominio aleatorio
Consultas de subdominios aleatorios para evitar aciertos en caché:
Query: abc123random.example.com
Query: xyz789random.example.com
Query: def456random.example.com
Each is unique → cache miss → authoritative query
Overwhelms authoritative nameservers
Vectores de ataque y técnicas
Ataques impulsados por botnet
Compromised devices:
- IoT devices (cameras, routers)
- Infected computers
- Hacked servers
Distributed attack:
10,000 bots × 100 queries/sec = 1 million queries/sec
Ataques de reflexión
Attacker spoofs victim's IP
Sends queries to many open resolvers
Resolvers respond to victim with large answers
Victim receives amplified traffic
Inundaciones de capa de aplicación
Legitimate-looking queries
Difficult to distinguish from real traffic
May target specific resource-intensive query types
Detección de ataques de inundación DNS
Volumen de consultas inusual
Normal baseline: 10,000 queries/second
During attack: 500,000+ queries/second
Monitorear:
# Check query rate (BIND)
rndc status | grep "queries resulted"
# Analyze query logs
tail -f /var/log/named/queries.log | wc -l
Tasa alta de NXDOMAIN
Normal: 5-10% NXDOMAIN responses
Attack: 50-90% NXDOMAIN responses (random subdomain flood)
Distribución de IP de origen
Legitimate: Diverse source IPs, geographic spread
Attack: Concentrated sources, unusual geographic patterns
Patrones de consulta
Legitimate: Repetitive queries (common domains cached)
Attack: Unique queries (random strings, no cache benefit)
Degradación del tiempo de respuesta
Normal: < 50ms response time
Under attack: > 1000ms or timeouts
Mitigación de ataques de inundación DNS
Defensas a nivel de infraestructura
#### Anycast DNS
Distribuir tráfico en múltiples ubicaciones geográficas:
Single IP address (e.g., 1.2.3.4) announced from multiple locations
Attack traffic automatically routed to nearest server
Load distributed across global network
Harder to overwhelm all locations simultaneously
Beneficios:
- Distribución automática de carga
- Resiliencia geográfica
- Absorción de tráfico de ataque
#### Infraestructura DNS de gran tamaño
Capacity: 10x normal peak traffic
Reserves: Handle sudden spikes
Auto-scaling: Add capacity during attacks
#### Limitación de tasa
# BIND rate limiting (response-rate limiting)
rate-limit {
responses-per-second 10;
window 5;
slip 2;
};
Limita las respuestas desde la misma fuente para prevenir ataques de amplificación.
#### Filtrado de consultas
# Block ANY queries (common in amplification)
# Block excessively long queries
# Block known-malicious patterns
Ejemplo BIND:
# Block ANY queries
match-query {
type ANY;
action drop;
};
Defensas a nivel de proveedor DNS
#### DNSSEC
Aunque no previene directamente las inundaciones, DNSSEC:
- Previene envenenamiento de caché durante ataques
- Mantiene la integridad bajo condiciones de ataque
#### Configuración de maestro oculto
Master server (hidden): 10.0.0.1 (not publicly known)
Slave servers (public): ns1.example.com, ns2.example.com
Attackers target slaves
Master remains operational
Can quickly update slaves if needed
#### Firewall DNS / IDS
Analyze queries in real-time
Block suspicious patterns
Whitelist known-good clients
Blacklist attack sources
Protecciones a nivel de aplicación
#### Limitación de tasa de respuesta (RRL)
Limit identical responses to same client
Prevents amplification attacks
Slip mode: Occasionally allow queries through (to not break legitimate recursive resolvers)
Configuración BIND:
options {
rate-limit {
responses-per-second 5;
referrals-per-second 5;
nodata-per-second 5;
nxdomains-per-second 5;
errors-per-second 5;
window 5;
};
};
#### Optimización de caché
Increase cache size to absorb repeated queries
Longer TTLs where appropriate (trade-off with agility)
Prefetch popular records
#### Filtrado de consultas
# Drop queries for non-existent zones
# Block queries from known-bad sources
# Rate-limit per-source queries
Defensas a nivel de red
#### Blackholing de BGP
Route attack traffic to null0
Sacrifice availability to preserve infrastructure
Last resort when attack overwhelms capacity
#### Filtrado de ISP aguas arriba
Coordinate with ISP to filter attack traffic
Source IP validation (prevent spoofing)
Traffic scrubbing centers
#### Servicios de mitigación DDoS
Cloudflare, Akamai, AWS Shield
Absorb attack traffic before reaching your servers
Global capacity to withstand large attacks
Mejores prácticas para la resiliencia de DNS
Utilizar múltiples proveedores DNS
Primary provider: Cloudflare
Secondary provider: AWS Route 53
If one is attacked/down, other continues serving
Different infrastructure reduces single point of failure
Implementar DNSSEC
Protects against DNS spoofing/cache poisoning
Maintains integrity during attacks
Build trust even under attack conditions
Monitorear el rendimiento de DNS
Real-time query rates
Response times
NXDOMAIN percentages
Geographic distribution of queries
Error rates
Herramientas: Grafana + Prometheus, Datadog, AWS CloudWatch
Prueba de capacidad regular
Load testing: Can infrastructure handle 10x traffic?
Failover testing: Do secondary providers activate correctly?
Attack simulation: Test mitigation strategies
Desactivar recursión en servidores autoritarios
# BIND
recursion no;
Los servidores de nombres autoritarios no deben actuar como resolutores recursivos.
Restringir transferencias de zona
# BIND
allow-transfer { 10.0.0.2; 10.0.0.3; }; # Only specific slaves
Evitar que los atacantes descarguen la zona completa.
Mantener el software actualizado
Regularly update DNS server software
Patch known vulnerabilities
Subscribe to security advisories
Respuesta a un ataque de inundación DNS activo
Acciones inmediatas
1. Verificar que el ataque está ocurriendo
# Check query rate
rndc status
# Check load
top
2. Habilitar limitación de tasa
# BIND: Enable RRL if not already active
rndc addzone rate-limit
3. Contactar con proveedor de mitigación DDoS
- Activar servicios de depuración
- Redirigir tráfico a través de la red de mitigación
4. Analizar patrones de ataque
# Top query types
grep "query" /var/log/named/queries.log | awk '{print $6}' | sort | uniq -c | sort -rn | head -20
# Top queried domains
grep "query" /var/log/named/queries.log | awk '{print $7}' | sort | uniq -c | sort -rn | head -20
5. Bloquear fuentes de ataque obvias
# Identify top source IPs
grep "query" /var/log/named/queries.log | awk '{print $5}' | cut -d# -f1 | sort | uniq -c | sort -rn | head -50
# Block at firewall
iptables -A INPUT -s ATTACKER_IP -j DROP
Acciones a medio plazo
1. Escalar infraestructura
- Añadir más capacidad de servidor de nombres
- Distribuir vía anycast si no está ya activado
2. Implementar filtrado adicional
- Bloquear patrones de consulta específicos del ataque
- Incluir en lista blanca fuentes conocidas como buenas
3. Coordinar con proveedores
- Proveedor de ISP/hosting
- Proveedor DNS
- Servicio de mitigación DDoS
4. Documentar el ataque
- Capturas de paquetes
- Registros
- Gráficos de tráfico
- Para análisis posterior al incidente y propósitos legales
Análisis posterior al ataque
1. Revisar la efectividad de las mitigaciones
2. Identificar debilidades de infraestructura
3. Actualizar procedimientos de respuesta a incidentes
4. Considerar mejoras a largo plazo (DNS de múltiples proveedores, mayor capacidad)
Legal e informes
Informar a las autoridades
- FBI IC3 (EE.UU.): ic3.gov
- Unidades locales de ciberdelitos
- Departamentos de abuso de ISP
Recopilación de pruebas
# Packet captures
tcpdump -i eth0 -w dns-attack.pcap port 53
# Full query logs
tar -czf attack-logs-$(date +%Y%m%d).tar.gz /var/log/named/
# Traffic graphs/screenshots
# System resource usage
Los ataques de inundación DNS son una amenaza grave para los servicios en línea, pero con la infraestructura adecuada, monitoreo y estrategias de mitigación, su impacto se puede minimizar.