Inundación DNS

Seguridad y Amenazas
Un ataque de negación de servicio que abruma la infraestructura DNS con consultas excesivas.
← Volver al Glosario

¿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:

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:

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: Proveedores: Cloudflare, AWS Route 53, NS1, Dyn

#### 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:

#### 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

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.

Pon Este Conocimiento en Práctica

Usa la API de DomScan para comprobar disponibilidad de dominios, estado y mucho más.