DNS spoofing : empoisonnement de cache, détection et DNSSEC

Le DNS spoofing (ou usurpation DNS) consiste à faire accepter à un poste ou à un résolveur une réponse DNS falsifiée, afin qu'un nom de domaine légitime pointe vers une adresse IP choisie par l'attaquant. La victime saisit la bonne adresse dans son navigateur et se retrouve pourtant sur un serveur contrôlé par l'adversaire. Deux cibles dominent : le poste client, souvent attaqué depuis le réseau local, et le cache d'un résolveur récursif : on parle alors d'empoisonnement de cache. En 2026, le sujet reste brûlant : des failles d'empoisonnement ont été corrigées fin 2025 dans BIND et Unbound, et la racine du DNS a changé de clé DNSSEC en octobre 2026. Ce guide défensif explique les mécanismes, les signaux de détection exploitables par un centre opérationnel de sécurité (SOC) et les protections à déployer, du durcissement des résolveurs jusqu'à la validation DNSSEC. Si vous exploitez déjà un résolveur filtrant comme celui présenté dans notre guide AdGuard Home pour filtrer le DNS du réseau local, vous disposez d'un point de contrôle idéal pour appliquer ces mesures.

DNS spoofing : définition et principe de l'usurpation DNS

Le système de noms de domaine (DNS, Domain Name System) traduit des noms lisibles, comme le domaine d'une entreprise, en adresses IP. Un poste interroge un résolveur récursif, qui parcourt la hiérarchie (racine, domaine de premier niveau, zone de l'organisation) puis conserve la réponse en cache pendant la durée de vie indiquée par le TTL (Time To Live). Chaque maillon de cette chaîne peut, en théorie, recevoir une réponse falsifiée.

L'expression anglaise DNS spoofing attack désigne l'ensemble de la famille. En français, on parle d'usurpation DNS, de spoofing DNS ou d'empoisonnement DNS selon le point d'injection. Le résultat reste identique : la résolution de noms, socle de presque toutes les connexions réseau, renvoie une information fausse sans que l'utilisateur ne s'en aperçoive, puisque la barre d'adresse affiche toujours le nom attendu.

DNS spoofing, empoisonnement de cache et détournement : trois notions voisines

Le DNS spoofing désigne l'acte de forger une réponse. L'empoisonnement de cache (cache poisoning) en est la variante la plus redoutable : la fausse donnée est stockée par un résolveur et servie à tous ses clients jusqu'à l'expiration du TTL. Le détournement DNS (DNS hijacking) modifie la configuration elle-même : serveur DNS d'un poste ou d'une box, ou enregistrements d'une zone chez son hébergeur. Notre article consacré aux attaques DNS, du tunneling au cache poisoning détaille ces distinctions.

Pourquoi le protocole DNS est-il si facile à usurper ?

Le DNS classique circule majoritairement en UDP (User Datagram Protocol), un transport sans connexion ni authentification de l'émetteur. D'après la RFC 5452 publiée par l'IETF en 2009, un résolveur accepte la première réponse qui correspond à la question posée, à l'identifiant de transaction, à l'adresse du serveur interrogé et au port d'origine de la requête. Un tiers qui satisfait ces quatre conditions avant le serveur légitime fait accepter ses propres données.

L'identifiant de transaction (TXID) ne compte que 16 bits. Sans autre source d'aléa, un attaquant peut tenter sa chance en envoyant un grand nombre de réponses forgées pendant la courte fenêtre où le résolveur attend la réponse authentique. Toute la sécurité du DNS non signé repose ainsi sur l'imprévisibilité de quelques champs, ce qui explique que chaque faiblesse de génération d'aléa devienne immédiatement une vulnérabilité grave.

Les grandes familles d'attaques par spoofing DNS

Une attaque par spoofing DNS se classe d'abord selon la position de l'attaquant. Plus il est proche de la victime, plus l'attaque est simple, mais plus sa portée est limitée. À l'inverse, empoisonner le cache d'un résolveur partagé demande davantage de moyens mais touche simultanément des milliers d'utilisateurs. Le tableau ci-dessous résume ces familles et la contre-mesure la plus efficace pour chacune d'elles.

L'usurpation sur le réseau local

