« Serveur DNS ne répond pas » : que faire, dans quel ordre

Ce message signifie une seule chose : votre machine a envoyé une requête sur le port 53 et n'a rien reçu avant expiration du délai. Le serveur visé peut être en ligne et répondre à tout le monde sauf à vous, car la cause se trouve le plus souvent entre votre carte réseau et votre box.

Sommaire

Ce que Windows vous dit exactement

L'assistant « Diagnostiquer les problèmes de connexion » affiche cette phrase quand il a interrogé les résolveurs configurés sur la carte active et n'a rien reçu en retour. Rien de plus. Il ne teste pas la santé du serveur, il constate un silence. Un pare-feu local qui mange l'UDP sortant produit exactement le même verdict qu'un résolveur réellement éteint.

Les délais expliquent l'attente avant l'affichage. Le client DNS de Windows patiente environ une seconde après la première requête, puis réémet vers tous les serveurs de toutes les cartes avec des délais de 2, 4 et 8 secondes. Sous Linux, le résolveur glibc utilise par défaut timeout:5 et attempts:2, soit dix secondes par serveur listé dans /etc/resolv.conf avant de passer au suivant. Une page qui met une quinzaine de secondes à s'ouvrir puis finit par s'afficher désigne un premier résolveur muet, pas une panne totale.

Le test de séparation tient en une commande : ping 1.1.1.1. Si les réponses arrivent, la couche IP va bien et seule la résolution est cassée. Chrome affiche alors ERR_NAME_NOT_RESOLVED ou DNS_PROBE_FINISHED_NO_INTERNET pendant qu'une adresse IP littérale tapée dans la barre reste parfaitement joignable.

Localiser la panne en trois commandes

L'ordre compte : on interroge d'abord un résolveur public connu, ensuite celui de la box, ensuite on regarde ce que la machine a réellement configuré. Chaque étape élimine une couche.

dig réessaie trois fois avec cinq secondes d'attente par essai (+tries=3 +time=5). Un « connection timed out; no servers could be reached » après une quinzaine de secondes est donc un vrai silence et pas une simple lenteur.

