Dans un contexte où les entreprises multiplient les connexions distantes, les accès VPN et les architectures hybrides, la configuration DNS devient un point névralgique souvent sous-estimé. Pourtant, une erreur de paramétrage ou un oubli dans la gestion des requêtes DNS peut entraîner des conséquences lourdes : exposition de ressources internes, fuites d’informations sensibles, compromission de l’infrastructure, voire contournement des politiques de sécurité. Dans cet article, nous allons examiner pourquoi et comment une mauvaise configuration DNS peut fragiliser la sécurité d’un réseau d’entreprise, en abordant notamment le rôle des VPN, d’Active Directory et des pièges liés au DNS split tunneling. Une sensibilisation indispensable pour les administrateurs réseau, les DSI et toute organisation soucieuse de sa résilience numérique.

Les fondamentaux du DNS dans un réseau d’entreprise

Le DNS (Domain Name System) est un composant fondamental de toute infrastructure réseau moderne. Son rôle dépasse largement la simple traduction d’un nom de domaine en adresse IP. Dans un réseau d’entreprise, le DNS est un service critique qui conditionne l’accès aux ressources internes, l’authentification des utilisateurs et la communication entre les différents composants du système d’information. Concrètement, le DNS assure la résolution des noms lisibles par l’humain (par exemple intranet.entreprise.local) vers des adresses IP exploitables par les machines. Mais dans un environnement professionnel, cette résolution repose généralement sur un ou plusieurs serveurs DNS internes, très souvent intégrés aux contrôleurs de domaine Active Directory. Dans une architecture Active Directory, le DNS n’est pas optionnel. Il est utilisé pour :

• Localiser les contrôleurs de domaine via les enregistrements SRV,
• Permettre l’authentification Kerberos,
• Assurer la réplication entre contrôleurs de domaine,
• Résoudre les noms des serveurs applicatifs internes,
• Garantir le bon fonctionnement des stratégies de groupe (GPO).

Les zones DNS internes sont généralement hébergées sur les contrôleurs de domaine et peuvent être intégrées à Active Directory. Cela permet une réplication sécurisée des enregistrements DNS entre serveurs, un contrôle fin des droits de modification et une meilleure résilience en cas de panne. En parallèle, ces serveurs DNS internes doivent aussi permettre la résolution des noms de domaine publics (sites web, services cloud, API externes). Pour cela, ils sont souvent configurés avec un mécanisme de forwarding DNS, c’est-à-dire une redirection des requêtes non connues vers un ou plusieurs résolveurs externes tels que Google DNS, Cloudflare ou OpenDNS.

Ce rôle hybride (résolution interne et relais externe)  est précisément là où les premières failles peuvent apparaître. Une mauvaise hiérarchisation des flux DNS, une absence de filtrage ou un manque de contrôle sur les résolveurs autorisés peut conduire à des comportements imprévus, voire dangereux. Les problèmes commencent réellement lorsque les postes clients ne respectent plus ce schéma de résolution centralisé. Cela peut arriver de manière involontaire ou délibérée, pour plusieurs raisons :

• VPN mal configuré qui n’impose pas l’utilisation du DNS interne et laisse les requêtes DNS sortir via la connexion locale de l’utilisateur,
• Postes personnels (BYOD) connectés au réseau de l’entreprise sans politique DNS stricte ni configuration GPO,
• Navigateurs ou applications qui activent par défaut le DNS over HTTPS (DoH) ou le DNS over TLS (DoT), contournant totalement l’infrastructure DNS interne,
• Logiciels malveillants ou outils d’administration détournés qui redirigent le trafic DNS vers des serveurs contrôlés par un tiers.

Dans ces situations, les requêtes DNS échappent au contrôle de l’entreprise. Elles peuvent être résolues par des entités externes, exposant des informations sensibles telles que :

• les noms des applications internes,
• la structure du réseau et des sous-domaines,
• les habitudes de navigation des utilisateurs,
• les flux applicatifs liés à des services métiers critiques.

Ce type de fuite ouvre la voie à plusieurs risques majeurs : fuite de données, usurpation de résolution DNS (DNS spoofing ou poisoning), attaques de type man-in-the-middle, ou encore surveillance externe par des fournisseurs d’accès, des réseaux Wi‑Fi publics ou des acteurs malveillants.

Dans un environnement professionnel, le DNS ne doit donc jamais être considéré comme un simple service d’infrastructure « annexe ». Il constitue un point de contrôle stratégique qui doit être maîtrisé, surveillé et intégré pleinement dans la politique de sécurité globale du système d’information.

VPN, Active Directory et DNS : Un équilibre délicat pour les entreprises

La mise en place d’un VPN d’entreprise vise à sécuriser les connexions distantes, notamment pour les collaborateurs en télétravail ou les équipes en mobilité. Cependant, beaucoup de déploiements VPN ne prennent pas en compte la gestion fine du trafic DNS. Lorsque le tunnel VPN est établi, il est censé rediriger tout ou partie du trafic vers l’infrastructure interne. Cela inclut bien entendu les requêtes DNS, qui doivent transiter par le serveur DNS de l’entreprise. Or, dans de nombreux cas, les configurations VPN par défaut ne forcent pas cette redirection, ou utilisent une méthode mixte appelée DNS split tunneling. Le split tunneling DNS consiste à envoyer les requêtes internes (vers les domaines de l’entreprise) via le VPN, tandis que les requêtes publiques passent directement par la connexion locale de l’utilisateur. Cette approche vise à alléger le trafic réseau et améliorer la vitesse de navigation. Mais elle introduit des failles :

