Bases de l’empoisonnement du cache DNS : durcir votre résolveur sans suringénierie

Ce qu’est réellement l’empoisonnement du cache (et ce que ce n’est pas)

« L’empoisonnement du cache DNS » survient lorsqu’un résolveur récursif conserve une réponse falsifiée et la sert aux clients jusqu’à son expiration (ou son éviction).
Le mot clé est cache. L’attaquant n’a pas besoin de compromettre votre serveur DNS autoritaire pour vous nuire ; il suffit que votre résolveur croie un mensonge assez longtemps.

Cela se distingue de :

• Détournement chez le registrar (quelqu’un change les enregistrements NS chez le registrar). Ce n’est pas de l’empoisonnement du cache ; c’est une compromission de compte.
• Altération en interception (MITM réécrivant les réponses DNS). C’est une attaque réseau ; le cache peut l’amplifier, mais la cause racine est l’interception du trafic.
• Mauvaise configuration (enregistrements A/AAAA erronés, TTL obsolètes, surprises de split-horizon). Depuis la chaise du client, ça ressemble exactement à la même chose.
• Tempêtes NXDOMAIN (beaucoup de réponses négatives). Ce n’est pas de l’empoisonnement ; c’est tout de même douloureux.

L’empoisonnement importe parce que le DNS est un système de distribution de confiance qui précède les modèles de menace modernes. Il a été conçu pour la fiabilité et
l’échelle, pas pour des adversaires actifs. Nous y avons ajouté des défenses. Elles fonctionnent, mais seulement si vous les activez et ne les sabotez pas avec des
optimisations « utiles ».

Le rayon d’impact est déterminé par deux décisions que vous contrôlez :

• Qui peut interroger votre résolveur ? Si vous exécutez un résolveur ouvert, vous transformez les problèmes des inconnus en vos problèmes.
• Avec quelle rigueur le résolveur valide-t-il les réponses ? La validation DNSSEC et des règles de bailiwick sensées transforment de nombreuses tentatives d’empoisonnement en bruit inoffensif.

Petite blague #1 : le DNS, c’est comme les commérages au bureau : une fois que la mauvaise info atteint le cache, tout le monde la répète avec une confiance absolue.

Comment fonctionne l’empoisonnement : des suppositions à la persistance

Un résolveur récursif interroge des serveurs en amont et met en cache les réponses. Les attaquants veulent insérer une fausse réponse dans ce cache.
Historiquement, l’empoisonnement consistait à faire la course avec la vraie réponse en envoyant une réponse falsifiée et à gagner la confiance du résolveur.

Les éléments qui rendent l’empoisonnement possible

Une réponse DNS falsifiée doit correspondre à ce que le résolveur attend : l’ID de transaction, le port source et la section question.
Les anciens résolveurs utilisaient des IDs prévisibles et des ports fixes. Cela réduisait l’espace de devinette à quelque chose qu’un attaquant pouvait forcer.
Les résolveurs modernes randomisent les IDs et les ports sources, rendant le guessing hors-chemin beaucoup plus difficile.

Mais « plus difficile » n’est pas « impossible ». Les attaquants recherchent :

• Des appareils NAT qui écrasent les ports sources (la randomisation de port est neutralisée par des middleboxes).
• Des canaux latéraux qui fuient des informations sur le port ou l’ID.
• Des configurations de forwarder faibles (forwarders qui acceptent des données corrompues ou qui ne valident pas DNSSEC).
• Des résolveurs mal configurés qui acceptent des enregistrements additionnels hors-bailiwick (vecteur classique d’empoisonnement).
• Des TTL longs qui rendent une victoire unique durable.

Pourquoi la section « additional » compte (et pourquoi bailiwick est un mot d’adulte)

Les réponses DNS peuvent contenir des enregistrements supplémentaires dans la section « additional », comme des A glue pour des serveurs de noms.
Un résolveur devrait être strict sur ce qu’il met en cache à partir de là. La règle empirique est le « bailiwick » : mettre en cache les données additionnelles seulement si elles sont dans
l’autorité du serveur qui les a fournies, et même alors avec prudence.

L’empoisonnement tente souvent de faire passer quelque chose comme :

• Un enregistrement A pour www.victim.com dans une réponse qui ne devrait pas être autoritaire pour ce nom.
• Un enregistrement NS pointant victim.com vers un serveur de noms contrôlé par l’attaquant, plus le glue pour ce serveur de noms.

Une fois qu’un résolveur met en cache une délégation malveillante (NS empoisonné), l’attaquant obtient un levier : les requêtes futures peuvent être dirigées vers ses serveurs,
qui peuvent répondre de façon cohérente et « légitime » du point de vue du résolveur. C’est à ce moment que l’incident devient persistant.

DNSSEC change la donne — si vous validez vraiment

DNSSEC ajoute des signatures aux données DNS pour qu’un résolveur validant puisse détecter la falsification. Ce n’est pas du chiffrement. Cela n’empêche pas quelqu’un d’apprendre ce que vous interrogez.
Cela ne protège pas non plus les zones non signées, et peut être contourné par une mauvaise gestion de la racine de confiance ou par la validation désactivée « temporairement ».

