Imaginons une organisation qui a correctement sécurisé son site web. L’application est à jour de ses correctifs, l’accès exige une authentification multifacteur et le trafic est chiffré en HTTPS.
Un attaquant compromet le compte qui sert à gérer le domaine de l’organisation et modifie un enregistrement DNS. Les utilisateurs qui saisissent la bonne adresse du site sont désormais envoyés vers une infrastructure contrôlée par l’attaquant.
L’application n’a pas été compromise. C’est le chemin qui y mène les utilisateurs qui a été modifié.
Voilà pourquoi le DNS reste précieux pour les attaquants. Il intervient très tôt dans la plupart des connexions réseau et les systèmes qui en dépendent lui font confiance. Une attaque réussie peut rediriger le trafic, interrompre des services, faciliter le vol d’identifiants ou dissimuler les communications d’un logiciel malveillant.
La sécurité du DNS ne se résume pas au durcissement d’un serveur. Les différentes composantes du système DNS remplissent des fonctions distinctes, et chacune présente sa propre surface d’attaque.
Trois rôles DNS à ne pas confondre
| Rôle DNS | Ce qu’il fait | Ce qu’un attaquant y gagne |
|---|---|---|
| DNS faisant autorité | Publie les enregistrements officiels d’un domaine | La possibilité de rediriger ou de perturber les services qui utilisent ce domaine |
| Résolveur récursif | Trouve les réponses DNS pour les utilisateurs et les met en cache | La possibilité d’influencer ou d’observer l’endroit où de nombreux clients se connectent |
| Administration DNS | Contrôle les domaines, les serveurs de noms, les enregistrements et les clés de signature | Le contrôle de la configuration DNS elle-même |
Une organisation peut assurer certaines de ces fonctions en interne et en confier d’autres à des bureaux d’enregistrement (registrar), des fournisseurs cloud ou des services DNS gérés. Savoir qui opère chaque rôle est le point de départ de sa sécurisation.
Pourquoi le DNS offre un tel levier
Il intervient dans presque toutes les connexions
Les utilisateurs manipulent des noms comme portal.example.com. Les applications, elles, ont en définitive besoin d’adresses réseau et d’autres informations sur les services. Le DNS fournit cette correspondance.
Si le DNS est indisponible, de nombreuses applications paraissent indisponibles alors même que leurs serveurs fonctionnent normalement. Si le DNS renvoie une réponse falsifiée, le client peut se connecter à la mauvaise destination. Le DNS est donc à la fois une dépendance et un point de contrôle.
Il ne sert pas qu’aux sites web
Les enregistrements DNS permettent de localiser les systèmes de messagerie, les services d’identité, les points de terminaison applicatifs et d’autres éléments d’infrastructure. Des technologies comme SPF, DKIM et DMARC s’appuient aussi sur des enregistrements DNS pour l’authentification des e-mails.
Dans les environnements Windows, le DNS est étroitement lié à la découverte des services Active Directory. Une atteinte au DNS interne peut donc perturber l’authentification, l’application des stratégies et l’accès aux ressources de l’organisation.
Il a été conçu pour un modèle de confiance plus ancien
Le DNS traditionnel privilégiait la résolution de noms distribuée et la disponibilité. Les réponses DNS de base n’ont pas été conçues pour prouver cryptographiquement qu’elles provenaient du propriétaire légitime ou qu’elles n’avaient pas été modifiées.
Les extensions de sécurité et les transports chiffrés corrigent une partie de cette faiblesse, mais leur déploiement n’a rien d’automatique et chaque mesure répond à un problème différent.
Toutes les attaques ne se ressemblent pas
Détournement de domaines et d’enregistrements
Si un attaquant compromet un compte auprès d’un bureau d’enregistrement ou d’un hébergeur DNS, ou un compte d’administration, il peut modifier la délégation des serveurs de noms ou des enregistrements individuels. Il s’agit d’une attaque sur le plan de contrôle : l’attaquant utilise des fonctions de gestion légitimes sans en avoir légitimement l’autorité.
Les conséquences peuvent dépasser la simple redirection d’un site web. Des modifications DNS peuvent rediriger les e-mails, perturber les processus de validation de domaine ou, dans certains cas, aider un attaquant à obtenir des certificats de confiance.
Une authentification forte, des rôles d’administration restreints, le verrou de registre (registry lock) lorsqu’il est disponible, des alertes sur les modifications et une procédure de récupération conservée de manière indépendante comptent ici davantage que le durcissement du logiciel serveur DNS.
Déni de service
Les attaquants peuvent inonder les serveurs faisant autorité ou les résolveurs jusqu’à ce que les requêtes légitimes ne puissent plus recevoir de réponse. Comme de très nombreuses applications dépendent du DNS, une seule attaque peut faire paraître plusieurs services hors ligne en même temps.
Des serveurs redondants situés dans le même bâtiment ou sur le même réseau n’offrent pas une résilience suffisante. Les organisations ont besoin d’une diversité de fournisseurs, de réseaux et d’implantations géographiques proportionnée à leur niveau de risque. Les plateformes gérées de DNS faisant autorité utilisent souvent l’anycast, qui répartit le service sur de nombreux sites, mais les clients doivent toujours protéger les comptes et les configurations qui pilotent ce service.
Empoisonnement de cache
Les résolveurs récursifs mettent les réponses en cache pour améliorer les performances. Si un attaquant amène un résolveur à stocker une réponse falsifiée, les clients qui s’appuient sur ce cache peuvent être envoyés vers une destination choisie par l’attaquant.
Les résolveurs modernes intègrent des protections, et DNSSEC peut permettre de valider les données DNS signées. L’empoisonnement de cache n’a pas disparu pour autant. Les travaux sur les protocoles et les implémentations se poursuivent, car l’analyse syntaxique, la mise en cache et la validation restent complexes.
Réflexion et amplification
Le DNS utilise couramment UDP, qui n’établit pas de connexion avant l’envoi d’une réponse. Un attaquant peut usurper l’adresse source de la victime et envoyer des requêtes à des serveurs DNS exposés. Ces serveurs envoient alors leurs réponses à la victime.
Lorsqu’une petite requête produit une réponse plus volumineuse, l’attaque bénéficie d’un effet d’amplification. Réserver le service récursif aux clients autorisés, éviter les résolveurs ouverts et appliquer la validation des adresses sources aident à limiter cet usage abusif.
Le DNS comme canal pour les logiciels malveillants
Un logiciel malveillant doit souvent localiser son infrastructure de commande ou envoyer des informations hors du réseau. Les attaquants peuvent recourir à des domaines qui changent rapidement, à des noms de domaine générés, à une infrastructure fast-flux ou au tunneling DNS pour rendre ces communications plus difficiles à bloquer.
Le DNS n’est donc pas seulement un élément à protéger. C’est aussi une source précieuse de télémétrie de sécurité. Des volumes de requêtes inhabituels, des noms longs qui semblent encodés, des domaines récemment enregistrés et des échecs répétés peuvent révéler des appareils compromis.
Ce que DNSSEC et le DNS chiffré résolvent réellement
Les discussions sur la sécurité du DNS traitent souvent DNSSEC, DNS over HTTPS et DNS over TLS comme des améliorations interchangeables. Ils protègent pourtant des propriétés différentes.
DNSSEC permet à un résolveur validant de vérifier l’origine et l’intégrité des données DNS signées. Il aide à se défendre contre les réponses falsifiées et l’empoisonnement de cache. Il ne chiffre pas la requête, ne masque pas le domaine demandé et ne maintient pas la disponibilité d’un service DNS pendant une attaque.
DNS over HTTPS (DoH) et DNS over TLS (DoT) chiffrent le trafic DNS entre un client et un résolveur. Cela protège la requête contre une simple observation ou une altération sur ce trajet. Cela ne prouve pas que le propriétaire du domaine a publié le bon enregistrement, et cela ne rend pas digne de confiance le résolveur choisi.
Le DNS chiffré implique aussi un compromis opérationnel. Si des appareils utilisent à l’insu de l’organisation des résolveurs externes, celle-ci peut perdre l’application de ses politiques et sa capacité de surveillance au niveau de son service DNS approuvé. Un déploiement sécurisé exige donc davantage que l’activation du chiffrement : il faut décider quels résolveurs sont autorisés et comment l’activité DNS restera observable.
Un modèle de défense pragmatique
Protéger l’autorité
- Utiliser une authentification multifacteur résistante à l’hameçonnage pour les comptes auprès du bureau d’enregistrement et de l’hébergeur DNS, lorsqu’elle est prise en charge.
- Séparer les comptes utilisateurs du quotidien de l’administration DNS.
- Restreindre les personnes habilitées à modifier la délégation, les enregistrements et les clés DNSSEC.
- Déclencher des alertes sur les modifications de serveurs de noms, de zones, d’enregistrements et de comptes.
- Conserver les contacts de récupération et les preuves de propriété du domaine en dehors de la plateforme DNS concernée.
Séparer les rôles
Les serveurs faisant autorité doivent publier des zones. Les résolveurs récursifs doivent répondre aux clients. Combiner un service public faisant autorité avec une récursion sans restriction accroît l’exposition et rend les politiques plus difficiles à analyser.
Limitez la récursion aux réseaux ou aux identités autorisés. N’autorisez les transferts de zone que vers les serveurs secondaires habilités. Tenez les interfaces de gestion à l’écart de l’internet public partout où c’est possible.
Concevoir en prévision des pannes
Utilisez des serveurs faisant autorité indépendants et éliminez les dépendances à un fournisseur ou à un réseau unique lorsque l’impact métier le justifie. Surveillez le DNS depuis l’extérieur de l’organisation, afin de détecter les pannes même lorsque la supervision interne dépend du même service DNS.
Sauvegardez les données de zone et la configuration, mais testez aussi la restauration. Une sauvegarde ne règle ni la compromission du bureau d’enregistrement ni les modifications malveillantes de délégation, sauf si le processus de récupération couvre aussi ces couches.
Faire du DNS une mesure de sécurité
Les services de DNS de protection bloquent la résolution des domaines malveillants connus avant qu’une connexion ne soit établie. La CISA et le National Cyber Security Centre britannique décrivent le DNS de protection comme un moyen de réduire l’efficacité de l’hameçonnage, des logiciels malveillants, des botnets et des rançongiciels.
Collectez les journaux des résolveurs avec des contrôles adaptés en matière de confidentialité et de conservation. Croisez les événements DNS avec les éléments issus des terminaux, des identités et du réseau. Une requête suspecte devient plus utile lorsque les analystes peuvent identifier l’appareil et l’utilisateur à l’origine de la requête ainsi que la connexion qui a suivi.
Appliquer les correctifs sur l’ensemble du chemin
La sécurité du DNS ne dépend pas seulement des logiciels DNS dédiés. Les systèmes d’exploitation, les routeurs, les pare-feu, les bureaux d’enregistrement, les portails de gestion et les identifiants d’automatisation peuvent tous influer sur le comportement du DNS.
En 2026, le National Cyber Security Centre britannique a indiqué qu’APT28 avait exploité des routeurs vulnérables pour mener des opérations de détournement DNS et d’adversary-in-the-middle. La leçon dépasse cette campagne : un attaquant peut manipuler le DNS par l’intermédiaire de l’infrastructure environnante plutôt qu’en compromettant directement le serveur faisant autorité.
Ce que les professionnels de la technologie doivent savoir
La plupart des développeurs n’ont pas besoin d’exploiter des serveurs DNS, mais ils doivent comprendre que la disponibilité et l’identité d’une application commencent avant que la requête n’atteigne leur code.
Les ingénieurs cloud et plateforme doivent savoir quel service fait autorité, quels résolveurs utilisent les charges de travail, comment interagissent les zones privées et publiques, et comment le DNS tombe en panne d’une région à l’autre. Les équipes de sécurité doivent traiter l’administration des domaines comme une infrastructure à privilèges et exploiter les journaux DNS dans leur dispositif de détection. Les dirigeants doivent savoir qui peut récupérer le domaine si le compte d’administration habituel est indisponible ou compromis.
La question la plus utile pour commencer est simple :
Si nos réponses DNS devenaient aujourd’hui indisponibles ou indignes de confiance, quels services tomberaient en panne — et qui pourrait rétablir l’autorité ?
Si personne ne peut répondre avec assurance, l’organisation a mis le doigt sur une faille de sécurité et de résilience qui mérite d’être corrigée.
Pour aller plus loin
- NIST SP 800-81 Revision 3 : Secure Domain Name System Deployment Guide — recommandations actuelles pour le DNS faisant autorité, les résolveurs récursifs, DNSSEC, le DNS chiffré, le DNS de protection et la sécurité des déploiements. Publié en mars 2026.
- CISA and NSA guidance on Protective DNS — explique comment le filtrage DNS peut réduire l’exposition aux domaines malveillants.
- RFC 7873 : Domain Name System Cookies — décrit une protection limitée contre les attaques par déni de service, par amplification, par falsification et par empoisonnement de cache.
- Microsoft guidance for securing DNS zone transfers — conseils pratiques pour restreindre les transferts de zone du DNS Windows.
- NCSC advisory on APT28 DNS hijacking — un exemple de 2026 de manipulation du DNS via une infrastructure environnante compromise.