Sur un réseau local partagé (Wi-Fi invité, salle de réunion, réseau industriel plat), l'attaquant commence souvent par s'intercaler entre la victime et la passerelle grâce à l'usurpation ARP, référencée T1557.002 dans la matrice MITRE ATT&CK. Une fois sur le chemin, il voit passer les requêtes DNS en clair et répond avant le résolveur légitime. Cette variante ne demande aucune devinette, puisque l'identifiant de transaction et le port sont directement observés.

L'empoisonnement de cache d'un résolveur

Ici, l'attaquant se situe hors du chemin (off-path). Il pousse le résolveur à interroger un nom, puis l'inonde de réponses forgées en espérant deviner la combinaison du port source et de l'identifiant de transaction. S'il réussit, la donnée frauduleuse reste en cache et contamine tous les clients du résolveur. C'est précisément ce scénario qui a motivé la randomisation des ports, puis le déploiement progressif de DNSSEC.

La modification de la configuration DNS

Un logiciel malveillant peut modifier le fichier hosts, les serveurs DNS de la carte réseau ou ceux d'une box internet. Un faux serveur DHCP peut aussi distribuer l'adresse d'un résolveur hostile à tout un segment. La fiche MITRE ATT&CK T1557 (Adversary-in-the-Middle) cite explicitement la manipulation des paramètres DNS des victimes pour les rediriger vers des sites malveillants ou leur pousser des charges supplémentaires.

Le détournement en amont

Le dernier niveau vise la source : compte chez le bureau d'enregistrement, serveurs faisant autorité ou fournisseur DNS. La même fiche MITRE indique que le groupe Sea Turtle a modifié des enregistrements DNS chez des prestataires afin de capter des identifiants. Techniquement, il ne s'agit plus de spoofing mais de détournement ; les conséquences pour la victime sont pourtant identiques, d'où l'intérêt de traiter ces risques dans une même analyse.

L'empoisonnement de cache DNS, de l'attaque Kaminsky aux canaux auxiliaires

L'empoisonnement de cache est la forme de DNS spoofing la plus étudiée, car un seul succès contamine un résolveur entier. Son histoire est faite d'allers-retours : chaque contre-mesure a relevé le coût de l'attaque, puis des chercheurs ont trouvé le moyen de contourner une partie de l'aléa. Comprendre cette évolution aide à prioriser les correctifs et évite de surestimer une protection unique.

2008 : l'attaque Kaminsky change la donne

À l'été 2008, le chercheur Dan Kaminsky a montré qu'il n'était plus nécessaire d'attendre l'expiration d'un enregistrement en cache. En interrogeant des sous-domaines aléatoires inexistants, l'attaquant ouvre autant de fenêtres d'injection qu'il le souhaite, et sa réponse forgée peut contenir une délégation vers un faux serveur de noms pour tout le domaine. La correction coordonnée des éditeurs, sous la référence CVE-2008-1447, a généralisé la randomisation du port source, qui ajoute jusqu'à 16 bits d'aléa à l'identifiant de transaction.

La RFC 5452 a ensuite normalisé ces exigences : port source imprévisible choisi dans la plage la plus large possible, identifiant tiré sur toute la plage disponible et vérification stricte de chaque attribut de la réponse. Elle rappelle aussi qu'un équipement de traduction d'adresses qui réécrit les ports de façon séquentielle peut annuler ce bénéfice, un point souvent oublié dans les architectures d'entreprise.

Canaux auxiliaires et fragmentation

La randomisation n'a pas clos le sujet. En 2020, l'attaque SAD DNS a exploité un canal auxiliaire lié à la limitation du débit des messages ICMP sous Linux (CVE-2020-25705) pour deviner le port source utilisé par un résolveur. D'autres travaux ont abusé de la fragmentation IP afin de remplacer un fragment d'une grande réponse, sans avoir à deviner l'identifiant de transaction. Ces techniques rappellent que l'aléa protège, mais ne garantit jamais l'authenticité des données.

2025 : des failles d'empoisonnement de cache dans BIND et Unbound