Activer la validation DNSSEC, c’est comme mettre sa ceinture de sécurité. Ça ne vous rend pas invincible, mais l’alternative, c’est de compter sur la bienveillance de la physique.

Une citation, parce que l’exploitation est un sport de contact : « L’espoir n’est pas une stratégie. » — Vince Lombardi.

Anecdotes et contexte historique (court et concret)

• Le DNS est plus vieux que le web : le DNS a été standardisé dans les années 1980 ; HTTP est venu plus tard. Le modèle de menace visait « le réseau d’un campus », pas « l’adversaire global ».
• 2008 a été un tournant : la divulgation de Dan Kaminsky a montré l’empoisonnement du cache à grande échelle, forçant des correctifs et la randomisation généralisée.
• La randomisation du port source est devenue la norme après cette époque parce que des IDs transactionnels de 16 bits seuls étaient devinables avec assez d’essais.
• Le « 0x20 encoding » existe : certains résolveurs randomisent la casse des lettres dans les requêtes pour ajouter de l’entropie ; c’est ingénieux mais pas un substitut à une vraie validation.
• Le NAT peut saboter la sécurité : certains anciens NAT réécrivaient les ports sources de manière prévisible, réduisant l’entropie dont vous pensiez disposer.
• Le chiffrement DNSSEC a été conçu dans les années 1990 de façon conceptuelle, mais le déploiement réel a pris des années à cause de la complexité opérationnelle et de la gestion des clés.
• La zone racine a été signée en 2010, ce qui a rendu la validation DNSSEC de bout en bout viable sans hacks de confiance personnalisés.
• La mise en cache négative est normalisée (comportement SOA minimum / TTL négatif). C’est essentiel pour l’échelle et aussi une source courante de confusion « pourquoi ça ne résout pas encore ? ».
• Les résolveurs sont des amplificateurs DDoS lorsqu’ils sont ouverts : pas de l’empoisonnement, mais lié : la récursion ouverte transforme votre infra en arme d’autrui.

Plan de diagnostic rapide

Vous êtes d’astreinte. Quelque chose sent le DNS. Ne noyez pas le poisson. Faites cela dans l’ordre et arrêtez-vous quand vous trouvez le cratère fumant.

Première étape : déterminer si le résolveur ment ou si l’amont change

1. Interrogez votre résolveur et un résolveur externe de confiance pour le même nom et comparez la réponse et le TTL.
2. Vérifiez l’état de validation DNSSEC (est-elle activée et échoue-t-elle ?)
3. Tracez la délégation (êtes-vous envoyé vers des serveurs NS inattendus ?)

Deuxième étape : chercher la persistance et l’étendue du cache

1. Vérifiez le comportement du TTL : la mauvaise réponse décroît-elle (mise en cache) ou fluctue-t-elle (amont) ?
2. Vérifiez plusieurs clients/sous-réseaux : est-ce un nœud résolveur, un site ou partout ?
3. Vérifiez si un forwarder est impliqué : beaucoup de déploiements « résolveur » sont juste des forwarders avec des étapes en plus.

Troisième étape : confirmez que ce n’est pas auto-infligé

1. Cherchez dans les diffs de gestion de configuration des modifications DNS (forwarders, vues, ACL, bascule DNSSEC).
2. Vérifiez les collisions split-horizon (zone interne qui masque l’externe).
3. Inspectez le comportement NAT/firewall si vous suspectez un risque d’empoisonnement hors-chemin (réécriture de ports, timeouts UDP).

L’objectif : séparer « cache empoisonné » de « la vérité autoritaire a changé » de « nous nous sommes plantés ». Ce sont trois classes d’incident différentes.

Tâches pratiques : commandes, sorties et la décision que vous prenez

Celles-ci sont volontairement pratiques. Exécutez-les sur un hôte client et sur l’hôte résolveur. Comparez les sorties. Prenez des décisions.
J’utiliserai 10.0.0.53 comme IP du résolveur récursif interne et resolver1 comme nom d’hôte.

Task 1 — Confirmer quel résolveur votre hôte utilise réellement

cr0x@server:~$ resolvectl status
Global
       Protocols: -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
resolv.conf mode: stub
Current DNS Server: 10.0.0.53
       DNS Servers: 10.0.0.53 10.0.0.54

Ce que cela signifie : Cet hôte envoie le DNS à 10.0.0.53 (primaire) et 10.0.0.54 (secondaire).
DNSSEC ici concerne le résolveur stub et peut indiquer « unsupported » même si la récursion valide en amont.

Décision : Si le « Current DNS Server » n’est pas le résolveur prévu, arrêtez-vous et corrigez les paramètres DHCP/systemd-resolved.
Déboguer l’empoisonnement sur la mauvaise machine, c’est finir par accuser la lune.

Task 2 — Comparer la réponse de votre résolveur à une référence externe connue

cr0x@server:~$ dig @10.0.0.53 www.example.com A +noall +answer +ttlid
www.example.com.  296  IN  A  203.0.113.50

cr0x@server:~$ dig @1.1.1.1 www.example.com A +noall +answer +ttlid
www.example.com.  300  IN  A  93.184.216.34

