Chaque fois que vous tapez une adresse comme forenshield.com, votre appareil demande à un serveur DNS de la traduire en adresse IP. Ce mécanisme est si discret qu'on l'oublie, mais il repose en grande partie sur la confiance. L'empoisonnement DNS, ou « DNS cache poisoning », consiste à y glisser une fausse réponse pour rediriger des utilisateurs vers un site contrôlé par l'attaquant, alors que l'adresse affichée dans le navigateur reste la bonne. Cet article explique comment l'attaque fonctionne, ce qui s'est passé depuis la faille de Kaminsky en 2008, et comment vous protéger, que vous soyez utilisateur, propriétaire de domaine ou administrateur.
À retenir : un empoisonnement DNS trompe la traduction d'un nom en adresse IP. La parade de fond est DNSSEC, complétée par des résolveurs à jour, du chiffrement TLS vérifié et un poste sain.
Les adresses IP des exemples ci-dessous sont fictives : elles proviennent des plages réservées à la documentation (192.0.2.0/24, 198.51.100.0/24 et 203.0.113.0/24).
Le DNS et son cache en deux minutes
Le DNS est l'annuaire d'Internet. Votre appareil interroge un résolveur récursif (celui de votre fournisseur d'accès, de votre entreprise, ou un résolveur public), qui interroge à son tour les serveurs qui font autorité sur le domaine. Pour aller plus vite, le résolveur garde chaque réponse en cache pendant une durée appelée TTL (Time To Live).
Vous pouvez le constater avec dig sous Linux ou macOS :
dig forenshield.com A
;; ANSWER SECTION:
forenshield.com. 3600 IN A 192.0.2.10
Ici, 3600 est le TTL en secondes : pendant une heure, le résolveur répondra sans redemander. Sous Windows, nslookup forenshield.com donne l'adresse sans afficher le TTL. L'outil Outil réseau de ForenShield exécute dig et nslookup depuis le navigateur.
Ce cache est utile, mais il crée une cible : si une fausse réponse y entre, elle sera resservie à tous les utilisateurs du résolveur jusqu'à l'expiration du TTL.
Comment fonctionne l'empoisonnement du cache
Le DNS classique circule surtout en UDP, sans authentification de l'émetteur. Pour accepter une réponse, un résolveur vérifie qu'elle correspond à sa question : même nom, même adresse et même port source, même identifiant de requête (« Transaction ID »). Cette correspondance est le seul verrou, comme le décrit la RFC 5452.
L'attaque suit ce schéma :
- L'attaquant provoque ou attend une requête du résolveur pour un nom donné.
- Il envoie de nombreuses réponses falsifiées, en essayant de deviner les paramètres attendus, avant que la vraie réponse n'arrive.
- Si l'une d'elles correspond, le résolveur l'accepte et l'enregistre dans son cache.
- Tous les utilisateurs de ce résolveur sont redirigés, tant que le TTL n'a pas expiré.
L'identifiant de requête ne fait que 16 bits, soit 65 536 valeurs possibles : c'est ce qui rendait l'attaque réalisable.
Un exemple concret
Un client veut ouvrir forenshield.com, dont l'adresse légitime est 192.0.2.10. Après empoisonnement, son résolveur renvoie 198.51.100.5, l'adresse d'un serveur qui imite le site. Le navigateur affiche toujours le bon nom. Si la page réclame des identifiants, ils partent chez l'attaquant. La protection HTTPS limite pourtant cette attaque : le faux serveur ne dispose normalement pas d'un certificat valide pour le vrai nom, et le navigateur affiche donc un avertissement. Ne passez jamais outre un avertissement de certificat après une redirection inattendue.
L'histoire : de Kaminsky à aujourd'hui
2008, la faille de Kaminsky
En juillet 2008, le chercheur Dan Kaminsky révèle une faille référencée CVE-2008-1447, qui touchait des résolveurs très répandus comme BIND et le DNS de Microsoft. Selon l'ISC, l'identifiant de 16 bits est « une cible facile » pour ce scénario de falsification. Le correctif a consisté à randomiser le port source des requêtes : l'attaquant doit désormais deviner à la fois l'identifiant et le port. L'ISC précise toutefois que c'est une atténuation, et que « DNSSEC est la seule solution définitive ».
2020, SAD DNS
En 2020, la faille SAD DNS (CVE-2020-25705) a montré que l'attaque pouvait revenir : un canal auxiliaire lié aux messages ICMP permettait de retrouver le port source ouvert, puis de deviner l'identifiant. Elle touchait notamment Linux, Windows Server, macOS et FreeBSD, ainsi que des résolveurs comme BIND, Unbound et dnsmasq.
2025, nouvelles failles dans BIND
Le 22 octobre 2025, l'ISC a publié deux failles de sévérité élevée (CVSS 8,6) dans BIND 9 :
- CVE-2025-40780 : un générateur de nombres pseudo-aléatoires faible permet, dans des circonstances précises, de prédire le port source et l'identifiant de requête.
- CVE-2025-40778 : BIND accepte trop facilement des enregistrements dans les réponses, ce qui permet d'injecter de fausses données dans le cache.
Elles concernent les résolveurs, les serveurs faisant autorité n'étant pas considérés comme vulnérables. Les versions corrigées sont les 9.18.41, 9.20.15 et 9.21.14, sans contournement possible, et aucune exploitation n'était connue à la publication. La leçon : un résolveur non mis à jour reste un risque en 2026.
Trois attaques à ne pas confondre
| Attaque | Où elle agit | Ce qu'elle change |
|---|---|---|
| Empoisonnement du cache | Dans un résolveur récursif | Fausses réponses mémorisées pour tous ses utilisateurs |
| Détournement local | Sur un poste ou un routeur | Fichier hosts modifié par un logiciel malveillant, ou serveur DNS d'un routeur remplacé |
| Déni de service sur le DNS | Sur les serveurs DNS | Le service devient indisponible, sans fausse réponse |
Le dernier cas est souvent confondu avec les deux autres. L'attaque de 2016 contre Dyn, qui a rendu injoignables Twitter, Netflix, Spotify ou GitHub, était une attaque par déni de service distribué menée avec le réseau de machines Mirai, pas un empoisonnement, d'après ThousandEyes.
Le fichier hosts
Le fichier hosts a priorité sur le DNS. Une ligne comme 198.51.100.5 forenshield.com y redirige toutes les requêtes vers l'adresse indiquée. Un logiciel malveillant ou un accès à distance peut la modifier. Pour vérifier :
- Linux et macOS :
cat /etc/hosts - Windows : ouvrez
C:\Windows\System32\drivers\etc\hostsavec un éditeur de texte.
Ce fichier ne doit contenir que des entrées que vous reconnaissez.
Comment détecter une résolution suspecte
Une adresse inattendue ne prouve pas un empoisonnement, mais elle mérite une vérification :
dig @1.1.1.1 forenshield.com A # un résolveur public
dig @9.9.9.9 forenshield.com A # un autre résolveur
dig +trace forenshield.com A # suit la délégation depuis la racine
Si votre résolveur habituel renvoie une adresse différente de celle des autres, et de celle obtenue par +trace, une manipulation est possible. Vous pouvez aussi analyser le domaine avec l'outil OSINT sur domaine et examiner le certificat présenté avec l'analyseur de certificats HTTP. Un certificat qui ne correspond pas au nom est un signal d'alerte fort. Attention : des adresses qui changent peuvent aussi venir d'un réseau de diffusion de contenu, ou d'un changement légitime.
Se protéger
DNSSEC : la protection de fond
Selon l'ICANN, DNSSEC ajoute des signatures numériques aux données DNS. Chaque zone est signée, sa clé publique est elle-même signée par la zone parente, et la chaîne remonte jusqu'à la racine du DNS. Un résolveur qui valide ces signatures peut refuser une réponse falsifiée. DNSSEC garantit l'authenticité et l'intégrité des données, mais ne chiffre pas les échanges et ne protège pas contre les attaques par déni de service.
Pour vérifier qu'un domaine est signé et que votre résolveur valide :
dig +dnssec forenshield.com A
Si le résolveur valide, la réponse contient l'indicateur ad (« authenticated data ») et des enregistrements RRSIG. Ce drapeau indique que le résolveur affirme avoir validé la réponse : il n'a de valeur que si vous faites confiance à ce résolveur et au chemin qui vous relie à lui.
Selon votre profil
Particuliers
- Utilisez un résolveur qui valide DNSSEC : plusieurs résolveurs publics (Google, Cloudflare, Quad9) le proposent, à vérifier dans leur documentation.
- Ne contournez jamais un avertissement de certificat.
- Changez le mot de passe par défaut de votre routeur et mettez son micrologiciel à jour : un routeur compromis peut imposer un faux serveur DNS à tout votre réseau.
- Gardez votre système à jour et protégé par un antivirus ou un EDR, pour éviter la modification du fichier
hosts.
Propriétaires de domaine et entreprises
- Signez votre zone avec DNSSEC et publiez la clé chez votre bureau d'enregistrement.
- Sécurisez le compte du registrar avec une authentification forte, car un détournement de domaine contourne DNSSEC.
- Surveillez les changements d'enregistrements et les résolutions inhabituelles dans vos journaux.
- Sensibilisez vos équipes : notre guide sur l'analyse d'un e-mail de phishing aide à repérer les liens piégés qui accompagnent souvent ces redirections.
Administrateurs système
- Mettez à jour vos résolveurs (BIND, Unbound, dnsmasq) et le système, comme le montrent les failles de 2020 et de 2025.
- Appliquez les mesures de la RFC 5452 : port source aléatoire sur une plage la plus large possible, identifiant de requête aléatoire, acceptation des seuls enregistrements du domaine interrogé, nouvelle requête en TCP en cas de suspicion.
- Activez la validation DNSSEC sur les résolveurs récursifs.
- Limitez la récursion aux réseaux de confiance, et séparez si possible résolveurs et serveurs faisant autorité.
Et le DNS chiffré ?
Le DNS sur HTTPS (DoH) ou sur TLS (DoT) chiffre le trajet entre votre appareil et le résolveur, ce qui protège la confidentialité et l'intégrité de ce segment. Il ne remplace pas DNSSEC, qui authentifie les données elles-mêmes tout au long de la chaîne : les deux sont complémentaires.
Ce qu'il faut retenir
- L'empoisonnement DNS exploite la confiance faite à un résolveur, et il reste possible quand les résolveurs ne sont pas à jour.
- DNSSEC est la protection de fond, à condition que le domaine soit signé et que le résolveur valide.
- HTTPS et la vérification des certificats limitent l'impact d'une redirection : un avertissement de certificat est un signal à respecter.
- Un poste ou un routeur compromis peut suffire à rediriger, sans toucher au DNS lui-même.