Le 22 octobre 2025, l'ISC (Internet Systems Consortium), qui développe le serveur DNS BIND, a publié des correctifs pour BIND 9 dont deux concernent l'empoisonnement du cache des résolveurs. Selon l'avis de l'ISC sur la CVE-2025-40778, le résolveur se montrait trop tolérant envers certains enregistrements présents dans les réponses, ce qui permettait d'injecter des données forgées en cache ; le score CVSS atteint 8,6 et aucun contournement n'est proposé. La CVE-2025-40780 décrit, elle, un générateur pseudo-aléatoire rendant prévisibles le port source et l'identifiant de requête.

Le même jour, NLnet Labs a corrigé dans Unbound la CVE-2025-11411 : des enregistrements NS non sollicités, placés dans la section d'autorité d'une réponse positive, pouvaient amener le résolveur à mettre à jour sa délégation pour une zone, donc à envoyer les requêtes suivantes vers des serveurs choisis par l'attaquant. Le correctif est arrivé avec Unbound 1.24.1, puis a été renforcé dans la version 1.24.2. Côté BIND, les versions corrigées sont 9.18.41, 9.20.15 et 9.21.14.

L'impact de ces failles est fortement réduit lorsque la zone visée est signée et que le résolveur valide DNSSEC ; Red Hat souligne également l'effet protecteur d'une récursion restreinte aux clients autorisés. La leçon opérationnelle est simple : le correctif reste indispensable, mais la validation cryptographique est la seule protection qui ne dépend pas de la qualité de l'aléa ni de la rigueur du code d'analyse des réponses.

DNS spoofing avec Ettercap et Bettercap : ce que les outils révèlent aux défenseurs

Les recherches « dns spoofing ettercap » et « bettercap dns spoofing » sont fréquentes, car ces deux logiciels libres servent de référence pour démontrer l'attaque en formation ou en test d'intrusion interne. Ettercap, outil historique, s'appuie sur un greffon d'usurpation DNS piloté par un fichier de correspondances entre noms et adresses. Bettercap, plus récent et écrit en Go, propose un module d'usurpation DNS qui répond aux requêtes visées pendant qu'un autre module assure l'interception ARP ou IPv6.

Pour un défenseur, l'intérêt de ces outils est ailleurs : ils produisent des traces très reconnaissables. L'interception préalable génère des annonces ARP répétées associant l'adresse IP de la passerelle à une nouvelle adresse MAC. Les réponses forgées arrivent avant la réponse légitime, qui parvient ensuite au poste avec le même identifiant de transaction mais un contenu différent. Enfin, les adresses renvoyées pointent souvent vers une machine du réseau local, ce qui est anormal pour un domaine public.

Utiliser ces outils en audit pour valider ses défenses

Dans un audit interne autorisé, une démonstration d'ettercap DNS spoofing ou un test équivalent sert à vérifier trois choses : que les commutateurs bloquent l'usurpation ARP, que les postes rejettent une réponse non chiffrée lorsqu'un transport DNS chiffré est imposé, et que le SOC lève une alerte exploitable. Le livrable utile n'est pas la capture d'un mot de passe, mais le temps de détection mesuré et la liste des segments où l'attaque reste possible.

Conséquences d'une attaque par spoofing DNS pour l'entreprise

Rediriger un nom de domaine n'est jamais une fin en soi : c'est le levier d'une étape suivante. Les conséquences dépendent de ce que l'attaquant place au bout de la fausse adresse et des protections applicatives restantes, en particulier le chiffrement TLS et la vérification rigoureuse des certificats par les clients.

• Vol d'identifiants : une fausse page de connexion ou un relais de type homme du milieu capture mots de passe et jetons de session, comme le décrit MITRE pour la technique T1557.
• Distribution de logiciels malveillants : un serveur de mise à jour usurpé peut livrer un binaire piégé si le client ne vérifie pas la signature du paquet.
• Interception de la messagerie : en falsifiant un enregistrement MX, l'attaquant reçoit des courriels destinés à un domaine ; ce risque est distinct de l'usurpation d'expéditeur, traitée par le déploiement de DMARC, DKIM et SPF.
• Contournement des contrôles : un nom de proxy, de serveur de journalisation ou de console antivirus détourné peut neutraliser une protection sans alerte visible.
• Déni de service : une réponse pointant vers une adresse inexistante rend un service indisponible pour tous les clients d'un résolveur empoisonné.