Ce que cela signifie : Votre résolveur renvoie une IP différente d’un résolveur public. C’est soit de l’empoisonnement, soit du split-horizon, soit une divergence en amont.

Décision : Si le domaine doit être public et cohérent, traitez cela comme un incident et poursuivez. S’il est intentionnellement interne, documentez-le et passez à autre chose.

Task 3 — Vérifier si la mauvaise réponse est mise en cache (TTL qui décroît)

cr0x@server:~$ dig @10.0.0.53 www.example.com A +noall +answer +ttlid
www.example.com.  296  IN  A  203.0.113.50

cr0x@server:~$ sleep 5; dig @10.0.0.53 www.example.com A +noall +answer +ttlid
www.example.com.  291  IN  A  203.0.113.50

Ce que cela signifie : Le TTL qui décroît indique que le résolveur sert depuis le cache.

Décision : Une mauvaise réponse en cache implique qu’il faut purger/vider le cache (avec précaution) et trouver la cause racine. Si le TTL remonte, votre résolveur le récupère à répétition depuis quelque part.

Task 4 — Tracer la délégation pour voir d’où viennent les réponses

cr0x@server:~$ dig +trace www.example.com A
; <<>> DiG 9.18.24 <<>> +trace www.example.com A
;; global options: +cmd
.                       3600    IN      NS      a.root-servers.net.
...
example.com.            172800  IN      NS      a.iana-servers.net.
example.com.            172800  IN      NS      b.iana-servers.net.
www.example.com.        300     IN      A       93.184.216.34

Ce que cela signifie : +trace contourne le cache de votre résolveur et effectue la résolution itérative depuis la racine.
Si +trace donne l’enregistrement correct mais que votre résolveur non, le résolveur est suspect.

Décision : Si le trace est correct mais que la réponse du résolveur diffère, inspectez l’empoisonnement du cache ou une substitution interne. Si le trace est aussi « faux », la vérité autoritaire a changé ou votre réseau intercepte le DNS.

Task 5 — Demander le statut de validation DNSSEC dans la réponse

cr0x@server:~$ dig @10.0.0.53 www.example.com A +dnssec +noall +answer +comments
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 42012
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
www.example.com.  300  IN  A  93.184.216.34

Ce que cela signifie : Vous ne voyez pas le drapeau ad (Authenticated Data). Cela peut signifier que la validation DNSSEC est désactivée, non supportée pour ce nom, ou que votre résolveur n’est pas validant.

Décision : Si vous attendez une validation, confirmez-la sur le résolveur. Si vous ne l’attendez pas, décidez si c’est acceptable en 2025 (généralement non).

Task 6 — Sur Unbound, vérifier que DNSSEC est activé et fonctionne

cr0x@server:~$ sudo unbound-control status
version: 1.17.1
verbosity: 1
threads: 2
modules: 2 [subnetcache validator]
uptime: 18432 seconds
options: reuseport control(ssl)

Ce que cela signifie : La liste des modules inclut validator, signe que la validation DNSSEC est compilée et active.

Décision : Si vous ne voyez pas validator, vous ne validez pas. Corrigez la configuration avant de discuter de l’empoisonnement.

Task 7 — Sur BIND9, confirmer la récursion et qui peut l’utiliser

cr0x@server:~$ sudo named-checkconf -p | sed -n '1,120p'
options {
        recursion yes;
        allow-recursion { 10.0.0.0/8; 192.168.0.0/16; };
        allow-query-cache { 10.0.0.0/8; 192.168.0.0/16; };
        dnssec-validation auto;
        minimal-responses yes;
        ...
};

Ce que cela signifie : La récursion est activée (ok) mais limitée aux réseaux internes (également ok). dnssec-validation auto; est la valeur sûre par défaut.

Décision : Si allow-recursion est any; ou absent, considérez cela comme un problème de sécurité. La récursion ouverte est une invitation à l’abus et augmente votre exposition.

Task 8 — Vérifier les motifs SERVFAIL (souvent DNSSEC ou problèmes amont)

cr0x@server:~$ dig @10.0.0.53 badsig.example A +dnssec
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 61457
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

Ce que cela signifie : SERVFAIL peut signifier des échecs de validation, des timeouts ou des pannes amont. S’il corrèle avec des zones activées DNSSEC, c’est généralement la validation.

Décision : Vérifiez les logs du résolveur pour des erreurs DNSSEC ; ne désactivez pas simplement la validation pour « réparer » la production. C’est comme résoudre une alarme incendie en retirant les piles.

Task 9 — Vérifier que le résolveur ne transmet pas à un amont non fiable ou cassé

cr0x@server:~$ sudo ss -uapn | grep -E ':(53)\b'
UNCONN 0      0         10.0.0.53:53         0.0.0.0:*    users:(("unbound",pid=1187,fd=6))
UNCONN 0      0         10.0.0.53:49322      8.8.8.8:53   users:(("unbound",pid=1187,fd=9))
UNCONN 0      0         10.0.0.53:42617      1.1.1.1:53   users:(("unbound",pid=1187,fd=10))

Ce que cela signifie : Ce résolveur effectue des requêtes UDP/53 sortantes vers des résolveurs publics. C’est un design de forwarding, pas une récursion complète.

