En bref. La formule « dns ok » recouvre trois réalités : un résolveur qui répond correctement et traduit les noms de domaine en adresses IP, le résultat d’un test en ligne hérité de l’affaire DNSChanger, et l’erreur « Not All DNS ok » affichée par Cisco Umbrella quand son appliance n’atteint plus ses serveurs de résolution. Un DNS sain répond sur le port 53 en quelques millisecondes. Un DNS détourné renvoie votre trafic vers des serveurs contrôlés par des pirates, souvent sans modifier l’apparence de votre navigateur.
Un technicien voit passer cette mention dans trois contextes qui n’ont presque rien en commun : un test de compromission en ligne, la supervision d’un parc d’entreprise et un simple diagnostic de connexion. Derrière ces deux mots se cache pourtant une question très concrète : le service qui traduit les noms de domaine en adresses IP répond-il normalement ? De cette réponse dépendent la navigation, la messagerie, les mises à jour logicielles et, dans une organisation, une bonne partie de l’activité quotidienne.
Contenu de l'article :
Que signifie exactement dns ok selon le contexte ?
Le DNS, ou Domain Name System, fait le pont entre un nom lisible, cyfernet.org par exemple, et l’adresse IP de la machine qui héberge le service. Quand tout se passe bien, cette résolution prend quelques millisecondes et le navigateur affiche la page demandée. Un DNS « ok » décrit donc un état de santé : les requêtes partent, les réponses reviennent, le cache se remplit correctement.
La deuxième acception vient de l’histoire. En 2012, une opération judiciaire internationale surnommée Ghost Click met fin aux activités d’un groupe qui exploitait le cheval de Troie DNSChanger. Pour ne pas couper brutalement l’accès Internet de centaines de milliers de machines encore infectées, les serveurs du botnet ont été maintenus en fonctionnement quelques mois sous la surveillance de l’ISC, avec l’appui d’acteurs comme Google. Un site de test, dns-ok.fr, permettait alors de savoir en une visite si la configuration DNS de son poste restait normale ou passait sous contrôle criminel, sans installation ni manipulation.
Troisième usage, plus professionnel : Cisco Umbrella et ses appliances affichent l’alerte « Not All DNS ok » lorsque la communication avec les résolveurs attendus est interrompue. Ici, il n’est plus question de logiciel malveillant mais de flux réseau filtré, de pare-feu trop strict ou de port fermé.
Vérifier l’état d’un DNS sans alourdir le diagnostic
Le réflexe utile consiste à comparer ce que la machine reçoit du réseau avec ce qui est attendu. Sur un poste Windows, la commande ipconfig /all affiche les serveurs hérités du bail DHCP. Sur macOS et Linux, les mêmes informations ressortent d’un fichier de configuration ou d’une commande d’interrogation. Si l’adresse annoncée n’est ni celle de votre box, ni celle de votre fournisseur d’accès, ni un résolveur public connu, il y a matière à creuser.
Un test visuel comme celui proposé à l’époque de DNSChanger n’avait qu’un mérite : il ne demandait aucune compétence technique et ne s’installait pas sur la machine. Ce principe reste pertinent en entreprise, où l’on préfère interroger un résolveur de référence et comparer sa réponse avec celle du résolveur configuré. Deux réponses identiques pour un même nom de domaine indiquent un chemin de résolution cohérent. Une différence franche trahit une redirection, et donc une piste à instruire.
Cette vérification reste non intrusive : aucune modification n’est apportée au poste, aucun agent n’est déployé. C’est précisément ce qui la rend acceptable lors d’un contrôle ponctuel sur un parc que l’on ne veut pas perturber.
Erreur « Not All DNS ok » : pourquoi Umbrella perd le contact
L’alerte apparaît quand l’appliance virtuelle ou le connecteur ne parvient plus à joindre les adresses de résolveurs qu’Umbrella lui impose. Le trafic DNS circule en principe sur le port 53, en UDP pour l’essentiel et en TCP pour les réponses volumineuses. Dès qu’un équipement intermédiaire ferme ce port, la vérification échoue et l’état global bascule.
| Point de contrôle | Ce qui déclenche l’alerte |
|---|---|
| Port 53 | Fermeture du port en sortie vers les résolveurs attendus, ou redirection vers un résolveur interne non déclaré. |
| Résolveurs autorisés | Absence d’autorisation pour 208.67.222.222 et 208.67.220.220 dans le pare-feu. |
| Prérequis de déploiement | Adressage, passerelle ou routage incomplets sur l’appliance virtuelle. |
| Dispositif d’inspection | Un équipement qui réécrit ou bloque les requêtes sans être déclaré comme intermédiaire légitime. |
| Fenêtre de contrôle | Une période pendant laquelle aucun des quatre résolveurs requis ne répond à l’appliance. |
La correction suit toujours la même logique : autoriser les adresses de résolveurs requises dans le pare-feu, vérifier que rien ne réécrit le port 53 en chemin, puis relancer le contrôle depuis la console. Quand l’accès à l’appliance est verrouillé, l’ouverture d’un tunnel d’assistance à la demande reste la voie la plus rapide pour un administrateur pressé.
Symptômes d’une résolution de noms de domaine défaillante
Les signes observables sont souvent discrets au début, puis deviennent bloquants. La liste ci-dessous regroupe ceux qui reviennent le plus souvent dans les remontées de support.
- Les pages mettent plusieurs secondes à s’afficher alors que la connexion semble active.
- Un site s’ouvre depuis un téléphone en 4G mais pas depuis le poste du bureau.
- Des pages de destination inconnues ou des publicités intrusives remplacent le site attendu.
- La messagerie et la visioconférence échouent alors qu’un test vers une adresse IP brute passe sans difficulté.
- La supervision remonte des pics de requêtes sans lien avec l’activité réelle des utilisateurs.
- Les journaux du résolveur mentionnent des réponses en cache pour des noms qui devraient être interrogés à distance.
Ces signes ne désignent pas une cause unique. Une résolution lente peut venir d’un serveur surchargé, d’un cache corrompu ou d’une latence vers un résolveur distant. Une redirection peut venir d’un logiciel malveillant, d’un routeur compromis ou d’une modification manuelle oubliée. Le recoupement entre plusieurs postes fait souvent la différence : un incident isolé oriente vers la machine, un incident général oriente vers le réseau.
DHCP, requêtes en double et saturation du résolveur
Sur un réseau domestique comme sur un réseau d’entreprise, la configuration DNS est très souvent distribuée par DHCP. Si le bail est mal renseigné ou si plusieurs serveurs DHCP se répondent, le poste peut recevoir deux jeux de résolveurs et alterner entre eux. Le symptôme est déroutant : la connexion fonctionne par intermittence, sans qu’aucune panne matérielle ne soit identifiable. Comparer le bail reçu avec la configuration attendue, et vérifier au passage l’adresse ip publique de la box, permet de reconstituer la chaîne complète.
Un autre cas, très documenté dans les communautés d’auto-hébergement, concerne les requêtes DNS émises en double. Un résolveur domestique de type pihole peut enregistrer près de 7 000 requêtes en 10 secondes, avec de nombreuses entrées identiques marquées comme servies depuis le cache. Quand le moteur plafonne à environ 150 requêtes simultanées, les nouvelles demandes patientent puis échouent. Les causes vont d’un client mal configuré à une boucle de résolution entre deux résolveurs, en passant par des enregistrements CNAME mal construits.
La couche matérielle compte aussi. Un Smart Switch mal segmenté peut isoler le poste du résolveur sans que la liaison soit coupée, ce qui donne l’illusion d’un DNS capricieux alors que l’origine du problème se situe ailleurs.
Infection, mauvaise configuration ou filtrage : trancher rapidement
Distinguer les trois familles de causes évite de perdre du temps sur la mauvaise piste. Une compromission touche en général quelques machines, avec des symptômes persistants et une configuration DNS qui diffère de celle des postes voisins. Une erreur de configuration, elle, se corrige en une modification et concerne souvent tout un segment réseau, parce qu’elle provient du DHCP ou d’un modèle de déploiement. Un filtrage, enfin, laisse passer certaines requêtes et en bloque d’autres, selon l’heure ou la destination.
Dans les environnements administrés, les résolveurs ne sont pas libres. Le cas de L’école 0 avec Toutatice illustre bien cette contrainte : les établissements scolaires utilisent des résolveurs imposés par l’académie, et toute dérogation locale provoque des blocages difficiles à interpréter. Avant d’accuser le DNS, il faut donc vérifier la politique appliquée au réseau.
Reste une règle simple : un diagnostic DNS se conduit par élimination. On contrôle d’abord la couche matérielle et le bail DHCP, puis le filtrage réseau, et seulement ensuite on envisage une compromission. Cette progression évite de réinstaller un poste pour un port fermé et de chercher un logiciel malveillant là où un pare-feu fait simplement son travail. Une sauvegarde de la configuration d’origine, prise avant toute modification, reste la meilleure assurance pour revenir en arrière.
Pourquoi la mention dns ok s’affiche alors que la navigation reste impossible ?
La résolution peut très bien fonctionner alors que le port 443 ou 80 est bloqué, ou qu’un certificat interdit la connexion. Un test DNS ne dit rien de la couche applicative.
Qu’est-ce que DNSChanger et faut-il encore s’en préoccuper ?
DNSChanger est un cheval de Troie qui remplaçait les serveurs DNS de la machine par ceux d’un réseau criminel. Le botnet a été démantelé en 2012, mais le principe reste utilisé : un logiciel malveillant peut encore modifier la configuration DNS d’un poste ou d’un routeur.
Qui doit autoriser les résolveurs d’Umbrella dans un pare-feu ?
L’équipe réseau ou l’administrateur en charge du déploiement. Les adresses 208.67.222.222 et 208.67.220.220 doivent être joignables sur le port 53, en sortie comme en retour, sans interception non déclarée.
Quand lancer un test de compromission DNS ?
Après un doute sur un poste, après une alerte de sécurité, ou de façon ponctuelle sur un parc ancien. Un test lancé aujourd’hui n’a de valeur que sur l’état actuel de la machine.
Comment réduire les requêtes DNS en double sur un résolveur local ?
Il faut inspecter les journaux pour identifier le client fautif, vérifier les enregistrements CNAME, allonger la durée de vie du cache et s’assurer qu’un seul résolveur répond sur le segment réseau.
Faut-il changer soi-même de serveur DNS ?
Sur un réseau d’entreprise, non : la politique de résolution est définie par l’équipe réseau. Sur un réseau domestique, c’est possible, à condition de garder une trace de la configuration d’origine pour pouvoir revenir en arrière.
Où se situe le blocage quand la supervision perd les résolveurs ?
Souvent entre l’appliance et l’extérieur, sur un pare-feu, un proxy transparent ou un équipement de filtrage. Comparer les journaux du résolveur et ceux du pare-feu suffit généralement à localiser la coupure.