Le chiffrement limite fortement les dégâts. Un site servi en HTTPS avec HSTS (HTTP Strict Transport Security) déclenche une erreur de certificat si l'attaquant ne possède pas de certificat valide pour le domaine. C'est pourquoi MITRE recommande de former les utilisateurs à se méfier des erreurs de certificat. Mais tous les protocoles ne vérifient pas l'identité du serveur, notamment certains automates industriels, imprimantes, agents de supervision ou scripts internes.

Un empoisonnement réussi peut même servir à obtenir un certificat : la RFC 5452 rappelait déjà que la validation d'un domaine par une autorité de certification s'appuie elle-même sur la résolution de noms. Les autorités multiplient désormais les points de vérification, mais ce scénario justifie de traiter le DNS comme une infrastructure critique, au même titre que l'annuaire ou la messagerie.

Comment détecter une attaque de DNS spoofing

La détection d'un spoofing DNS repose rarement sur un indicateur unique. Elle combine les journaux du résolveur, l'observation du trafic réseau et la télémétrie des postes. Le guide NIST SP 800-81 révision 3, publié en mars 2026, recommande d'ailleurs de journaliser requêtes et réponses DNS, de les intégrer au SIEM (plateforme de gestion des informations et événements de sécurité) et de conserver un historique complet pour la réponse à incident.

Les signaux réseau à surveiller

Une sonde réseau placée devant les résolveurs et sur les segments sensibles permet de repérer les anomalies caractéristiques d'une injection. Les indicateurs suivants offrent le meilleur rapport entre pertinence et bruit :

• deux réponses pour un même identifiant de transaction et une même question, avec des adresses différentes ;
• un afflux de réponses DNS non sollicitées vers un résolveur, dont l'identifiant ne correspond à aucune requête en attente ;
• des réponses fragmentées au niveau IP, inhabituelles pour le domaine concerné ;
• un TTL anormalement court ou incohérent par rapport à l'historique du domaine ;
• une réponse pour un domaine public pointant vers une adresse privée ou vers un hôte du segment local.

Une sonde comme Zeek consigne chaque transaction DNS avec son identifiant, ses réponses et leurs TTL, ce qui permet d'écrire ces règles de corrélation dans le SIEM. Les méthodes présentées dans notre guide SOC de détection du tunneling DNS reposent sur les mêmes journaux et peuvent être mutualisées pour limiter le coût de collecte.

Les signaux côté résolveur

Un résolveur bien configuré compte les réponses qu'il n'attendait pas. Unbound propose ainsi un seuil de réponses indésirables au-delà duquel il vide ses caches et écrit un avertissement dans ses journaux. Il est aussi utile de comparer périodiquement les serveurs de noms en cache pour vos domaines critiques avec ceux déclarés dans la zone parente : l'apparition d'un nouveau serveur NS pour une zone stable doit déclencher une enquête immédiate.

Surveiller les postes et vérifier ses propres résolveurs

Les sondes réseau ne voient pas tout : une modification locale de la configuration DNS ou une usurpation ARP (Address Resolution Protocol) sur un segment non instrumenté leur échappe. La télémétrie des postes et des commutateurs complète donc la détection d'un spoofing DNS, tandis que quelques vérifications régulières de vos résolveurs confirment que les protections attendues sont réellement actives.

Les signaux côté poste et sur le réseau local

Sur les postes Windows, l'événement 22 de Sysmon enregistre les requêtes DNS par processus avec leurs résultats, tandis que toute modification du fichier hosts ou des serveurs DNS de la carte réseau doit être remontée. MITRE recommande précisément de détecter les modifications non autorisées de /etc/hosts et /etc/resolv.conf. Sur le réseau local, arpwatch ou les journaux d'inspection ARP des commutateurs révèlent l'usurpation ARP qui précède souvent l'injection.

Les commandes ci-dessous permettent de vérifier, sur vos propres résolveurs, que la validation DNSSEC est active et que la délégation de vos domaines n'a pas été altérée. Elles sont purement défensives et utilisent des adresses de documentation à remplacer par les vôtres.