Décision : Décidez si le forwarding est intentionnel. Si vous transmettez, vous héritez du comportement de l’amont et réduisez votre capacité à faire une validation bout en bout et du troubleshooting clair.

Task 10 — Inspecter le comportement NAT qui peut réduire l’entropie des ports sources

cr0x@server:~$ sudo conntrack -L -p udp --dport 53 2>/dev/null | head
udp      17 25 src=10.0.0.53 dst=1.1.1.1 sport=42617 dport=53 src=1.1.1.1 dst=203.0.113.10 sport=53 dport=42617 [ASSURED]
udp      17 25 src=10.0.0.53 dst=8.8.8.8 sport=49322 dport=53 src=8.8.8.8 dst=203.0.113.10 sport=53 dport=49322 [ASSURED]

Ce que cela signifie : Vous pouvez voir les flux UDP et les ports sources. Si vous observez à répétition des ports séquentiels ou réutilisés à cause du NAT, vous perdez de l’entropie.

Décision : Si votre NAT est prévisible, corrigez la configuration NAT ou déplacez le résolveur pour qu’il préserve la randomisation.

Task 11 — Vérifier les statistiques Unbound pour anomalies de cache

cr0x@server:~$ sudo unbound-control stats_noreset | egrep 'num.cachehits|num.cachemiss|num.query|unwanted|cache'
num.query=1842099
num.cachehits=1320091
num.cachemiss=522008
unwanted.queries=183
unwanted.replies=91
msg.cache.count=76231
rrset.cache.count=54012

Ce que cela signifie : Un nombre élevé de cache hits est normal. Une augmentation de unwanted.replies peut indiquer des réponses usurpées arrivant qui ne correspondent pas à des requêtes en cours.

Décision : Si unwanted.replies monte en flèche, enquêtez sur des tentatives de spoofing réseau ou des appareils amont cassés. Ce n’est pas une preuve d’empoisonnement, mais c’est un indice à suivre.

Task 12 — Capturer le trafic DNS pour confirmer ce qui est sur le fil

cr0x@server:~$ sudo tcpdump -ni any udp port 53 -vv -c 5
tcpdump: listening on any, link-type LINUX_SLL2 (Linux cooked v2), snapshot length 262144 bytes
IP 10.0.0.53.42617 > 1.1.1.1.53: 42012+ A? www.example.com. (33)
IP 1.1.1.1.53 > 10.0.0.53.42617: 42012* 1/0/1 A 93.184.216.34 (49)
IP 10.0.0.53.49322 > 8.8.8.8.53: 1337+ DS? example.com. (29)
IP 8.8.8.8.53 > 10.0.0.53.49322: 1337 1/0/1 DS 370 13 2 49AAC11D... (68)
IP 203.0.113.66.53 > 10.0.0.53.42617: 42012 1/0/0 A 203.0.113.50 (49)

Ce que cela signifie : L’IP tierce 203.0.113.66 envoie une réponse qui correspond à l’ID de transaction et au port de la requête en attente.
Si cette IP n’est pas votre amont et qu’elle arrive avant la vraie, vous avez un problème sérieux : du spoofing se produit sur le chemin ou via une défaillance de routage/ACL.

Décision : Escaladez immédiatement : équipe réseau pour les ACLs/routage, équipe sécurité pour la réponse à incident, et isolez le résolveur si possible.

Task 13 — Vérifier les logs de requêtes BIND pour des clients inattendus et un abus de récursion

cr0x@server:~$ sudo rndc querylog
query logging is now on

cr0x@server:~$ sudo tail -n 5 /var/log/named/named.log
client @0x7f3c9c0a: query: randomstring.badness.example IN A +E(0)K (198.51.100.77)
client @0x7f3c9c0a: query: www.example.com IN A +E(0)K (10.10.14.22)
client @0x7f3c9c0a: query: api.internal.corp IN A +E(0)K (10.20.1.9)

Ce que cela signifie : Une IP publique interrogeant votre résolveur suggère une récursion ouverte ou une fuite de pare-feu. Notez aussi les sous-domaines aléatoires : cela peut être une tentative d’amplification ou de contournement de cache.

Décision : Si des IP publiques utilisent la récursion, bloquez immédiatement et corrigez les ACLs. C’est à la fois sécurité et stabilité.

Task 14 — Vérifier si vous divulguez des zones internes au monde (views / split horizon)

cr0x@server:~$ dig @10.0.0.53 api.internal.corp A +noall +answer
api.internal.corp.  60  IN  A  10.55.0.21

cr0x@server:~$ dig @1.1.1.1 api.internal.corp A +noall +comments
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 11610

Ce que cela signifie : Le nom interne existe seulement en interne. Bien. Mais si un résolveur externe retourne quelque chose, vous avez une collision ou une fuite.

Décision : Assurez-vous que les suffixes internes sont vraiment privés et ne rentrent pas en collision avec des TLD publics. Envisagez une stratégie de nommage interne réservée pour éviter les surprises.

Task 15 — Valider que votre résolveur rejette les données hors-bailiwick (test de sanité)

