Une requête DNS renvoie bien une adresse IP, mais la page refuse de se charger. Ce scénario, souvent résumé par « DNS ok mais pas de connexion », pointe vers un problème situé en aval de la résolution de noms. Le serveur DNS a fait son travail, la panne se cache ailleurs dans la chaîne réseau.
Conflit DNS IPv4 et IPv6 : la cause la plus sous-estimée
Configurer un DNS public comme 8.8.8.8 en IPv4 sans toucher aux paramètres IPv6 de la box crée un conflit entre résolveurs IPv4 et IPv6. Le système d’exploitation envoie alors certaines requêtes via le DNS IPv4 personnalisé et d’autres via le DNS IPv6 attribué automatiquement par le FAI.
Le résultat est trompeur : certains sites se chargent normalement, d’autres restent inaccessibles malgré un diagnostic DNS apparemment correct. Ce comportement hybride se généralise avec les box et les systèmes récents qui privilégient IPv6 par défaut.
Pour vérifier, ouvrez les paramètres de votre carte réseau et examinez la configuration DNS sous les propriétés IPv6 (TCPv6). Si un serveur DNS IPv6 automatique y figure alors que vous avez forcé un DNS IPv4 différent, le conflit est probable.
Corriger le conflit sur Windows
- Ouvrez les paramètres réseau, puis accédez aux propriétés de votre connexion active (Wi-Fi ou Ethernet).
- Dans les propriétés du protocole IPv6 (TCP/IPv6), remplacez le DNS automatique par un DNS public compatible IPv6, ou désactivez temporairement IPv6 pour isoler le problème.
- Videz le cache DNS après modification avec la commande ipconfig /flushdns dans une invite de commandes administrateur.
Si la navigation reprend après désactivation d’IPv6, le conflit est confirmé. La solution durable consiste à aligner les DNS IPv4 et IPv6 sur le même fournisseur.
Blocage du port 53 par le FAI : le DNS fonctionne, mais pas celui que vous croyez
Plusieurs fournisseurs d’accès redirigent le trafic DNS circulant sur le port 53 vers leurs propres résolveurs. Quand vous configurez un DNS externe, la requête part bien de votre ordinateur, mais le FAI l’intercepte et y répond à la place du serveur que vous avez choisi.
La résolution semble fonctionner puisqu’une adresse IP est renvoyée. En revanche, la connexion échoue si le FAI filtre ou manipule certaines réponses. Ce type de blocage est transparent pour l’utilisateur : aucun message d’erreur DNS n’apparaît, la panne ressemble à un problème de serveur distant.
Détecter et contourner ce blocage avec DNS-over-HTTPS
Le moyen le plus fiable de confirmer un blocage du port 53 est de tester une requête DNS chiffrée. DNS-over-HTTPS (DoH) encapsule la requête DNS dans du trafic HTTPS classique, sur le port 443, que le FAI ne peut pas intercepter de la même manière.
Sur Firefox, activez DoH dans les paramètres réseau du navigateur (Paramètres > Général > Paramètres réseau > Activer le DNS via HTTPS). Si la navigation fonctionne avec DoH activé mais échoue sans, le FAI intercepte bien vos requêtes DNS classiques.
Sur Windows, la version récente du système permet d’activer DoH directement dans les paramètres réseau, au niveau de la configuration DNS de la carte. Cela protège l’ensemble du trafic DNS de la machine, pas seulement celui du navigateur.
Pile réseau corrompue : quand le problème n’est ni DNS ni FAI
Une pile réseau fatiguée ou corrompue produit exactement le même symptôme. La résolution DNS aboutit, l’adresse IP est correcte, mais les paquets ne circulent plus normalement entre votre ordinateur et le serveur distant. Ce problème survient après des installations de VPN, des mises à jour système interrompues, ou des modifications de proxy oubliées.
Réinitialisation complète sur Windows
La séquence de commandes suivante, exécutée dans une invite de commandes administrateur, remet à zéro les composants réseau sans toucher au reste du système :
- netsh winsock reset : réinitialise le catalogue Winsock, qui gère la communication entre les applications et la pile TCP/IP.
- netsh int ip reset : remet à zéro la configuration IP, y compris les routes statiques parasites.
- ipconfig /release puis ipconfig /renew : force le renouvellement de l’adresse IP auprès du routeur.
- ipconfig /flushdns : purge le cache DNS local pour éliminer les entrées périmées.
Un redémarrage est nécessaire après ces commandes. Si le problème persiste, vérifiez dans les paramètres réseau qu’aucun proxy n’est configuré (Paramètres > Réseau > Proxy) et qu’aucun VPN résiduel n’est actif en arrière-plan.
Fichier hosts et filtrage local : des redirections invisibles
Le fichier hosts de Windows (situé dans C:\Windows\System32\drivers\etc\) est consulté avant tout serveur DNS. Une entrée qui redirige un domaine vers une adresse IP incorrecte, ou vers 127.0.0.1, produit un blocage silencieux. Certains logiciels de contrôle parental ou antimalware modifient ce fichier sans avertissement.
Ouvrez le fichier avec un éditeur de texte en mode administrateur. Toute ligne qui ne commence pas par le caractère # (commentaire) et qui associe un domaine à une adresse locale (127.0.0.1 ou 0.0.0.0) bloque l’accès à ce domaine. Supprimez ou commentez les lignes suspectes.
Le pare-feu Windows ou un antivirus tiers peuvent aussi bloquer le trafic sortant vers certains ports ou adresses, sans que la résolution DNS soit affectée. Désactivez temporairement ces protections pour isoler la cause. Si la connexion revient, le pare-feu ou l’antivirus filtre le trafic après la résolution DNS.
Diagnostic rapide : distinguer panne DNS et panne réseau
Avant de modifier quoi que ce soit, un test simple permet de trancher. Ouvrez une invite de commandes et tapez ping suivi d’une adresse IP publique connue (celle de votre passerelle ou d’un serveur externe). Si le ping aboutit, la connectivité réseau fonctionne et le problème se situe au niveau DNS ou applicatif. Si le ping échoue, la panne est réseau, pas DNS.
Testez ensuite avec la commande nslookup suivie d’un nom de domaine. Si nslookup renvoie une adresse IP mais que le navigateur refuse de charger la page, le DNS fonctionne et la panne est en aval : proxy, pare-feu, pile réseau corrompue, ou blocage du FAI.
La majorité des cas « DNS ok mais pas de connexion » se résolvent en alignant les configurations IPv4 et IPv6, en vérifiant l’absence d’interception sur le port 53, ou en réinitialisant la pile réseau. Le fichier hosts et les pare-feu locaux restent à vérifier en dernier recours, car ils produisent des blocages très ciblés, souvent limités à quelques domaines précis.
