Un résultat « DNS ok » rassure. Il confirme que la résolution de noms pointe vers les bons serveurs et qu’aucun détournement de type DNSChanger n’est actif sur la machine testée. Le problème, c’est que ce diagnostic couvre une fraction de plus en plus mince du spectre réel des menaces. Nous observons sur les réseaux que nous auditons un décalage croissant entre la confiance accordée à ce test et la protection effective qu’il procure contre les malwares contemporains.
Communication directe par IP : la zone aveugle du test DNS
Un filtrage DNS, quel que soit le fournisseur, intercepte les requêtes de résolution de noms. Si un binaire malveillant contacte son serveur de commande et contrôle (C2) via une adresse IP codée en dur, la requête ne transite jamais par le résolveur. Le test « DNS ok » ne voit rien, le filtre DNS non plus.
Près de la moitié des échantillons de malwares analysés récemment communiquent directement par IP sans passer par une résolution DNS. Ce chiffre transforme la portée réelle d’un contrôle DNS : il ne couvre, dans le meilleur cas, qu’environ la moitié du trafic C2 sortant.
Le phénomène n’est pas nouveau, mais son ampleur l’est. Les familles de type stealer ou loader intègrent désormais des listes d’IP de repli qui s’activent dès que la résolution DNS échoue ou tarde. Un réseau qui s’appuie uniquement sur un DNS protectif laisse donc passer une part significative du trafic malveillant sortant.
Traffic Distribution Systems DNS : l’infrastructure d’évasion que le test ne détecte pas
Les Traffic Distribution Systems (TDS) exploitent le DNS comme couche de routage dynamique. Un domaine résolu aujourd’hui pointe vers un serveur légitime, demain vers un kit de phishing, après-demain vers un proxy résidentiel. Le test ponctuel « DNS ok » capture un instantané qui ne reflète pas ce comportement rotatif.
Les données Infoblox de 2026 sont parlantes : la très grande majorité des réseaux d’entreprise étudiés ont été exposés à des TDS DNS servant de camouflage pour des scams et des malwares. Environ deux tiers des terminaux ont interrogé des domaines liés à des proxys résidentiels masquant du trafic malveillant derrière des adresses IP grand public.
Nous recommandons de distinguer deux niveaux de diagnostic :
- Le test DNS ponctuel (type dns-ok.fr ou outil VPN) vérifie l’intégrité de la configuration résolveur à un instant T, sans analyse comportementale.
- L’analyse passive DNS (pDNS) sur la durée détecte les changements de résolution suspects, les domaines à durée de vie très courte (DGA) et les flux vers des TDS connus.
- L’inspection du trafic chiffré sortant (TLS fingerprinting, JA3/JA4) identifie les connexions C2 qui contournent entièrement le DNS.
Un « DNS ok » valide le premier niveau. Les deux suivants restent invisibles sans outillage dédié.
DNS protectif et cadres réglementaires : NIST, CISA, NIS2
À partir de 2024, plusieurs cadres normatifs ont élevé le DNS protectif au rang de contrôle de sécurité à part entière. Le NIST, dans la révision SP 800-81r3, traite explicitement la sécurisation DNS comme un composant de l’architecture réseau, pas comme un simple test de bon fonctionnement. La CISA recommande l’adoption d’un protective DNS en tant que service managé pour les agences fédérales américaines, et les CIS Controls intègrent désormais le filtrage DNS dans leurs mesures prioritaires.
En Europe, la directive NIS2 impose aux entités concernées une gestion des risques qui couvre la chaîne de résolution de noms. Le Cyber Resilience Act complète le dispositif côté fabricants d’équipements connectés. Concrètement, un audit de conformité NIS2 ne se satisfera pas d’un screenshot « DNS ok » : il attend une politique de filtrage documentée, des journaux de requêtes conservés, et une capacité de détection des anomalies DNS.
Ce que le régulateur attend versus ce que le test fournit
Le fossé est net. Un test de type dns-ok.fr répond à une question binaire : vos résolveurs sont-ils compromis par un malware spécifique ? Les exigences réglementaires couvrent la journalisation, la détection de tunnels DNS (exfiltration de données encapsulées dans des requêtes TXT ou CNAME), le blocage de domaines malveillants en temps réel et la résilience de l’infrastructure DNS elle-même face aux attaques DDoS.
Un test DNS ponctuel ne constitue pas une mesure de sécurité au sens des référentiels actuels. Il reste un outil de diagnostic utile, mais limité à la vérification d’intégrité du résolveur.
Tunnels DNS et exfiltration : le trafic malveillant qui passe par le résolveur légitime
Certains malwares ne contournent pas le DNS, ils l’utilisent comme canal de communication. TrickBot, par exemple, a intégré des variantes exploitant le DNS tunneling pour ses échanges C2. Les requêtes ressemblent à du trafic DNS normal, transitent par le résolveur configuré, et un test « DNS ok » les considère comme parfaitement saines.
Le principe est simple : les données sont encodées dans les sous-domaines des requêtes (par exemple, base64 dans un enregistrement TXT). Le résolveur fait son travail, la réponse revient, le malware récupère ses instructions. Aucune anomalie visible au niveau de la configuration DNS.
Détecter ce type de trafic exige une analyse volumétrique et entropique des requêtes DNS sortantes. Les solutions de type DNS protectif avancé (Infoblox, Cisco Umbrella, Quad9 avec threat feeds) inspectent le contenu des requêtes, pas seulement leur destination. C’est une couche supplémentaire que le test basique ne prétend pas couvrir.
Construire un diagnostic DNS réellement utile contre les malwares
Un test « DNS ok » garde sa place comme vérification de premier niveau. Il détecte les détournements grossiers et les résolveurs corrompus. Considérer ce résultat comme une garantie de protection contre les malwares est une erreur de cadrage.
Pour un diagnostic qui couvre réellement le spectre des menaces liées au DNS, nous recommandons de combiner :
- Un filtrage DNS avec threat intelligence en temps réel, capable de bloquer les domaines DGA et les TDS identifiés.
- Une analyse passive DNS interne pour repérer les résolutions anormales (volume, entropie, TTL inhabituels).
- Un contrôle du trafic sortant hors DNS (connexions IP directes, trafic chiffré suspect) via un pare-feu applicatif ou un NDR.
- Une journalisation DNS conforme aux exigences NIS2, avec conservation et capacité d’investigation.
Le résultat « DNS ok » valide un point de contrôle, pas une posture de sécurité. La distinction entre ces deux notions détermine la pertinence réelle de votre protection réseau.
