Le DNS (Domain Name System) traduit les noms de domaine lisibles par l’humain en adresses IP exploitables par les machines. Chaque connexion à un site, chaque appel d’API, chaque synchronisation logicielle commence par une résolution DNS. C’est le système nerveux du réseau d’entreprise, et pourtant il reste l’un des composants les moins surveillés du système d’information.
Cette asymétrie n’a pas échappé aux attaquants. Le DNS sert de canal de commande et contrôle, de vecteur d’exfiltration par tunneling, et de cible pour le détournement de domaine. La bonne nouvelle : parce qu’il est un point de passage obligé, le DNS est aussi un poste d’observation et de contrôle exceptionnel. Bien instrumenté, il devient une ligne de défense à coût modéré.
Cet article propose une lecture opérationnelle de la sécurité DNS pour un SI d’entreprise. La grille de référence est le NIST SP 800-81 [1], complétée par les recommandations de la CISA sur le Protective DNS [2] et les RFC fondatrices de l’écosystème.
Pourquoi le DNS est une cible et un angle mort
Le DNS est attaqué parce qu’il est partout et rarement filtré. Selon le panorama de la menace de l’ENISA, les vecteurs réseau et l’abus de services légitimes figurent durablement parmi les techniques les plus exploitées dans les compromissions d’entreprise [6].
Trois familles d’abus dominent.
Le command-and-control (C2). Un poste compromis a besoin de joindre son serveur de pilotage. Plutôt que d’ouvrir une connexion suspecte, le malware utilise le DNS : il interroge des domaines à génération algorithmique (DGA) qui changent en permanence, ce qui complique le blocage par liste statique. Le trafic ressemble à des requêtes DNS ordinaires.
L’exfiltration par tunneling. Le tunneling DNS encode des données dans les sous-domaines des requêtes. Comme le port 53 sort presque toujours sans inspection, c’est un canal discret pour faire fuiter des fichiers ou maintenir un canal bidirectionnel. Le débit est faible, mais suffisant pour des secrets, des bases de mots de passe ou du vol progressif de données.
Le détournement et l’empoisonnement. L’empoisonnement de cache, le détournement de domaine (compromission du compte registrar) ou la manipulation des réponses permettent de rediriger les utilisateurs vers des infrastructures contrôlées par l’attaquant, sans qu’aucune alerte ne se déclenche côté poste.
L’angle mort vient d’un constat simple : dans beaucoup d’organisations, les requêtes DNS ne sont ni journalisées ni analysées. Le SOC voit le trafic web, les flux pare-feu, les événements EDR, mais pas le DNS. Or le DNS précède tout le reste. Surveiller le DNS, c’est observer l’intention avant l’action.
Durcir les résolveurs et l’infrastructure DNS
La première couche consiste à reprendre le contrôle de l’infrastructure de résolution elle-même.
Centraliser la résolution. Tous les postes et serveurs doivent utiliser les résolveurs internes de l’entreprise, pas des résolveurs publics configurés au cas par cas. Un parc qui résout via une dizaine de fournisseurs différents est impossible à journaliser et à filtrer de façon cohérente. La règle : un ou deux résolveurs internes, redondants, et un blocage en sortie des requêtes DNS directes vers Internet (port 53 et résolveurs DoH publics).
Séparer les rôles. Le serveur faisant autorité pour les zones internes ne doit pas être le même que le résolveur récursif exposé aux requêtes utilisateurs. Le NIST SP 800-81 recommande explicitement cette séparation pour limiter la surface d’attaque [1]. Un serveur faisant autorité ne doit jamais accepter de récursion ouverte.
Appliquer les bonnes pratiques de durcissement. Limitation des transferts de zone aux seuls serveurs secondaires autorisés, désactivation de la récursion ouverte, restriction des requêtes ANY souvent utilisées en amplification, mise à jour régulière des logiciels (BIND, Unbound, serveurs Microsoft). Ces mesures relèvent de l’hygiène, mais leur absence transforme un résolveur en relais d’attaque par déni de service distribué.
Protéger le registrar et les comptes DNS. Le détournement de domaine passe souvent par la compromission du compte chez le bureau d’enregistrement, pas par une faille technique. Authentification forte sur le compte registrar, verrou de transfert (registry lock) sur les domaines critiques, et liste restreinte d’administrateurs. Cette mesure rejoint les principes d’une architecture où l’on ne fait confiance à aucun accès par défaut, détaillés dans notre guide de déploiement Zero Trust en cinq étapes.
DNSSEC : garantir l’intégrité, pas la confidentialité
DNSSEC (DNS Security Extensions, RFC 4033 [3]) ajoute des signatures cryptographiques aux réponses DNS. Le résolveur peut alors vérifier qu’une réponse provient bien de la zone légitime et n’a pas été falsifiée en chemin. C’est la parade contre l’empoisonnement de cache et le spoofing.
Le point à comprendre, et la confusion la plus fréquente en réunion : DNSSEC ne chiffre rien. Les requêtes et réponses restent en clair sur le réseau. DNSSEC apporte l’authenticité et l’intégrité, pas la confidentialité. Un observateur passif voit toujours quels domaines sont interrogés.
Deux volets pour une entreprise :
La validation. Le résolveur interne valide les signatures DNSSEC des domaines qui en publient. C’est un réglage à activer, peu coûteux, qui protège les utilisateurs contre des réponses falsifiées pour les domaines signés.
La signature. Les zones de l’entreprise (en particulier les domaines exposés publiquement) sont signées avec DNSSEC, pour que les visiteurs validants puissent vérifier l’authenticité des réponses. Cette opération demande une gestion rigoureuse des clés (rotation des KSK et ZSK) car une erreur de signature rend le domaine injoignable pour les résolveurs validants.
DNSSEC est une brique d’intégrité solide, mais isolée elle ne bloque aucun domaine malveillant et ne détecte aucun tunneling. Elle se combine avec les autres couches.
Protective DNS : le filet de sécurité à déployer en priorité
Le Protective DNS (PDNS) est probablement le meilleur rapport effort sur bénéfice de toute la sécurité DNS. Le principe est simple : le résolveur consulte des listes de domaines malveillants connus (phishing, C2, distribution de malware, domaines DGA) et refuse de les résoudre, renvoyant une réponse neutre ou une page de blocage.
La CISA américaine en a fait un service de référence et documente publiquement son efficacité contre une large part des chaînes d’attaque qui démarrent par un domaine malveillant [2]. Le mécanisme technique sous-jacent côté serveur est souvent la Response Policy Zone (RPZ), qui permet de réécrire ou de bloquer des réponses selon une politique.
Pourquoi c’est efficace : la plupart des attaques modernes passent par un nom de domaine à un moment de leur chaîne. Le lien de phishing pointe vers un domaine. La charge utile se télécharge depuis un domaine. Le malware contacte son C2 via un domaine. Bloquer la résolution casse la chaîne en amont, avant même l’établissement de la connexion. C’est une défense préventive qui complète l’EDR (qui agit sur le poste) et le pare-feu (qui agit sur le flux).
Trois options de déploiement :
- Service de PDNS managé : un fournisseur opère le résolveur filtrant et maintient les listes. Mise en œuvre rapide, peu d’effort interne, mais les requêtes transitent par un tiers (à cadrer côté confidentialité et conformité).
- Résolveur interne avec flux de threat intelligence : on enrichit le résolveur existant avec des listes RPZ alimentées par des sources de renseignement sur la menace, dont les indicateurs publiés par le CERT-FR [7]. Plus de contrôle, plus d’effort.
- Approche hybride : PDNS managé en première ligne, résolveur interne pour la journalisation et les règles spécifiques à l’organisation.
Quel que soit le choix, deux exigences : maîtriser les faux positifs (un domaine légitime bloqué génère un ticket de support immédiat, donc prévoir un processus de mise en liste blanche rapide) et journaliser tous les blocages, car chaque blocage est un signal de sécurité exploitable.
DNS chiffré : maîtriser DoH et DoT sans créer d’angle mort
Le transport DNS historique est en clair. Deux protocoles le chiffrent : DNS over HTTPS (DoH, RFC 8484 [4]) et DNS over TLS (DoT, RFC 7858 [5]). Tous deux protègent la confidentialité des requêtes contre l’observation passive sur le réseau.
Pour une entreprise, le sujet n’est pas binaire. Le DNS chiffré est une bonne chose côté confidentialité, mais déployé sans contrôle il devient un problème de sécurité.
Le risque du DoH non maîtrisé. Les navigateurs modernes peuvent activer le DoH automatiquement vers un résolveur public (Cloudflare, Google), en contournant complètement le résolveur de l’entreprise. Résultat : le filtrage Protective DNS est court-circuité, et le SOC perd toute visibilité sur les requêtes. Un poste compromis peut ainsi communiquer avec son C2 sans qu’aucun journal interne ne le voie. Le DoH non contrôlé crée précisément l’angle mort qu’on cherche à supprimer.
La bonne posture. On ne bloque pas le chiffrement, on le réoriente. La cible : les postes utilisent le résolveur interne de l’entreprise, et c’est ce résolveur qui parle DoH ou DoT en sortie vers l’amont. Le chiffrement protège alors le transport sans casser le filtrage ni la journalisation, qui s’opèrent au niveau du résolveur interne.
Concrètement :
- Désactiver le DoH automatique des navigateurs par stratégie d’entreprise (stratégie de groupe pour Edge et Chrome, paramètre dédié pour Firefox via le domaine canary).
- Imposer le résolveur interne par configuration DHCP et par stratégie poste.
- En défense en profondeur, bloquer en sortie les résolveurs DoH publics connus (par liste d’IP et de domaines), pour empêcher les contournements applicatifs.
- Faire parler le résolveur interne en DoT ou DoH vers ses propres amonts, pour bénéficier du chiffrement sans perte de contrôle.
Cette logique de canalisation du trafic chiffré rejoint celle des architectures réseau convergées, traitée dans notre article sur SASE et SD-WAN pour moderniser le réseau d’entreprise.
Journaliser et détecter : transformer le DNS en capteur
Sans journalisation, toutes les couches précédentes restent aveugles aux abus qui passent à travers. La journalisation DNS est le pilier de détection.
Quoi journaliser. Les requêtes (nom interrogé, type d’enregistrement, source), les réponses, et les blocages PDNS. Ces journaux sont volumineux : un SI de quelques milliers de postes génère des millions de requêtes par jour. La centralisation dans un SIEM ou une plateforme d’analyse est indispensable, et nos recommandations sur la journalisation et la détection par les logs en entreprise s’appliquent directement ici.
Quoi détecter. Plusieurs signatures comportementales sont exploitables :
- Tunneling DNS : volume anormal de requêtes vers un même domaine, sous-domaines longs et à forte entropie (chaînes aléatoires), prédominance de types d’enregistrement inhabituels (TXT, NULL).
- Domaines à génération algorithmique : pics de requêtes vers des noms de domaine non prononçables, taux élevé de réponses NXDOMAIN (le malware teste de nombreux domaines avant de trouver le bon).
- Beaconing : requêtes régulières et périodiques vers un même domaine, signe d’un canal C2 qui prend des nouvelles à intervalle fixe.
- Résolutions vers des domaines récemment enregistrés, statistiquement plus risqués.
Ces analyses alimentent directement la détection réseau. Le DNS est d’ailleurs l’une des sources de télémétrie clés d’une démarche de Network Detection and Response, qui corrèle les signaux DNS avec les flux réseau pour reconstituer une chaîne d’attaque.
Conservation et conformité. Les durées de conservation des journaux DNS doivent être cohérentes avec la politique de journalisation globale et les obligations sectorielles. La directive NIS2 impose des capacités de détection, de journalisation et de réponse aux incidents [8] ; le DNS est une source de preuve précieuse lors de l’investigation post-incident, notamment pour reconstituer le déroulé d’une compromission par rançongiciel.
Articulation avec NIS2 et la gouvernance cyber
La sécurité DNS ne figure pas nommément dans les textes réglementaires, mais elle répond à plusieurs exigences de la directive NIS2 (Directive (UE) 2022/2555, article 21 [8]) :
- Maîtrise des actifs et des flux réseau (centralisation des résolveurs).
- Mesures de prévention et de détection des incidents (Protective DNS, journalisation).
- Capacité de réponse et d’investigation (journaux DNS comme source de preuve).
- Sécurité de la chaîne d’approvisionnement (protection du registrar et des domaines).
Pour une entité essentielle ou importante au sens de NIS2, démontrer une surveillance et un filtrage DNS structurés contribue à la démonstration de conformité, sans être à elle seule suffisante. La sécurité DNS s’intègre dans la gouvernance cyber d’ensemble, avec des indicateurs propres : taux de postes résolvant via les résolveurs internes, volume de blocages PDNS, délai de détection des anomalies DNS, couverture de la journalisation.
Feuille de route pragmatique
Pour une entreprise de taille intermédiaire, une trajectoire réaliste s’organise en paliers.
Palier 1, semaines 1 à 4. Inventaire des résolveurs utilisés, centralisation vers les résolveurs internes, blocage des résolutions DNS directes en sortie. Activation de la journalisation des requêtes et centralisation dans le SIEM. C’est le socle : sans visibilité, rien d’autre ne tient.
Palier 2, mois 2 à 3. Déploiement d’un Protective DNS (managé ou interne), avec processus de gestion des faux positifs. Activation de la validation DNSSEC sur les résolveurs internes. Désactivation du DoH automatique des navigateurs par stratégie d’entreprise.
Palier 3, mois 4 à 6. Mise en place des règles de détection (tunneling, DGA, beaconing) dans le SIEM. Signature DNSSEC des domaines publics de l’entreprise. Durcissement du compte registrar (MFA, registry lock) et séparation des rôles autorité/récursif.
Palier 4, continu. Revues régulières des journaux, ajustement des listes de blocage, intégration des indicateurs DNS dans le tableau de bord cyber. La sécurité DNS, comme le reste, est une discipline continue et non un projet ponctuel.
Le vocabulaire technique de cet article (RPZ, DGA, KSK, beaconing) est détaillé dans notre glossaire cyber et réseau pour les équipes qui découvrent le sujet.
À retenir
Le DNS est un point de passage obligé du trafic réseau, ce qui en fait à la fois une cible de choix pour les attaquants et un capteur de premier ordre pour la défense. La trajectoire utile combine quatre couches complémentaires : durcir l’infrastructure de résolution, garantir l’intégrité des réponses avec DNSSEC, bloquer les domaines malveillants avec un Protective DNS, et journaliser puis analyser les requêtes pour détecter tunneling, DGA et beaconing. Le DNS chiffré (DoH, DoT) protège la confidentialité, mais doit être canalisé par le résolveur interne sous peine de créer un angle mort. Aucune de ces couches ne remplace les autres, et aucune ne se substitue à l’EDR, au pare-feu ou au SIEM : la sécurité DNS est une pièce de la défense en profondeur, peu coûteuse et trop souvent négligée. À jour au juin 2026.
Sources
[1] NIST, Special Publication 800-81 Rev. 2, Secure Domain Name System (DNS) Deployment Guide. https://csrc.nist.gov/publications/detail/sp/800-81/2/final [2] CISA, Protective Domain Name System (DNS) Resolver. https://www.cisa.gov/resources-tools/services/protective-domain-name-system-resolver [3] IETF, RFC 4033, DNS Security Introduction and Requirements (DNSSEC). https://www.rfc-editor.org/rfc/rfc4033 [4] IETF, RFC 8484, DNS Queries over HTTPS (DoH). https://www.rfc-editor.org/rfc/rfc8484 [5] IETF, RFC 7858, Specification for DNS over Transport Layer Security (DoT). https://www.rfc-editor.org/rfc/rfc7858 [6] ENISA, ENISA Threat Landscape 2024. https://www.enisa.europa.eu/publications/enisa-threat-landscape-2024 [7] CERT-FR (ANSSI), Cyber Threat Intelligence. https://www.cert.ssi.gouv.fr/cti/ [8] Directive (UE) 2022/2555 (NIS2). https://eur-lex.europa.eu/eli/dir/2022/2555/oj