cr0x@server:~$ dig @10.0.0.53 ns1.example.com A +noall +authority +additional
example.com.     172800  IN  NS  a.iana-servers.net.
example.com.     172800  IN  NS  b.iana-servers.net.
a.iana-servers.net.  172800 IN A  199.43.135.53
b.iana-servers.net.  172800 IN A  199.43.133.53

Ce que cela signifie : La section additional contient des glue records pour les serveurs de noms. C’est attendu et en-bailiwick pour la chaîne de délégation.

Décision : Si vous voyez votre résolveur mettre en cache des enregistrements A additionnels non liés (pour des noms non impliqués dans la délégation), resserrez la configuration et mettez à jour le logiciel du résolveur.

Durcissement des résolveurs qui change la donne

Durcir les résolveurs revient principalement à adopter une pensée par défaut « refuser » et réduire l’ambiguïté. Vous n’essayez pas d’être brillant.
Vous essayez d’être ennuyeux, correct et résistant à la fois aux attaquants et aux « petites améliorations » de vos collègues.

1) Arrêtez d’exécuter une récursion ouverte (sérieusement)

Restreignez qui peut interroger et qui peut récursivement résoudre. Ce sont deux ACL différentes. Faites-les correctement toutes les deux.
Si vous exécutez un résolveur ouvert, vous attirez les abus, vous générez des schémas de trafic confus, et vous augmentez la probabilité que des ordures usurpées atteignent votre cache.

• BIND : définissez allow-recursion et allow-query-cache uniquement pour les réseaux internes.
• Unbound : configurez access-control pour les sous-réseaux autorisés ; refusez tout le reste.

2) Activez la validation DNSSEC et ne la considérez pas comme optionnelle

La validation DNSSEC est la mitigation la plus efficace contre l’empoisonnement pour les zones signées. Elle transforme le « peut-être » en « non ».
Oui, elle introduit de nouveaux modes de défaillance (signatures expirées, enchaînements DS cassés). C’est acceptable. Nous savons comment les surveiller.

Ce qu’il ne faut pas faire : couper DNSSEC pendant une panne et oublier de le réactiver. C’est ainsi que l’on passe de « instabilité temporaire »
à « compromission silencieuse ».

3) Maintenez votre logiciel de résolveur à jour

La sécurité des résolveurs évolue : corrections de bailiwick, meilleure randomisation, parsing renforcé, améliorations de la minimisation QNAME,
et mitigations pour de nouveaux canaux latéraux. Les anciennes versions accumulent des arêtes vives. Vous en subirez les conséquences.

4) Préservez l’entropie de bout en bout (ports, IDs et réseau intermédiaire)

La randomisation du port source n’aide que si les paquets conservent leurs ports. Si votre résolveur est derrière un NAT qui réécrit les ports de façon prévisible,
vous perdez de l’entropie. Déplacez le résolveur vers la périphérie, corrigez le NAT, ou utilisez une architecture évitant ce chemin NAT.

5) Préférez la récursion complète au forwarding aveugle (quand c’est possible)

Le forwarding vers des résolveurs publics est opérationnellement facile. C’est aussi un transfert de confiance. Vous externalisez une partie de votre posture de sécurité et toute la
clarté du dépannage. La récursion complète rend l’analyse de la cause racine plus propre et réduit la dépendance aux bizarreries d’un amont unique.

Si vous devez forwarder (conformité, politique, contraintes d’egress), faites-le vers des résolveurs contrôlés que vous exploitez ou vers des amonts de confiance et
conservez la validation DNSSEC localement autant que possible.

6) Activez la minimisation QNAME

La minimisation QNAME réduit la fuite d’information et diminue légèrement la valeur de certains jeux de spoofing en minimisant ce que vous révélez à chaque amont.
Ce n’est pas votre défense principale contre l’empoisonnement, mais c’est un gain peu coûteux.

7) Utilisez le rate limiting pour protéger la stabilité, pas comme une baguette magique

Le rate limiting aide contre les inondations et certains patterns de brute-force. Il ne « résoudra » pas l’empoisonnement.
Mais il peut maintenir le résolveur en vie suffisamment longtemps pour répondre et réduit le potentiel d’amplification.

8) Journalisez avec intention : assez pour enquêter, pas pour se noyer

Les logs de requêtes 24/7 sont chers et bruyants. Utilisez l’échantillonnage ou des bascules à court terme (rndc querylog, augmentation de la verbosité Unbound),
et conservez des métriques structurées en permanence : taux de hits du cache, taux de SERVFAIL, réponses non souhaitées, principaux QNAME par volume.

9) Figez les zones internes et évitez les collisions

Le split-horizon DNS est souvent nécessaire. C’est aussi un terrain fertile pour des comportements « ressemblant à l’empoisonnement » : réponses différentes selon la source,
mauvaises vues appliquées, zones internes masquant des domaines publics réels. Utilisez des suffixes clairs, testez en externe et automatisez les contrôles.

10) Décidez de votre position sur EDNS, cookies et retour vers TCP

EDNS augmente la taille des messages DNS et les capacités. C’est utile, mais cela interagit avec MTU, la fragmentation et les middleboxes.
Les EDNS Cookies peuvent ajouter de la résilience contre les réponses usurpées dans certains scénarios en ajoutant un jeton à l’échange (support variable).
Assurez-vous que le fallback TCP fonctionne : certaines attaques et pannes reposent sur la rupture des hypothèses UDP.