dig +dnssec www.exemple.fr A @192.0.2.53       # drapeau "ad" attendu si la zone est signée et validée
dig www.dnssec-failed.org A @192.0.2.53        # domaine de test mal signé : SERVFAIL attendu
delv @192.0.2.53 www.exemple.fr A +rtrace      # chaîne de confiance détaillée (outils BIND)
unbound-control lookup exemple.fr              # serveurs NS réellement utilisés par Unbound
dig NS exemple.fr +trace                       # délégation publiée depuis la racine
rndc managed-keys status                       # BIND : ancre racine KSK-2024 (key tag 38696) présente ?
grep "38696" /var/lib/unbound/root.key         # Unbound : même contrôle (chemin Debian)

Retour terrain : Cas typique rencontré en mission — parmi les règles DNS mises en production dans un SIEM, celles sur les noms sentinelles et les changements de délégation tiennent dans la durée, avec peu de faux positifs. La règle sur les réponses en double se révèle d'abord bruyante : retransmissions, réseaux de diffusion de contenu et équilibrage de charge produisent des réponses multiples légitimes. Elle ne devient exploitable qu'une fois restreinte aux noms sensibles et aux réponses divergentes pour un même identifiant de transaction.

DNSSEC : authentifier les réponses pour neutraliser l'empoisonnement

Les extensions de sécurité du DNS (DNSSEC, DNS Security Extensions) ajoutent une signature cryptographique aux enregistrements. Le résolveur qui valide vérifie chaque signature (RRSIG) avec la clé publique de la zone (DNSKEY), elle-même authentifiée par un condensat (DS) publié dans la zone parente, et ainsi de suite jusqu'à la racine. Une réponse forgée, même parfaitement synchronisée, échoue alors à la vérification et se trouve rejetée.

Signer ses zones et valider les réponses : deux chantiers distincts

DNSSEC ne protège que si deux conditions sont réunies : la zone interrogée est signée par son propriétaire et le résolveur utilisé valide les signatures. Signer vos domaines protège vos clients et partenaires ; activer la validation sur vos résolveurs protège vos collaborateurs lorsqu'ils consultent des domaines signés par d'autres. Notre guide d'audit DNS 2026 (SOA, SPF, DMARC, DNSSEC, DANE) détaille les contrôles à mener côté zone.

Ce retard français signifie qu'une large majorité d'internautes ne bénéficie pas de la protection DNSSEC, même lorsque le domaine consulté est correctement signé. Pour une entreprise, la conclusion est directe : ne comptez pas sur le résolveur de l'opérateur, activez la validation sur vos propres résolveurs ou choisissez un service qui valide et dont vous maîtrisez la configuration.

Limites de DNSSEC et roulement de la clé racine en 2026

DNSSEC (DNS Security Extensions) neutralise l'empoisonnement des zones signées, mais il ne s'agit pas d'une protection « posée une fois pour toutes ». Sa chaîne de confiance repose sur une clé racine qui change périodiquement, et son périmètre laisse volontairement de côté certains risques. Connaître ces limites évite un faux sentiment de sécurité et aide à planifier les mesures complémentaires.

Octobre 2026 : la racine a changé de clé

Le 11 octobre 2026, la nouvelle clé de signature de clés de la racine, KSK-2024 (identifiant 38696), a commencé à signer la zone racine, et l'ICANN a indiqué quelques jours plus tard que le roulement s'était déroulé comme prévu. Un résolveur validant qui ignorerait cette ancre de confiance considérerait les réponses signées comme altérées et renverrait des erreurs SERVFAIL. Vérifiez explicitement sa présence plutôt que de supposer que la mise à jour automatique a fonctionné.

Ce que DNSSEC ne fait pas

DNSSEC garantit l'intégrité et l'origine des données, pas leur confidentialité : les requêtes restent lisibles sur le réseau. Il ne protège pas le « dernier kilomètre » entre le poste et le résolveur, puisque la plupart des postes font confiance au résolveur sans valider eux-mêmes. Il ajoute enfin une complexité réelle : signatures expirées, roulements de clés manqués ou vulnérabilités comme KeyTrap (CVE-2023-50387), qui permettait d'épuiser le processeur d'un résolveur validant, imposent une exploitation rigoureuse.

