Un indicateur DNS rouge dans un diagnostic réseau ne signale pas toujours une panne réelle. Depuis que les navigateurs modernes activent le DNS chiffré (DoH) par défaut, les outils de test interrogent souvent le résolveur de la box ou du système, alors que le navigateur résout déjà les noms via un tunnel chiffré vers Cloudflare, Google ou Quad9. Comprendre ce décalage évite de perdre du temps sur un faux positif.
DNS chiffré du navigateur et faux négatif sur le test DNS
Chrome, Edge et Firefox proposent désormais une option « Utiliser un DNS sécurisé » (DoH) activée par défaut dans plusieurs configurations. Quand cette fonction est active, les requêtes DNS contournent le résolveur déclaré dans les paramètres réseau de l’OS ou du routeur.
A lire en complément : Transfert de fichier Excel vers Google Drive : les étapes clés
Le test DNS de votre box ou d’un outil tiers continue pourtant d’interroger le résolveur classique. Si celui-ci est lent, mal configuré ou injoignable, le diagnostic affiche un voyant rouge, alors que la navigation fonctionne normalement dans le navigateur.
TP-Link documente ce cas précis : pour que leurs interfaces locales soient joignables, il faut désactiver « Use Secure DNS » dans le navigateur. Ce n’est pas un bug, c’est un conflit de couche.
A voir aussi : Comment configurer un VPN sur Windows : étapes essentielles
Avant toute manipulation, nous recommandons de vérifier si le problème est réel. Ouvrez un terminal et lancez une résolution manuelle :
nslookup google.comsur Windows ou macOS pour interroger directement le serveur DNS configuré dans l’OSnslookup google.com 1.1.1.1pour forcer la requête vers Cloudflare et comparer le résultat- Si la seconde commande répond mais pas la première, le problème se situe sur votre résolveur local, pas sur votre connexion
Empilement de configurations DNS : la cause que les guides ignorent
La majorité des articles de dépannage suggèrent de « changer de DNS » ou de « vider le cache ». Ces manipulations traitent un symptôme sans identifier la couche responsable. Sur un poste moderne, le DNS peut être configuré à quatre niveaux distincts qui se superposent.
Le routeur (paramètres WAN ou DHCP) distribue un DNS à tous les appareils du réseau local. Windows, macOS, Android ou iOS permettent ensuite de forcer un autre DNS dans les propriétés de l’adaptateur réseau. Android propose en plus un champ « DNS privé » dans les paramètres de connectivité. Le navigateur ajoute sa propre couche DoH.
Si un VPN est actif, il impose encore un autre résolveur. Résultat : une requête DNS peut être interceptée, redirigée ou bloquée à chaque étage, et le test qui affiche « DNS rouge » interroge rarement la bonne couche.
Nous observons régulièrement ce scénario : un utilisateur configure un DNS public sur le routeur et un autre dans Windows, puis active DoH dans Chrome. Trois résolveurs coexistent, et le diagnostic réseau de la box ne voit que le sien, celui qui est peut-être le seul à ne pas fonctionner.
Identifier le niveau maître et éliminer les doublons
La correction ne consiste pas à multiplier les DNS partout. Elle consiste à choisir un seul point de configuration et à s’assurer que les autres niveaux héritent ou restent en automatique.
- Si vous configurez le DNS sur le routeur (Cloudflare 1.1.1.1 ou Google 8.8.8.8 par exemple), laissez Windows et le navigateur en « obtenir automatiquement »
- Si vous préférez contrôler le DNS par appareil, laissez le routeur distribuer le DNS du FAI et configurez uniquement l’OS
- Désactivez le DoH du navigateur si vous voulez que le DNS de l’OS soit respecté, ou inversement, activez-le et considérez que c’est lui le maître
- Un VPN actif prend la main sur tout le reste : inutile de configurer un DNS alternatif tant que le tunnel est monté
Vider le cache DNS : quand c’est vraiment utile
Le vidage du cache DNS local est le premier réflexe recommandé partout. Il reste pertinent dans un cas précis : un enregistrement DNS a changé récemment (migration de site, changement d’hébergeur, modification de zone) et votre machine conserve l’ancienne adresse IP en cache.
Sur Windows, la commande ipconfig /flushdns purge le cache du résolveur système. Sur macOS, sudo dscacheutil -flushcache suivi de sudo killall -HUP mDNSResponder fait le même travail. Sur Linux, cela dépend du service de cache actif (systemd-resolved, nscd ou dnsmasq).
En revanche, vider le cache ne sert à rien si le résolveur lui-même est injoignable. Si nslookup échoue même en pointant directement un DNS public, le problème est en amont : connectivité réseau, pare-feu ou filtrage du port 53 (voire du port 443 pour DoH).
Pare-feu et filtrage du port 53 : un blocage DNS silencieux
Un pare-feu local ou d’entreprise qui bloque le trafic sortant sur le port UDP/TCP 53 empêche toute résolution DNS classique. Le navigateur avec DoH activé contourne ce blocage en passant par le port 443 (HTTPS), ce qui explique à nouveau pourquoi la navigation peut fonctionner alors que le test DNS est rouge.
Pour diagnostiquer ce cas, nous recommandons de tester la connectivité au port 53 directement :
Test-NetConnection -ComputerName 1.1.1.1 -Port 53 sur PowerShell, ou nc -vz 1.1.1.1 53 sur macOS/Linux. Si la connexion échoue, le pare-feu filtre le trafic DNS non chiffré.
Certains antivirus intègrent un composant de filtrage DNS qui intercepte les requêtes pour les analyser. WatchGuard, par exemple, propose un proxy DNS transparent qui peut modifier le comportement de résolution sans que l’utilisateur en soit conscient. Désactiver temporairement le pare-feu ou l’antivirus permet de confirmer ou d’écarter cette piste.
Redémarrage du routeur et renouvellement du bail DHCP
Quand les vérifications précédentes n’ont rien donné, un redémarrage du routeur reste une étape valide. Le firmware du routeur maintient son propre cache DNS et ses associations DHCP. Un redémarrage force le renouvellement du bail et la récupération des DNS à jour depuis le FAI.
Après le redémarrage, vérifiez que le routeur a bien récupéré des DNS valides dans son interface d’administration (section WAN ou État de la connexion). Si les champs DNS primaire et secondaire sont vides ou affichent 0.0.0.0, le problème vient de la liaison avec le FAI, pas de votre configuration locale.
Un test DNS rouge ne mérite pas toujours une série de manipulations. Identifier la couche qui pose réellement problème, du navigateur au routeur en passant par l’OS et le pare-feu, évite les corrections aveugles. La plupart des faux positifs disparaissent dès qu’on aligne la configuration DNS sur un seul niveau maître et qu’on comprend le rôle du DNS chiffré dans l’équation.