Petite blague #2 : chaque fois que quelqu’un dit « le DNS est simple », un résolveur laisse tomber un paquet UDP fragmenté et médite sa vengeance.

Trois micro-récits du monde de l’entreprise

Micro-récit 1 : L’incident causé par une mauvaise hypothèse

Une entreprise exploita deux résolveurs récursifs par site. Le document de conception disait « anycast », mais l’implémentation c’était « deux IP dans le DHCP ».
Un ingénieur a supposé que cela signifiait que les clients basculeraient de manière transparente quand un résolveur était malade.

Un lundi, un nœud résolveur a commencé à renvoyer des enregistrements obsolètes pour un petit ensemble de domaines à fort trafic. Pas complètement mort. Juste suffisamment mauvais.
Les TTL étaient longs. Le support a reçu des rapports « la page de connexion parfois est erronée ». C’est le genre de rapport que vous voudriez qu’on vous fasse en blague.

La mauvaise hypothèse : l’équipe pensait que le résolveur secondaire masquerait les problèmes du primaire. En réalité, la plupart des piles clientes restent collées au premier serveur
sauf en cas de timeout. Un résolveur qui répond rapidement—incorrectement—ne déclenche pas la bascule. Il devient une source autoritaire de mensonges pour cette population de clients.

La correction n’a pas été héroïque. Ils ont arrêté de traiter « deux IP » comme haute disponibilité. Ils ont ajouté des vérifications de santé des résolveurs, retiré les nœuds malsains des pools DHCP,
et standardisé les procédures de purge de cache. Surtout, ils ont construit une petite vérification synthétique comparant les réponses de chaque résolveur à un trace externe.

La conclusion du postmortem était franche : « des réponses rapides et incorrectes sont pires que des timeouts. » Cette ligne est devenue une exigence de conception, pas une leçon.

Micro-récit 2 : L’optimisation qui s’est retournée contre eux

Une autre organisation avait des plaintes de latence depuis des bureaux distants. Quelqu’un proposa une optimisation : forwarder tout le DNS vers une paire de résolveurs centraux
parce que « les hits du cache seraient plus élevés ». Techniquement vrai. Opérationnellement, un piège.

Ils ont implémenté le forwarding sur un VPN. Le volume de requêtes était correct, mais les réponses EDNS ont commencé à être fragmentées, et le chemin VPN avait un MTU effectif plus bas.
Certains fragments étaient perdus. Certains domaines ont commencé à échouer de façon intermittente avec SERVFAIL ou de longs blocages à cause de la logique de retry et du fallback TCP.

L’équipe a remarqué le symptôme mais diagnostiqué d’abord la mauvaise chose : « les serveurs autoritaires sont instables ». Ils ont ouvert des tickets, attendu et n’ont rien obtenu.
Pendant ce temps, un attaquant dans un environnement réseau partagé (pas en interception vers le datacenter, mais proche de certains clients de succursales) avait plus de facilité à usurper des réponses
parce que le chemin de forwarding et le comportement NAT réduisaient l’entropie effective et augmentaient les retransmissions.

Rien de catastrophique n’est arrivé, mais l’incident était une masterclass de fragilité auto-infligée. L’« optimisation » a concentré la confiance et la défaillance.
La correction a été de déployer des résolveurs locaux dans les succursales avec récursion complète, préserver la randomisation des ports localement, et conserver le forwarding seulement comme levier de politique d’urgence.

La leçon finale : la mise en cache n’est pas une raison pour créer un point unique de bizarrerie. Surtout pas pour le DNS.

Micro-récit 3 : La pratique ennuyeuse mais correcte qui a sauvé la situation

Une entreprise de paiements avait une politique : les résolveurs valident DNSSEC, et désactiver la validation requiert un changement formel avec une date d’expiration.
Les gens râlaient pendant les semaines calmes. Lors d’un vrai incident, cela leur a rendu service.

Un domaine SaaS tiers a commencé à résoudre vers une IP inattendue pour un sous-ensemble de réseaux. Les résolveurs publics n’étaient pas d’accord entre eux.
Les résolveurs validants de l’entreprise renvoyaient SERVFAIL pour certaines réponses et des réponses correctes pour d’autres. Cela ressemblait à une panne DNS pour les équipes applicatives.

Parce que des métriques étaient en place, la SRE a vu une augmentation des échecs de validation et des « unwanted replies ». Les captures de paquets montraient des réponses falsifiées arrivant
plus vite que les légitimes sur un chemin ISP. La validation DNSSEC a refusé les données falsifiées. L’impact a été une résolution dégradée (timeouts et retries),
mais pas une redirection silencieuse vers l’attaquant.

Ils ont temporairement routé l’egress des résolveurs via un autre fournisseur, en gardant la validation activée. Le service s’est stabilisé.
Plus tard, l’ISP a reconnu un problème cohérent avec une interférence du trafic. L’entreprise n’a jamais eu à dire aux clients « il se peut que nous vous ayons redirigés vers le mauvais hôte ».

