¿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:
Operación normal:
Usuario → consulta DNS → servidor DNS → respuesta → sitio web se carga
Durante la inundación DNS:
Usuario → consulta DNS → servidor DNS (abrumado, sin respuesta)
→ el sitio web no se carga (aunque el servidor web esté bien)
- 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 → Millones de consultas DNS → servidor DNS objetivo
Ejemplos de consultas:
example.com A
www.example.com A
random1.example.com A
random2.example.com A
...millones más...
- 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. El atacante envía una consulta pequeña a un resolutor abierto
2. Falsifica la IP de origen como la IP de la víctima
3. El resolutor envía una respuesta grande a la víctima
4. El atacante amplifica el ancho de banda 28-54 veces
El atacante envía: consulta de 60 bytes para registro TXT (consulta ANY)
El resolutor envía: respuesta de 3000 bytes a la víctima
Amplificación: 50 veces
Inundación NXDOMAIN
Consultas de dominios inexistentes para omitir el caché:
Consulta: random-12345.example.com (no existe)
El servidor debe comprobar la zona autoritaria cada vez
No se puede almacenar en caché (las respuestas NXDOMAIN a menudo tienen TTL bajo)
Consumeré más recursos del servidor que las respuestas en caché
Ataque de dominio fantasma
Consultas de dominios legítimos que no responden:
Atacante: consulta el resolutor para dominios lentos/sin respuesta
Resolutor: espera a que se agote el tiempo, consume recursos
Resultado: agotamiento de recursos del resolutor
Ataque de subdominio aleatorio
Consultas de subdominios aleatorios para evitar aciertos en caché:
Consulta: abc123random.example.com
Consulta: xyz789random.example.com
Consulta: def456random.example.com
Cada uno es único → fallo de caché → consulta autoritaria
Abruma los servidores de nombres autoritarios
Vectores de ataque y técnicas
Ataques impulsados por botnet
Dispositivos comprometidos:
- Dispositivos IoT (cámaras, enrutadores)
- Ordenadores infectados
- Servidores pirateados
Ataque distribuido:
10.000 bots × 100 consultas/seg = 1 millón de consultas/seg
Ataques de reflexión
El atacante falsifica la IP de la víctima
Envía consultas a muchos resolutores abiertos
Los resolutores responden a la víctima con respuestas grandes
La víctima recibe tráfico amplificado
Inundaciones de capa de aplicación
Consultas con apariencia legítima
Difícil de distinguir del tráfico real
Puede dirigirse a tipos de consulta que requieren muchos recursos
Detección de ataques de inundación DNS
Volumen de consultas inusual
Línea base normal: 10.000 consultas/segundo
Durante el ataque: 500.000+ consultas/segundo
# Comprobar tasa de consultas (BIND)
rndc status | grep "queries resulted"
# Analizar registros de consultas
tail -f /var/log/named/queries.log | wc -l
Tasa alta de NXDOMAIN
Normal: 5-10% de respuestas NXDOMAIN
Ataque: 50-90% de respuestas NXDOMAIN (inundación de subdominio aleatorio)
Distribución de IP de origen
Legítimo: IPs de origen diversas, dispersión geográfica
Ataque: fuentes concentradas, patrones geográficos inusuales
Patrones de consulta
Legítimo: consultas repetitivas (dominios comunes en caché)
Ataque: consultas únicas (cadenas aleatorias, sin beneficio de caché)
Degradación del tiempo de respuesta
Normal: tiempo de respuesta < 50ms
Bajo ataque: tiempo de respuesta > 1000ms o agotamientos
Mitigación de ataques de inundación DNS
Defensas a nivel de infraestructura
#### Anycast DNS
Distribuir tráfico en múltiples ubicaciones geográficas:
Dirección IP única (p. ej., 1.2.3.4) anunciada desde múltiples ubicaciones
El tráfico de ataque se enruta automáticamente al servidor más cercano
Carga distribuida en toda la red global
Más difícil de abrumar todas las ubicaciones simultáneamente
- Distribución automática de carga
- Resiliencia geográfica
- Absorción de tráfico de ataque
#### Infraestructura DNS de gran tamaño
Capacidad: 10 veces el tráfico máximo normal
Reservas: manejar picos repentinos
Escalado automático: añadir capacidad durante ataques
#### Limitación de tasa
# Límite de tasa BIND (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
# Bloquear consultas ANY (común en amplificación)
# Bloquear consultas excesivamente largas
# Bloquear patrones conocidos como maliciosos
# Bloquear consultas ANY
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
Servidor maestro (oculto): 10.0.0.1 (no conocido públicamente)
Servidores esclavo (público): ns1.example.com, ns2.example.com
Los atacantes atacan los esclavos
El maestro permanece operativo
Puede actualizar rápidamente los esclavos si es necesario
#### Firewall DNS / IDS
Analizar consultas en tiempo real
Bloquear patrones sospechosos
Incluir en lista blanca clientes conocidos
Incluir en lista negra fuentes de ataque
Protecciones a nivel de aplicación
#### Limitación de tasa de respuesta (RRL)
Limitar respuestas idénticas al mismo cliente
Prevenir ataques de amplificación
Modo slip: ocasionalmente permitir que las consultas pasen (para no romper resolutores recursivos legítimos)
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é
Aumentar el tamaño de la caché para absorber consultas repetidas
TTLs más largo si es apropiado (compensación con agilidad)
Prefetch de registros populares
#### Filtrado de consultas
# Descartar consultas para zonas inexistentes
# Bloquear consultas de fuentes conocidas como malas
# Limitar tasa de consultas por fuente
Defensas a nivel de red
#### Blackholing de BGP
Enrutar tráfico de ataque a null0
Sacrificar disponibilidad para preservar infraestructura
Último recurso cuando el ataque abruma la capacidad
#### Filtrado de ISP aguas arriba
Coordenarse con el ISP para filtrar el tráfico de ataque
Validación de IP de origen (prevenir falsificación)
Centros de depuración de tráfico
#### Servicios de mitigación DDoS
Cloudflare, Akamai, AWS Shield
Absorber tráfico de ataque antes de llegar a tus servidores
Capacidad global para resistir ataques grandes
Mejores prácticas para la resiliencia de DNS
Utilizar múltiples proveedores DNS
Proveedor principal: Cloudflare
Proveedor secundario: AWS Route 53
Si uno está bajo ataque/caído, el otro continúa sirviendo
La infraestructura diferente reduce el punto único de fallo
Implementar DNSSEC
Protege contra suplantación de DNS/envenenamiento de caché
Mantiene la integridad durante ataques
Construir confianza incluso bajo condiciones de ataque
Monitorear el rendimiento de DNS
Tasas de consulta en tiempo real
Tiempos de respuesta
Porcentajes de NXDOMAIN
Distribución geográfica de consultas
Tasas de error
Prueba de capacidad regular
Prueba de carga: ¿Puede la infraestructura manejar 10 veces el tráfico?
Prueba de conmutación por error: ¿Se activan correctamente los proveedores secundarios?
Simulación de ataque: Prueba estrategias de mitigación
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; }; # Solo esclavos específicos
Evitar que los atacantes descarguen la zona completa.
Mantener el software actualizado
Actualizar regularmente el software del servidor DNS
Parchear vulnerabilidades conocidas
Suscribirse a avisos de seguridad
Respuesta a un ataque de inundación DNS activo
Acciones inmediatas
1. Verificar que el ataque está ocurriendo
# Comprobar tasa de consultas
rndc status
# Comprobar carga
top
2. Habilitar limitación de tasa
# BIND: habilitar RRL si no está ya activo
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
# Tipos de consulta principales
grep "query" /var/log/named/queries.log | awk '{print $6}' | sort | uniq -c | sort -rn | head -20
# Dominios consultados principales
grep "query" /var/log/named/queries.log | awk '{print $7}' | sort | uniq -c | sort -rn | head -20
5. Bloquear fuentes de ataque obvias
# Identificar IPs de origen principales
grep "query" /var/log/named/queries.log | awk '{print $5}' | cut -d# -f1 | sort | uniq -c | sort -rn | head -50
# Bloquear en 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
# Capturas de paquetes
tcpdump -i eth0 -w dns-attack.pcap port 53
# Registros completos de consultas
tar -czf attack-logs-$(date +%Y%m%d).tar.gz /var/log/named/
# Gráficos de tráfico/capturas de pantalla
# Uso de recursos del sistema
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.