Qu’est-ce que Inondation DNS ? Définition et exemples

Q: Qu'est-ce que Inondation DNS?

Une attaque par déni de service qui surcharge l'infrastructure DNS avec des requêtes excessives.

Qu'est-ce qu'une attaque par inondation DNS ?

Une inondation DNS est une attaque par déni de service distribué (DDoS) qui sature l'infrastructure DNS en envoyant un volume massif de requêtes DNS à des serveurs DNS, qu'il s'agisse de serveurs de noms faisant autorité ou de résolveurs récursifs. L'objectif est d'épuiser les ressources des serveurs, de rendre le service DNS indisponible et d'empêcher les utilisateurs légitimes de résoudre les noms de domaine.

Impact des attaques par inondation DNS

Lorsque les serveurs DNS sont saturés :

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)

Effets :

Les sites web deviennent inaccessibles, même si les serveurs web fonctionnent
La remise des e-mails échoue, car les recherches d'enregistrements MX échouent
Les API et services qui dépendent du DNS deviennent indisponibles
L'infrastructure DNS partagée peut subir des dommages collatéraux

Types d'attaques par inondation DNS

Inondation directe de requêtes DNS

L'attaquant envoie des requêtes DNS légitimes à un volume élevé :

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

Caractéristiques :

Requêtes DNS valides, difficiles à filtrer
Souvent dirigées vers des sous-domaines aléatoires pour contourner le cache
Utilisation de botnets pour distribuer l'attaque

Attaque par amplification DNS

L'attaque exploite des résolveurs récursifs afin d'amplifier le trafic :

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

Exemple :

Attacker sends: 60-byte query for TXT record (ANY query) Resolver sends: 3000-byte response to victim

Amplification: 50x

Inondation NXDOMAIN

Des requêtes vers des domaines inexistants contournent la mise en cache :

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

Attaque par domaine fantôme

L'attaquant interroge des domaines légitimes qui ne répondent pas :

Attacker: Queries resolver for slow/non-responsive domains Resolver: Waits for timeout, consumes resources

Result: Resolver resource exhaustion

Attaque par sous-domaines aléatoires

Des sous-domaines aléatoires sont utilisés pour éviter les réponses du cache :

Query: abc123random.example.com Query: xyz789random.example.com Query: def456random.example.com Each is unique → cache miss → authoritative query

Overwhelms authoritative nameservers

Vecteurs et techniques d'attaque

Attaques pilotées par un botnet

Compromised devices: IoT devices (cameras, routers) Infected computers Hacked servers Distributed attack:

10,000 bots × 100 queries/sec = 1 million queries/sec

Attaques par réflexion

Attacker spoofs victim's IP Sends queries to many open resolvers Resolvers respond to victim with large answers

Victim receives amplified traffic

Inondations au niveau applicatif

Legitimate-looking queries Difficult to distinguish from real traffic

May target specific resource-intensive query types

Détecter les attaques par inondation DNS

Volume inhabituel de requêtes

Normal baseline: 10,000 queries/second

During attack: 500,000+ queries/second

Surveillance :

# Check query rate (BIND)
rndc status | grep "queries resulted"

# Analyze query logs
tail -f /var/log/named/queries.log | wc -l

Taux élevé de NXDOMAIN

Normal: 5-10% NXDOMAIN responses

Attack: 50-90% NXDOMAIN responses (random subdomain flood)

Répartition des adresses IP sources

Legitimate: Diverse source IPs, geographic spread

Attack: Concentrated sources, unusual geographic patterns

Profils de requêtes

Legitimate: Repetitive queries (common domains cached)
Attack: Unique queries (random strings, no cache benefit)

Dégradation du temps de réponse

Normal: < 50ms response time
Under attack: > 1000ms or timeouts

Atténuer les attaques par inondation DNS

Défenses au niveau de l'infrastructure

#### DNS Anycast

Répartir le trafic entre plusieurs emplacements géographiques :

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

Avantages :

Répartition automatique de la charge
Résilience géographique
Absorption du trafic d'attaque

Fournisseurs : Cloudflare, AWS Route 53, NS1, Dyn

#### Infrastructure DNS surdimensionnée

Capacity: 10x normal peak traffic Reserves: Handle sudden spikes

Auto-scaling: Add capacity during attacks

#### Limitation de débit

# BIND rate limiting (response-rate limiting)
rate-limit {
    responses-per-second 10;
    window 5;
    slip 2;
};

Limiter les réponses provenant d'une même source afin de prévenir les attaques par amplification.

#### Filtrage des requêtes

# Block ANY queries (common in amplification) # Block excessively long queries

# Block known-malicious patterns

Exemple BIND :