La pratique ennuyeuse n’était pas juste « DNSSEC activé ». C’était « DNSSEC activé, surveillé et difficile à désactiver ». L’ennuyeux est bon. L’ennuyeux monte en charge.

Erreurs courantes : symptômes → cause racine → correctif

1) Symptôme : Certains utilisateurs atteignent la mauvaise IP, d’autres vont bien

Cause racine : Un nœud résolveur a le cache empoisonné/obsolète, ou les clients sont fixés sur le premier serveur DNS.

Correctif : Comparez les réponses par IP de résolveur ; videz le cache sur le nœud fautif ; retirez-le de la rotation ; ajoutez des vérifications synthétiques par nœud.

2) Symptôme : La mauvaise réponse persiste des heures après avoir « corrigé le DNS »

Cause racine : TTL long mis en cache chez les récursifs ; mise en cache négative ; cache d’un forwarder intermédiaire ; ou applications qui cachent DNS en interne.

Correctif : Mesurez le countdown TTL à chaque couche. Purgez les caches que vous contrôlez ; réduisez le TTL avant les migrations ; redémarrer n’est qu’un dernier recours.

3) Symptôme : Pic soudain de SERVFAIL pour des domaines populaires

Cause racine : Échecs de validation DNSSEC (chaîne DS cassée, signatures expirées) ou timeouts/fragmentation amont.

Correctif : Vérifiez les logs pour erreurs de validation ; confirmez EDNS/MTU du chemin ; assurez le fallback TCP ; ne désactivez pas la validation sans plan cadré.

4) Symptôme : Le CPU du résolveur est correct, mais les clients voient des timeouts

Cause racine : Perte de paquets, pare-feu qui supprime des fragments, ou timeouts d’état UDP ; parfois exhaustion de conntrack.

Correctif : tcpdump sur le résolveur ; vérifier conntrack ; autoriser DNS TCP/53 ; ajuster la taille EDNS ou le path MTU ; corriger les ACL réseau.

5) Symptôme : Des IP publiques apparaissent dans les logs du résolveur comme clients

Cause racine : Récursion ouverte exposée à l’internet ou routage VPN incorrect ; parfois une erreur de security group cloud.

Correctif : Verrouillez la récursion avec des ACLs ; pare-feu UDP/TCP 53 ; vérifiez SG/NACL cloud ; confirmez que vous n’annoncez pas accidentellement des IP de résolveur.

6) Symptôme : Le résolveur retourne un A « correct » mais TLS échoue avec un mismatch de certificat

Cause racine : La réponse DNS pointe vers le mauvais hôte (empoisonnement ou split-horizon), ou les CDN déplacent les bords et vos hypothèses de pinning sont obsolètes.

Correctif : Comparez avec +trace et plusieurs résolveurs ; vérifiez si vous overridez la zone en interne ; validez les enregistrements autoritatifs.

7) Symptôme : Problèmes uniquement pour les réponses volumineuses (TXT, DNSKEY, certains HTTPS/SVCB)

Cause racine : Fragments EDNS perdus ; problèmes de path MTU ; middleboxes cassés ; TCP bloqué.

Correctif : Assurez que TCP/53 fonctionne de bout en bout ; ajustez la taille EDNS ; préférez des versions modernes de résolveurs avec des valeurs par défaut sensées.

8) Symptôme : Pics de requêtes pour des sous-domaines aléatoires (ex : a1b2c3.example.com)

Cause racine : Inondation de contournement de cache, tentative DDoS, ou malware qui beacon ; peut aussi être une découverte de service défaillante.

Correctif : Utilisez RPZ ou une politique locale pour bloquer les patterns malveillants ; implémentez le rate limiting ; identifiez les IP sources ; coordonnez avec la sécurité.

Listes de contrôle / plan étape par étape

Phase 1 — Établir la posture de sécurité du résolveur (1–2 jours)

1. Inventoriez les résolveurs : IPs, versions, s’ils récursent ou forwardent, et où va leur egress.
2. Confirmez les ACLs de récursion : seules les réseaux internes peuvent récursivement résoudre ; tout le monde else reçoit un REFUSED.
3. Activez la validation DNSSEC : validez sur le résolveur, pas seulement sur les clients.
4. Vérifiez que TCP/53 est autorisé : à la fois vers le résolveur depuis les clients (si nécessaire) et depuis le résolveur en sortie.
5. Confirmez que la randomisation de ports survit au NAT : vérifiez conntrack/flows ; corrigez les mappings prévisibles.
6. Activez les métriques : taux de hits du cache, SERVFAIL, NXDOMAIN, unwanted replies, histogrammes de latence.

Phase 2 — Ajouter des garde-fous pour éviter les « sécurités temporaires » (1–2 semaines)

1. Configuration en code : les résolveurs gérés via votre pipeline habituel, pas des éditions artisanales en SSH.
2. Contrôle des changements pour les bascules DNSSEC : toute désactivation requiert une date d’expiration et un responsable.
3. Vérifications synthétiques par nœud résolveur : comparez contre +trace pour un petit jeu de domaines ; alertez sur divergence.
4. Bascule de journalisation de requêtes à court terme : runbook opérationnel pour activer les logs pendant 15 minutes avec rétention sûre.