Durcir ses résolveurs contre le spoofing DNS

Le résolveur récursif est le point où un empoisonnement produit le plus de dégâts ; c'est donc là que l'effort de protection rapporte le plus. Le guide NIST SP 800-81r3 recommande notamment de dédier les serveurs DNS à cette seule fonction, de ne pas cumuler les rôles faisant autorité et récursif sur une instance exposée à Internet et de restreindre les clients autorisés à utiliser la récursion.

1. Appliquer les correctifs : suivez les avis de l'ISC, de NLnet Labs, de PowerDNS ou de Microsoft et planifiez les mises à jour des résolveurs avec la même rigueur que celles d'un pare-feu.
2. Restreindre la récursion : n'acceptez les requêtes récursives que depuis vos plages internes ; un résolveur ouvert permet à un attaquant de déclencher à volonté les requêtes qu'il veut empoisonner.
3. Séparer les rôles : un serveur joignable depuis Internet est soit faisant autorité, soit récursif, jamais les deux à la fois.
4. Préserver l'aléa : vérifiez qu'aucun équipement de traduction d'adresses ne réécrit les ports source de façon prévisible devant vos résolveurs.
5. Activer les durcissements disponibles : validation DNSSEC, cookies DNS (RFC 7873), variation aléatoire de la casse des noms interrogés (technique dite « 0x20 »), rejet des données hors bailliage et minimisation des noms interrogés.
6. Sous Windows Server : conservez le verrouillage du cache et le pool de sockets, activés par défaut depuis Windows Server 2008 R2, et configurez des ancres de confiance si le service DNS doit valider DNSSEC.

L'extrait suivant illustre une configuration Unbound durcie pour un résolveur interne. Les plages d'adresses sont à adapter, et chaque option doit être testée en préproduction, la variation de casse pouvant gêner de rares serveurs faisant autorité non conformes.

server:
    # Récursion réservée aux réseaux internes
    access-control: 0.0.0.0/0 refuse
    access-control: 10.0.0.0/8 allow
    access-control: 192.168.0.0/16 allow
    # Validation DNSSEC avec mise à jour automatique de l'ancre racine (RFC 5011)
    auto-trust-anchor-file: "/var/lib/unbound/root.key"
    harden-dnssec-stripped: yes
    val-log-level: 2
    # Durcissements contre l'empoisonnement de cache
    harden-glue: yes
    use-caps-for-id: yes
    qname-minimisation: yes
    # Purge des caches et alerte en cas d'afflux de réponses indésirables
    unwanted-reply-threshold: 10000000
    # Discrétion et journalisation exploitable par le SIEM
    hide-identity: yes
    hide-version: yes
    log-queries: yes
    log-replies: yes

Pour BIND, les directives équivalentes sont la validation automatique (dnssec-validation auto) et une liste de contrôle d'accès dédiée à la récursion (allow-recursion). Un résolveur filtrant comme celui décrit dans notre article pilier sur AdGuard Home peut, de son côté, s'appuyer sur des serveurs amont validants interrogés en DoT ou en DoH.

Protéger les postes et le réseau local contre l'usurpation DNS

Même avec un résolveur irréprochable, la requête d'un poste peut être interceptée avant de l'atteindre. La protection de ce trajet combine des mesures réseau, qui empêchent l'attaquant de se placer sur le chemin, et des mesures de transport, qui rendent toute réponse forgée inacceptable pour le client DNS du poste.

Fermer la porte à l'homme du milieu

Sur les commutateurs, le DHCP snooping n'autorise les offres DHCP que depuis les ports de confiance, et l'inspection ARP dynamique rejette les annonces ARP qui contredisent la table de baux ainsi construite. En IPv6, les protections RA Guard et DHCPv6 Guard jouent un rôle comparable. L'authentification 802.1X et la segmentation réduisent le nombre de machines capables d'atteindre une victime. Les empoisonnements propres aux protocoles de résolution locale de Windows relèvent d'une analyse distincte.

Chiffrer le trajet entre le poste et le résolveur