• Une mauvaise définition des domaines internes peut laisser passer des requêtes sensibles hors VPN ;
• Les attaquants peuvent exploiter cette configuration pour injecter de faux enregistrements DNS ou rediriger les utilisateurs ;
• Les logs DNS peuvent être visibles par le FAI local de l’utilisateur, révélant l’activité professionnelle.

Ce problème est particulièrement critique dans les environnements basés sur Active Directory, où le DNS joue un rôle central pour l’authentification, la localisation des contrôleurs de domaine, la réplication, et le bon fonctionnement global du domaine. Une résolution DNS incomplète ou perturbée peut entraîner des erreurs d’accès, des ralentissements, voire des échecs de connexion au domaine. Les risques les plus fréquents liés à cette configuration sont :

• Une dégradation de la sécurité : Les postes clients ne résolvent plus correctement les noms internes ou tombent sur des IP erronées ;
• Des tentatives d’interception DNS par des réseaux Wi-Fi publics ou compromis ;
• Une perte de visibilité pour les équipes IT, qui ne peuvent plus tracer les requêtes DNS sortantes.

Dans ce contexte, il est essentiel de configurer les VPN pour forcer l’usage du DNS interne, désactiver le split tunneling DNS sauf exception maîtrisée, et surveiller l’activité DNS sortante.

Comment sécuriser la configuration DNS de votre réseau d’entreprise

La sécurisation de la couche DNS dans un réseau d’entreprise repose avant tout sur une politique de configuration cohérente, centralisée et proactive. Ce n’est pas une question de moyens techniques exceptionnels, mais bien de rigueur dans les paramétrages, de contrôle des flux réseau et de sensibilisation des utilisateurs et administrateurs réseaux. Un DNS mal géré peut devenir un vecteur de fuite d’informations, d’attaque ou de contournement des règles de sécurité. Voici les mesures techniques essentielles pour éviter ces dérives :

• Forcer l’usage des serveurs DNS internes sur tous les postes de travail (fixes et mobiles). Cela implique :
  • une configuration serveur cohérente (DHCP, VPN, DNS Push),
  • la mise en place de GPO (Group Policy Object) dans les environnements Active Directory pour interdire la modification manuelle des paramètres DNS sur les clients,
  • l’ajout de règles sur les clients nomades pour rediriger systématiquement le trafic DNS vers le serveur interne, même hors réseau.
• Bloquer l’utilisation des résolveurs DNS publics (comme 8.8.8.8, 1.1.1.1, 9.9.9.9) par les postes internes :
  • en interdisant les requêtes DNS sortantes sur le port UDP 53, mais aussi sur TCP 53, 443 et 853 (ports utilisés pour DoH et DoT),
  • via des ACL (Access Control Lists) ou des politiques de filtrage sur le firewall ou le proxy,
  • en auditant régulièrement les flux pour détecter les résolutions non autorisées.
• Désactiver le split tunneling DNS sur les connexions VPN, sauf cas spécifiques maîtrisés. Par défaut, toutes les requêtes DNS doivent transiter par le tunnel sécurisé. Si un DNS split tunneling est maintenu pour des raisons de performance :
  • restreindre les domaines publics autorisés via une liste blanche dynamique,
  • segmenter les profils utilisateurs en fonction de leur rôle et de leur niveau de sécurité requis.
• Activer la journalisation des requêtes DNS sur les serveurs internes :
  • via les fonctions d’audit du DNS Microsoft (ou Bind/Unbound dans un environnement Unix),
  • en couplant cette journalisation avec des systèmes de détection de comportements anormaux (par exemple, des requêtes vers des domaines exotiques ou très récents, signe d’une attaque de type beaconing ou exfiltration).
• Mettre en place une surveillance centralisée des flux DNS :
  • via des plateformes de type SIEM (Security Information and Event Management),
  • ou à l’aide de sondes réseau capables de capter et d’analyser les trames DNS (passives ou inline),
  • en créant des alertes en cas de résolutions anormales (nombre élevé de requêtes, domaines inconnus, résolutions hors plages autorisées).
• Sensibiliser les utilisateurs à l’impact des extensions de navigateur et des fonctionnalités activées par défaut, notamment :
  • le DNS over HTTPS (DoH) dans Firefox, Chrome et Edge, qui force les requêtes vers des résolveurs publics sans passer par le DNS local,
  • les applications de messagerie ou de collaboration qui embarquent leur propre résolution DNS, parfois en passant par des CDN ou réseaux de distribution globaux,
  • l’usage d’outils de développement ou d’administration système pouvant modifier les configurations réseau locales.
• Intégrer la couche DNS dès la conception de l’architecture réseau, notamment dans les environnements :
  • multi-sites, où les latences DNS peuvent impacter les performances applicatives,
  • cloud ou hybrides (Azure, AWS, GCP), où la résolution interne doit être redondée, compatible avec les services managés et intégrée à l’identité fédérée,
  • avec segmentation réseau ou micro-segmentation (Zero Trust), nécessitant un contrôle très précis des flux DNS entre zones de sécurité.

Enfin, pour les organisations à forte exigence de confidentialité (secteurs sensibles, R&D, juridique, secteur public, etc.), il est pertinent d’aller plus loin en déployant :

• Des serveurs DNS internes capables de chiffrer les échanges DNS (via DoT ou DNSCrypt) ;
• Un cache DNS local ou en périphérie pour réduire les dépendances externes et améliorer la résilience ;
• Des politiques DNS dynamiques basées sur le contexte utilisateur (localisation, identité, type de terminal).

En associant ces bonnes pratiques, vous transformez le DNS d’un simple composant technique en véritable levier de sécurité réseau. Il devient un point de contrôle, un capteur de signaux faibles, et un rempart contre de nombreuses attaques invisibles à d’autres niveaux. Bien entendu, rien ne vaut ici l’intervention d’une entreprise spécialisée en infogérance informatique.