Phase 3 — Durcissement sans suringénierie (en continu)

1. Privilégiez la récursion complète sauf si la politique impose le forwarding. Si vous forwardez, soyez explicite sur la confiance et surveillez l’amont.
2. Minimisez la complexité split-horizon : gardez les zones internes petites et claires ; évitez de masquer des domaines publics.
3. Cadence de patch : traitez les mises à jour des résolveurs comme des mises à jour de sécurité, parce que ça en est.
4. Exercice table-top : simulez « mauvaise réponse DNS » et « échec de validation DNSSEC » et entraînez la réponse.

FAQ

1) L’empoisonnement du cache DNS existe-t-il encore en 2025 ?

Oui, mais les versions faciles sont essentiellement mortes sur les résolveurs modernes avec bonne randomisation et règles de bailiwick.
Le risque restant vient de la mauvaise configuration, du transfert de confiance via le forwarding, de la perte d’entropie due au NAT, de l’interférence on-path, et de la « validation désactivée ».

2) Si j’utilise DoH/DoT, suis-je protégé contre l’empoisonnement du cache ?

DoH/DoT protège le trajet client→résolveur contre l’altération en interception. Cela ne valide pas automatiquement DNSSEC, et ne vous protège pas
si le résolveur lui-même est compromis ou mal configuré. C’est une amélioration du transport, pas un oracle de vérité.

3) Quelle est la meilleure étape de durcissement unique ?

Activez la validation DNSSEC sur le résolveur récursif et laissez-la activée. Puis restreignez la récursion aux clients internes.
Ces deux changements éliminent des classes entières de problèmes.

4) Pourquoi mon résolveur renvoie-t-il SERVFAIL alors que des résolveurs publics renvoient une IP ?

Le plus souvent : échec de validation DNSSEC. Les résolveurs publics peuvent être configurés différemment, ignorer la validation pour cette zone,
ou avoir un état de cache différent. Vérifiez vos logs avant d’accuser l’internet.

5) Comment distinguer l’empoisonnement du split-horizon DNS ?

Le split-horizon tend à être cohérent selon le réseau source et les zones configurées. L’empoisonnement montre souvent une divergence entre résolveurs,
des changements de délégation inattendus et des anomalies comme des unwanted replies. Utilisez +trace et comparez les réponses internes vs externes.

6) Devons-nous vider les caches lors d’un soupçon d’empoisonnement ?

Parfois oui — après avoir capturé des preuves. La purge peut détruire la preuve dont vous avez besoin (captures, logs, RRsets en cache).
Si vous videz d’abord et posez des questions après, votre postmortem sera un exercice de créativité.

7) Les TTL longs sont-ils toujours mauvais ?

Non. Les TTL longs sont excellents pour la stabilité et le coût. Ils sont mauvais quand les données sont erronées. Opérationnellement, baissez les TTL avant des migrations planifiées
et évitez des TTL extrêmement longs sur des enregistrements qui changent fréquemment.

8) Exécuter plusieurs résolveurs règle-t-il l’empoisonnement ?

Cela réduit la probabilité qu’un cache empoisonné unique affecte tout le monde, mais seulement si les clients utilisent effectivement plusieurs résolveurs et que vous surveillez le comportement par nœud.
Deux résolveurs with le même mauvais forwarding upstream, c’est juste de la redondance de la même erreur.

9) Qu’en est-il du « 0x20 encoding » et autres astuces d’entropie ?

Elles peuvent aider dans des cas spécifiques, mais ce ne sont pas des défenses principales. Traitez-les comme des assaisonnements, pas comme le plat principal.
La validation DNSSEC et une randomisation correcte plus des ACL sont le plat principal.

10) Comment éviter la suringénierie ?

Ne construisez pas une plateforme de sécurité DNS sur-mesure. Exécutez un résolveur moderne (Unbound ou BIND), validez DNSSEC, verrouillez la récursion,
surveillez les métriques clés et entraînez la réponse aux incidents. La plupart des équipes échouent sur les bases, pas par manque de fonctionnalités exotiques.

Conclusion : prochaines étapes pratiques

L’empoisonnement du cache DNS tient moins du hack hollywoodien que de l’hygiène opérationnelle : qui peut vous interroger, en quoi vous avez confiance, et si votre résolveur
sait distinguer le vrai de l’ordure. Les attaquants aiment l’ambiguïté. Les pannes aussi. Votre travail est de supprimer les deux.

1. Cette semaine : vérifiez les ACLs de récursion, confirmez que la validation DNSSEC est activée, et exécutez les vérifications « comparer avec l’externe » sur vos domaines clés.
2. La semaine prochaine : ajoutez une surveillance synthétique par résolveur pour divergence des réponses et échecs de validation ; faites de la « désactivation DNSSEC » un changement contrôlé avec date d’expiration.
3. Ce trimestre : modernisez les versions de résolveur, auditez le NAT/egress pour perte d’entropie, et simplifiez les zones split-horizon.

Si vous ne faites qu’une seule chose : arrêtez d’accepter des réponses rapides et incorrectes comme « saines ». Le DNS est une infrastructure. Traitez-le comme important, car tout le reste en dépend.