Les protocoles DNS over TLS (DoT, RFC 7858), DNS over HTTPS (DoH, RFC 8484) et DNS over QUIC (DoQ, RFC 9250) authentifient le résolveur par certificat et chiffrent l'échange. Une réponse injectée sur le réseau local est alors ignorée. Le guide NIST consacre d'ailleurs une section à la restriction des résolveurs publics : pointez ces protocoles vers vos résolveurs d'entreprise, et non vers un service externe qui échapperait à votre politique et à votre journalisation.

Verrouiller la configuration DNS des postes et des domaines

Un attaquant qui ne peut pas s'intercaler sur le réseau cherchera à changer le résolveur utilisé par la victime. Bloquez donc en sortie le port 53 en UDP et en TCP, ainsi que le port 853 du DNS over TLS (DoT), pour tout équipement autre que vos résolveurs. Verrouillez les paramètres DNS des postes par stratégie de groupe ou par gestion des terminaux mobiles (MDM), et surveillez le fichier hosts avec votre outil EDR (détection et réponse sur les terminaux).

Côté domaines, exigez un verrou de registre et une authentification renforcée chez votre bureau d'enregistrement, comme le recommande le guide de l'ANSSI sur l'acquisition et l'exploitation des noms de domaine. L'agence y rappelle que la compromission de ces prestataires peut conduire à l'interception du trafic et des courriels, à des dénis de service ou à la défiguration de sites web.

Plan d'action en cinq étapes contre le DNS spoofing

Les mesures précédentes n'ont pas toutes le même coût. L'ordre suivant maximise le gain de sécurité dès les premières semaines, en commençant par ce qui ne demande ni budget ni changement d'architecture, puis en industrialisant la surveillance et le chiffrement.

1. Inventorier : lister tous les équipements qui répondent en DNS (contrôleurs de domaine, box, appliances, conteneurs), leur version et leur rôle exact.
2. Corriger : mettre à jour les résolveurs, fermer toute récursion ouverte et séparer les rôles exposés à Internet.
3. Valider : activer DNSSEC sur les résolveurs, contrôler l'ancre KSK-2024, puis signer progressivement vos zones publiques.
4. Observer : centraliser les journaux DNS, ARP et poste dans le SIEM, puis créer les alertes sur noms sentinelles et changements de délégation.
5. Chiffrer et cloisonner : imposer DoT ou DoH vers les résolveurs internes, bloquer le DNS sortant direct et activer DHCP snooping et inspection ARP.

Retour terrain : Cas typique rencontré en mission — lors d'un test d'intrusion interne autorisé, une usurpation ARP suivie de fausses réponses DNS sur un réseau utilisateur non segmenté redirige un poste de test vers une page de connexion factice. Aucune alerte ne se déclenche pendant tout l'exercice : l'inspection ARP n'est pas activée sur les commutateurs et les résolveurs ne journalisent pas les requêtes. Priorités retenues : journalisation DNS vers le SIEM, DHCP snooping et inspection ARP dynamique, puis segmentation des postes.

Pour exploiter les journaux DNS au-delà du spoofing, notre dossier sur le tunneling DNS et la détection de l'exfiltration de données par le SOC montre comment bâtir des tableaux de bord réutilisables. Les mêmes sources alimentent ainsi la détection de l'usurpation, de l'exfiltration et des communications de commande et de contrôle.

À lire aussi : les risques liés à WPAD dans Active Directory.

Questions fréquentes

Conclusion

Le DNS spoofing exploite une faiblesse originelle du protocole : la confiance accordée à la première réponse plausible. De l'attaque Kaminsky aux failles de BIND et d'Unbound corrigées fin 2025, l'histoire montre que l'aléa seul ne suffit pas et que chaque résolveur non corrigé reste une cible. La défense efficace est un empilement : correctifs, résolveurs dédiés et fermés, validation DNSSEC avec une ancre de confiance à jour, DNS chiffré jusqu'au poste et détection fondée sur des journaux corrélés.

Commencez par les mesures gratuites, à savoir l'inventaire, la mise à jour, la fermeture de la récursion et la validation DNSSEC, puis industrialisez la surveillance. Un résolveur filtrant interne, à l'image de celui décrit dans notre guide AdGuard Home, constitue un excellent point de départ pour reprendre la maîtrise du DNS de votre réseau.