Votre navigateur affiche une page blanche, mais le diagnostic réseau Windows indique que le DNS fonctionne. Ce décalage entre un test « DNS ok » et une navigation réellement bloquée est plus fréquent qu’on ne le pense, surtout depuis que Windows 11 gère nativement le DNS chiffré. Comprendre pourquoi le test réussit alors que la connexion échoue permet de cibler la bonne correction, au lieu d’enchaîner des manipulations inutiles.
Pourquoi le test DNS affiche « ok » alors que la connexion échoue
Quand vous lancez nslookup ou ipconfig /all dans l’invite de commandes, ces outils interrogent le serveur DNS classique sur le port 53. Si ce serveur répond correctement, le diagnostic conclut que tout va bien.
Le navigateur, lui, peut utiliser un chemin différent. Depuis que Windows 11 expose DNS over HTTPS (DoH) dans ses paramètres réseau, les requêtes de résolution passent parfois par un canal HTTPS chiffré. Si ce canal est mal configuré, bloqué par un pare-feu ou en conflit avec un VPN, la résolution échoue côté applicatif, même si le DNS classique fonctionne parfaitement.
C’est exactement ce décalage qui produit des messages comme « DNS PROBE FINISHED NXDOMAIN » ou « le serveur DNS ne répond pas » dans le navigateur, alors que la ligne de commande ne détecte aucun problème.
DNS over HTTPS mal configuré sur Windows 11 : la cause invisible
Avez-vous activé DoH sans vérifier les paramètres de repli ? C’est la source d’erreur la plus courante sur les machines récentes.
Windows 11 propose trois modes pour DoH : automatique, manuel, ou avec l’option « Fallback to plaintext ». Le mode manuel exige un template HTTPS valide. Si ce template est incorrect ou si le serveur DNS choisi ne supporte pas DoH, les requêtes chiffrées échouent silencieusement.
Vérifier et corriger la configuration DoH
Ouvrez Paramètres, puis Réseau et Internet, puis les propriétés de votre connexion (Wi-Fi ou Ethernet). Dans la section « Attribution du serveur DNS », vérifiez deux points :
- Le serveur DNS renseigné supporte bien le protocole DoH (les DNS publics de Google, Cloudflare ou Quad9 le prennent en charge, mais pas tous les DNS de fournisseurs d’accès).
- L’option « Fallback to plaintext » est activée. Sans elle, aucune résolution ne passe si le canal chiffré est bloqué.
- Si vous avez renseigné un template HTTPS manuellement, comparez-le caractère par caractère avec celui documenté par votre fournisseur DNS.
Le réflexe le plus rapide : repassez temporairement le DNS en mode non chiffré. Si la navigation reprend, le problème vient bien de la couche DoH.
Conflit entre VPN, DNS privé et réseau d’entreprise
Un VPN actif modifie le serveur DNS utilisé par votre machine. Quand ce VPN cohabite avec un DNS privé ou une politique réseau d’entreprise (proxy, inspection TLS, pare-feu), les requêtes DNS chiffrées peuvent être interceptées ou rejetées.
Le résultat est toujours le même : le test DNS en ligne de commande réussit via le résolveur de secours, mais le navigateur, qui tente de passer par le tunnel chiffré, n’obtient aucune réponse.
Identifier le conflit réseau
Déconnectez le VPN, puis testez la navigation. Si les pages se chargent, le conflit est confirmé. Deux pistes pour le résoudre :
- Configurer le VPN pour qu’il utilise les mêmes serveurs DNS que votre réseau local, plutôt que ses propres résolveurs.
- Désactiver DoH tant que le VPN est actif, pour que toutes les requêtes passent par le canal classique non chiffré.
- Vérifier auprès de votre administrateur réseau si une politique de filtrage bloque le trafic HTTPS sur le port 443 vers les résolveurs DNS publics.
Sur un poste professionnel, ce type de conflit est particulièrement fréquent. Les politiques de sécurité d’entreprise bloquent souvent les requêtes DoH pour conserver la visibilité sur le trafic DNS.
Commandes de diagnostic DNS sur Windows : ipconfig et nslookup
Avant de modifier quoi que ce soit, deux commandes permettent de localiser précisément le problème.
Vider le cache DNS local
Ouvrez une invite de commandes en mode administrateur, puis tapez ipconfig /flushdns. Cette commande purge le cache de résolution local. Un enregistrement DNS corrompu ou expiré dans ce cache peut provoquer un échec de navigation alors que le serveur DNS lui-même fonctionne.
Enchaînez avec ipconfig /all pour vérifier l’adresse IP du serveur DNS configuré, le masque de sous-réseau et la passerelle par défaut. Si l’adresse DNS affichée ne correspond pas à celle que vous avez choisie, un autre service (VPN, DHCP, politique de groupe) l’a remplacée.
Tester la résolution avec nslookup
Tapez nslookup suivi du nom de domaine que vous tentez d’atteindre, puis de l’adresse IP du serveur DNS souhaité. Par exemple : nslookup example.com 8.8.8.8.
Si la réponse est positive avec ce serveur mais que le navigateur échoue toujours, le problème ne vient pas du serveur DNS. Il se situe entre votre machine et la couche applicative, c’est-à-dire exactement dans la configuration DoH ou VPN décrite plus haut.
Changer de serveur DNS : quand et comment le faire
Remplacer le serveur DNS de votre fournisseur d’accès par un résolveur public est pertinent dans un cas précis : quand nslookup échoue avec le DNS par défaut mais réussit avec un autre. Cela signifie que le serveur DNS de votre FAI est en panne ou surchargé.
Pour modifier le serveur DNS sous Windows, ouvrez les propriétés de votre connexion réseau, passez l’attribution DNS en mode manuel, puis renseignez les adresses du résolveur choisi. Relancez ensuite le navigateur.
Si nslookup réussit avec tous les serveurs testés, changer de DNS ne résoudra rien. Le problème se situe ailleurs, probablement dans la configuration DoH, un conflit VPN, ou un pare-feu applicatif.
Avant de multiplier les modifications, notez toujours les paramètres d’origine. Un mauvais réglage DNS peut rendre toute navigation impossible, y compris l’accès aux pages d’aide en ligne. Garder une trace écrite de la configuration initiale reste le meilleur filet de sécurité.