dig @1.1.1.1 adresse-ip.fr +short : une réponse immédiate signifie que la sortie sur le port 53 fonctionne et que le coupable est votre résolveur habituel.
dig @192.168.1.1 adresse-ip.fr (mettez l'IP de votre box) : silence ici après un succès à l'étape précédente, le relais DNS de la box est figé.
dig @1.1.1.1 adresse-ip.fr +tcp : si l'UDP reste muet et que le TCP répond, un équipement filtre ou fragmente l'UDP/53.
Sans dig sous Windows : nslookup adresse-ip.fr 9.9.9.9, ou Resolve-DnsName adresse-ip.fr -Server 9.9.9.9 en PowerShell.
Get-DnsClientServerAddress -AddressFamily IPv4 sous Windows, resolvectl status sous Linux systemd : la liste des résolveurs vraiment actifs, interfaces VPN comprises.

Ce que vous obtenez	Interprétation	Où chercher
ping 1.1.1.1 échoue aussi	La panne n'est pas DNS	Câble, Wi-Fi, bail DHCP, passerelle
Résolveur public OK, box muette	Forwarder de la box planté	Redémarrage box, ou DNS public distribué par DHCP
UDP muet, +tcp répond	Filtrage ou fragmentation sur le port 53	Pare-feu, antivirus, client VPN, MTU
status: SERVFAIL	Le serveur répond mais échoue à produire la donnée	DNSSEC ou zone cassée, tester dig +cd
status: NXDOMAIN	Le nom n'existe pas	Faute de frappe, domaine expiré
Résolveur en 10.x hors VPN	Configuration laissée par un client VPN	Réinitialiser les DNS de la carte

Les causes réelles, de la plus banale à la plus tordue

Le relais DNS des box (Livebox, Freebox, box SFR ou Bouygues) est un petit forwarder embarqué avec peu de mémoire. Il sature, il garde des entrées mortes, il se bloque. Une coupure électrique de trente secondes remet en route un grand nombre de cas signalés sur un seul foyer. Si la panne revient chaque semaine, arrêtez d'utiliser la box comme résolveur et distribuez 1.1.1.1 et 9.9.9.9 directement par DHCP.

Une adresse en 169.254.x.x dans ipconfig /all veut dire que le DHCP n'a jamais répondu. Sans bail, pas de passerelle et pas de serveur DNS transmis : le message DNS n'est alors qu'un symptôme d'une panne située un cran plus bas.

Les clients VPN laissent parfois leur résolveur interne, une IP privée devenue injoignable, accroché à l'interface après une déconnexion brutale. Même logique côté sécurité : les modules de protection web de plusieurs suites antivirus interceptent le trafic DNS et le cassent après une mise à jour ratée. Désactivez le module dix minutes, retestez, tirez la conclusion.

Le cas qui trompe le plus de monde vient d'IPv6. La box annonce un résolveur IPv6 via RDNSS dans ses annonces de routeur (RFC 8106) et Windows le préfère à l'IPv4. Si ce résolveur ne répond pas, chaque requête part d'abord dans le vide avant de retomber sur l'IPv4. Un dig -6 @2606:4700:4700::1111 adresse-ip.fr qui échoue alors que la variante IPv4 fonctionne isole le problème tout de suite.

Firefox et Chrome peuvent résoudre en DNS over HTTPS sur le port 443 (RFC 8484), en court-circuitant la configuration système. D'où des situations où le navigateur affiche les pages pendant que nslookup échoue, ou l'inverse exactement. La page about:networking#dns de Firefox indique si le mode TRR est actif.

Si le serveur muet est le vôtre, regardez systemctl status named ou unbound, puis les directives listen-on et allow-query : un BIND en allow-query { localhost; } ignore ou refuse les requêtes venues du réseau. Les serveurs autoritatifs appliquent aussi du Response Rate Limiting, qui laisse volontairement tomber des réponses quand une même source interroge trop vite.

Silence, SERVFAIL, NXDOMAIN : trois pannes différentes

« Ne répond pas » veut dire zéro paquet reçu. Un serveur qui renvoie SERVFAIL ou NXDOMAIN a répondu, et le diagnostic n'a plus rien à voir. Le champ status: de la sortie dig tranche en une ligne.

dig +cd désactive la validation DNSSEC côté résolveur. Si la requête passe avec +cd et échoue sans, la signature de la zone est en cause et votre réseau est hors de cause. Ce scénario se produit à chaque rotation de clé mal exécutée chez un hébergeur, et il touche tous les visiteurs dont le résolveur valide.

Un NXDOMAIN se met en cache lui aussi. Sa durée est bornée par le champ MINIMUM de l'enregistrement SOA de la zone, que la RFC 2308 recommande de plafonner à trois heures. Un domaine que vous venez de créer peut donc rester introuvable un moment sur un résolveur qui a déjà répondu non.

Dernier piège, la taille. Sans EDNS0 (RFC 6891), une réponse DNS en UDP est limitée à 512 octets ; au-delà, le serveur positionne le bit TC et le client doit rejouer la requête en TCP sur le même port 53. Un pare-feu qui autorise UDP/53 mais bloque TCP/53 génère des pannes intermittentes sur les zones signées DNSSEC, dont les réponses dépassent souvent cette limite.

Code	Nom (RFC 1035)	Signification	Réflexe
0	NOERROR	Réponse valide, parfois sans enregistrement	Lire la section ANSWER, elle peut être vide
2	SERVFAIL	Le résolveur n'a pas pu produire de réponse	Tester dig +cd, vérifier les serveurs autoritatifs
3	NXDOMAIN	Le nom n'existe pas	Orthographe, domaine expiré, enregistrement supprimé
5	REFUSED	Le serveur refuse de traiter la requête	ACL allow-query, résolveur fermé à votre IP
aucun	timeout	Rien n'est revenu	Port 53 filtré, serveur éteint, route cassée

Réparer, dans l’ordre

Commencez par le cache et le service, avant de toucher à la configuration IP. Sous Windows, les quatre commandes ci-dessous couvrent la quasi-totalité des remises en route côté poste.

Sous macOS : sudo dscacheutil -flushcache puis sudo killall -HUP mDNSResponder. Sous Linux avec systemd-resolved : resolvectl flush-caches, et resolvectl status pour voir le serveur réellement utilisé par lien. Le stub écoute sur 127.0.0.53:53, ce qui explique pourquoi /etc/resolv.conf n'y contient qu'une seule ligne sans intérêt diagnostique.

Deux réserves avant de coller 8.8.8.8 partout. Sur un réseau d'entreprise, un poste joint à un domaine Active Directory doit garder le contrôleur de domaine comme résolveur, sinon il perd les enregistrements SRV qui servent à trouver ses services et l'ouverture de session se dégrade. Sur une ligne résidentielle, un résolveur public qui ne transmet pas EDNS Client Subnet peut vous diriger vers un nœud CDN plus lointain que celui que votre FAI vous donnait.

Si le message revient à chaque redémarrage sur une seule machine pendant que les autres fonctionnent, la piste est logicielle et locale : profil réseau corrompu, pilote de carte, filtre LSP installé par un antivirus ou un ancien VPN. netsh winsock show catalog liste ces filtres sous Windows.

ipconfig /flushdns puis ipconfig /registerdns
net stop dnscache && net start dnscache, ou Restart-Service Dnscache en PowerShell administrateur
Set-DnsClientServerAddress -InterfaceAlias "Ethernet" -ServerAddresses 1.1.1.1,9.9.9.9
netsh winsock reset puis netsh int ip reset, avec redémarrage obligatoire, en dernier recours seulement

Résolveur	IPv4	IPv6	Particularité
Cloudflare	1.1.1.1 et 1.0.0.1	2606:4700:4700::1111	DoT (853) et DoH (443), pas de filtrage de contenu
Quad9	9.9.9.9 et 149.112.112.112	2620:fe::fe	Blocage des domaines malveillants connus
Google	8.8.8.8 et 8.8.4.4	2001:4860:4860::8888	Transmet EDNS Client Subnet aux CDN
FDN	80.67.169.12 et 80.67.169.40	2001:910:800::12	Associatif, hébergé en France

Questions fréquentes

Faut-il changer de serveur DNS pour régler le problème ?

C'est le correctif le plus rapide quand la box est en cause, mais faites-le en connaissance. Testez d'abord avec dig @1.1.1.1 : si le résolveur public répond et pas celui de la box, remplacez les serveurs distribués par DHCP dans l'interface de la box plutôt que carte par carte, sinon vous devrez recommencer sur chaque appareil. Sur un poste joint à un Active Directory, gardez le contrôleur de domaine comme résolveur.

Pourquoi mon téléphone en 4G ouvre le site alors que mon PC affiche l’erreur ?

Parce que le téléphone utilise le résolveur de l'opérateur mobile, pas celui de votre box. Cette différence confirme que le site est en ligne et que la panne est locale à votre réseau ou à votre poste. Refaites le test en connectant le téléphone au Wi-Fi : s'il échoue à son tour, le problème est la box ; s'il fonctionne, il est sur le PC.

ipconfig /flushdns suffit-il vraiment ?

Il ne règle qu'un cas : celui d'une entrée périmée en cache local, typiquement après un changement d'hébergeur. Il ne fait rien si le résolveur configuré est injoignable, puisqu'il ne modifie aucune configuration. Vérifiez ce que contenait le cache avant de le vider avec ipconfig /displaydns, l'information disparaît ensuite.

Mon fournisseur d’accès peut-il bloquer le port 53 ?

Certains réseaux, surtout en hôtel, en entreprise ou sur des points d'accès publics, interceptent ou filtrent le port 53 pour forcer l'usage de leur propre résolveur. Le symptôme est net : dig @1.1.1.1 échoue en UDP alors que la connectivité IP fonctionne. Contournez en DNS over TLS sur le port 853 ou DNS over HTTPS sur le 443, sauf si l'accès à ces ports est également contrôlé.

Comment savoir si la panne vient de moi ou du domaine visité ?

Interrogez deux résolveurs indépendants du vôtre, par exemple dig @9.9.9.9 exemple.fr et dig @8.8.8.8 exemple.fr. Si les deux renvoient SERVFAIL ou NXDOMAIN, le problème est chez le domaine (zone cassée, DNSSEC, expiration). Si les deux répondent normalement, votre configuration locale est en cause.

Testez vos connaissances

Quiz rapide Question 1 sur 3

Que signifie précisément « le serveur DNS ne répond pas » ?