# Block ANY queries
match-query {
    type ANY;
    action drop;
};

Défenses au niveau du fournisseur DNS

#### DNSSEC

DNSSEC n'empêche pas directement les inondations, mais :

empêche l'empoisonnement du cache pendant les attaques
préserve l'intégrité des données dans ces conditions

#### Configuration d'un serveur maître caché

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

#### Pare-feu DNS et IDS

Analyze queries in real-time Block suspicious patterns Whitelist known-good clients

Blacklist attack sources

Protections au niveau applicatif

#### Limitation du débit des réponses (RRL)

Limit identical responses to same client Prevents amplification attacks

Slip mode: Occasionally allow queries through (to not break legitimate recursive resolvers)

Configuration 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;
    };
};

#### Optimisation du cache

Increase cache size to absorb repeated queries Longer TTLs where appropriate (trade-off with agility)

Prefetch popular records

#### Filtrage des requêtes

# Drop queries for non-existent zones # Block queries from known-bad sources

# Rate-limit per-source queries

Défenses au niveau du réseau

#### Blackholing BGP

Route attack traffic to null0 Sacrifice availability to preserve infrastructure

Last resort when attack overwhelms capacity

#### Filtrage par le fournisseur amont

Coordinate with ISP to filter attack traffic Source IP validation (prevent spoofing)

Traffic scrubbing centers

#### Services d'atténuation DDoS

Cloudflare, Akamai, AWS Shield Absorb attack traffic before reaching your servers

Global capacity to withstand large attacks

Bonnes pratiques pour la résilience DNS

Utiliser plusieurs fournisseurs DNS

Primary provider: Cloudflare Secondary provider: AWS Route 53 If one is attacked/down, other continues serving

Different infrastructure reduces single point of failure

Mettre en œuvre DNSSEC

Protects against DNS spoofing/cache poisoning Maintains integrity during attacks

Build trust even under attack conditions

Surveiller les performances DNS

Real-time query rates Response times NXDOMAIN percentages Geographic distribution of queries

Error rates

Outils : Grafana + Prometheus, Datadog, AWS CloudWatch

Tester régulièrement la capacité

Load testing: Can infrastructure handle 10x traffic? Failover testing: Do secondary providers activate correctly?

Attack simulation: Test mitigation strategies

Désactiver la récursion sur les serveurs faisant autorité

# BIND
recursion no;

Les serveurs de noms faisant autorité ne doivent pas agir comme des résolveurs récursifs.

Restreindre les transferts de zone

# BIND
allow-transfer { 10.0.0.2; 10.0.0.3; };  # Only specific slaves

Empêcher les attaquants d'extraire la zone entière.

Maintenir les logiciels à jour

Regularly update DNS server software Patch known vulnerabilities

Subscribe to security advisories

Réagir à une attaque par inondation DNS en cours

Mesures immédiates

1. Vérifier qu'une attaque est en cours

# Check query rate rndc status # Check load

top

2. Activer la limitation de débit

# BIND: Enable RRL if not already active

rndc addzone rate-limit

3. Contacter le fournisseur d'atténuation DDoS

- Activer les services de nettoyage

- Rediriger le trafic vers le réseau d'atténuation

4. Analyser les schémas de l'attaque

# 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. Bloquer les sources d'attaque évidentes

# 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

Actions à moyen terme

1. Mettre l'infrastructure à l'échelle

- Ajouter de la capacité aux serveurs de noms

- Distribuer le trafic avec Anycast si ce n'est pas déjà fait

2. Mettre en place un filtrage supplémentaire

- Bloquer les schémas de requêtes propres à l'attaque

- Autoriser sur liste blanche les sources fiables

3. Se coordonner avec les fournisseurs

- FAI ou hébergeur

- Fournisseur DNS

- Service d'atténuation DDoS

4. Documenter l'attaque

- Captures de paquets

- Journaux

- Graphiques de trafic

- Pour l'analyse post-incident et les besoins juridiques

Analyse après l'attaque

1. Évaluer l'efficacité des mesures d'atténuation

2. Identifier les faiblesses de l'infrastructure

3. Mettre à jour les procédures de réponse aux incidents

4. Examiner les améliorations à long terme (DNS multi-fournisseurs, capacité accrue)

Aspects juridiques et signalement

Signaler aux autorités

FBI IC3 (États-Unis) : ic3.gov
Unités locales de lutte contre la cybercriminalité
Services de signalement des abus des FAI

Collecter les éléments de preuve

# 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

Les inondations DNS constituent une menace sérieuse pour les services en ligne, mais une infrastructure adaptée, une surveillance active et des stratégies d'atténuation permettent d'en limiter les effets.