Aller au contenu principal

Guides / Corriger : guides pour les erreurs que l'on rencontre vraiment

Comment corriger DNS server not responding

« DNS server not responding » signifie que votre appareil a envoyé une résolution de nom et n'a rien reçu en retour avant l'expiration du délai de la requête. Le diagnostic réseau de Windows l'affiche après l'échec d'un test de connexion. Le nom peut être parfaitement valide ; c'est le résolveur qui devait le traduire qui n'a jamais répondu.

Ce que signifie l'erreur

Chaque connexion commence par une résolution de nom. Votre appareil envoie le nom d'hôte à un résolveur, en général votre routeur, votre FAI, ou un service public comme 1.1.1.1, et attend une adresse IP. Si aucune réponse n'arrive avant le délai imparti, le système d'exploitation retente, essaie le serveur secondaire, puis finit par abandonner. Windows lance alors son dépanneur, qui indique que le serveur DNS ne répond pas.

La formulation pointe vers le serveur, mais c'est en réalité une affirmation sur un chemin. N'importe lequel de ces cas produit le même message : le résolveur est hors service, le résolveur fonctionne mais est injoignable depuis votre réseau, un pare-feu bloque le port 53, l'adresse configurée sur votre carte réseau est erronée, ou le routeur au milieu a cessé de relayer. Le silence a exactement la même apparence dans les cinq cas.

Distinguez-la de ses voisines avant de commencer. Un résolveur qui répond « ce nom n'existe pas » vous donne NXDOMAIN, traité dans DNS_PROBE_FINISHED_NXDOMAIN. Un résolveur qui répond lentement mais correctement est encore un autre problème, qui a sa propre section plus bas. Cette erreur-ci est le cas où rien ne revient du tout.

Pourquoi cela arrive

  • Le routeur a cessé de relayer. Les routeurs grand public font tourner un petit relais DNS qui se bloque plus souvent que le reste de l'appareil, de sorte que le réseau paraît en ligne et seules les résolutions de noms échouent.
  • Le serveur DNS configuré est erroné. Une adresse statique héritée d'un ancien réseau, ou un serveur qui a été mis hors service.
  • Le résolveur du FAI subit une panne ou est surchargé et abandonne les requêtes au lieu d'y répondre.
  • Un pare-feu ou une suite de sécurité bloque le port 53. Certains produits interceptent le DNS eux-mêmes et échouent en mode fermé quand leur propre service ne tourne pas.
  • Un VPN est à moitié connecté. Le tunnel a poussé ses résolveurs internes sur votre carte réseau, puis s'est coupé, laissant des adresses qui ne sont joignables qu'à l'intérieur du tunnel.
  • L'IPv6 est configuré mais inutilisable. Le système préfère un résolveur IPv6, n'a aucune route vers lui, et attend l'expiration du délai avant de se rabattre sur l'IPv4.
  • Le service Client DNS de Windows est arrêté ou son cache est corrompu.
  • Un logiciel malveillant ou une application indésirable a changé le résolveur vers une adresse qu'il contrôle, qui ensuite disparaît.
  • Le réseau exige une connexion via portail captif qui n'a pas encore eu lieu, si bien que tout le DNS sortant est avalé.

Comment le corriger

Déterminez d'abord si le réseau lui-même fonctionne avant de toucher aux réglages DNS. ping 1.1.1.1 n'utilise aucune résolution de nom. Si cela échoue aussi, vous avez un problème de connectivité, pas un problème DNS. Si cela réussit alors que ping example.com échoue, le DNS est confirmé comme l'élément cassé et les étapes ci-dessous s'appliquent.

Windows

  1. Videz le cache et redémarrez le service client :
    ipconfig /flushdns
    net stop dnscache
    net start dnscache
  2. Voyez ce que votre carte réseau utilise : ipconfig /all | findstr /C:"DNS Servers"
  3. Définissez un résolveur public à la place : netsh interface ipv4 set dnsservers name="Wi-Fi" static 1.1.1.1 primary
  4. Testez ce serveur précis directement : nslookup example.com 1.1.1.1
  5. Réinitialisez la pile si rien ne tient, puis redémarrez :
    netsh int ip reset
    netsh winsock reset
  6. Décochez IPv6 sur la carte réseau si la machine n'a pas d'IPv6 fonctionnel, puis retestez.

macOS

  1. Videz le cache : sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder
  2. Lisez les résolveurs utilisés : scutil --dns | grep nameserver
  3. Remplacez-les : sudo networksetup -setdnsservers Wi-Fi 1.1.1.1 1.0.0.1
  4. Revenez à ce que le DHCP distribue : sudo networksetup -setdnsservers Wi-Fi empty

Linux

  1. Vérifiez l'état et videz le cache : resolvectl status, puis sudo resolvectl flush-caches
  2. Interrogez un serveur explicitement pour voir s'il répond du tout : dig @1.1.1.1 example.com +short
  3. Changez le résolveur sur la connexion plutôt que d'éditer /etc/resolv.conf, qui est généralement généré :
    nmcli con mod "Wired connection 1" ipv4.dns "1.1.1.1 1.0.0.1"
    nmcli con mod "Wired connection 1" ipv4.ignore-auto-dns yes
    nmcli con up "Wired connection 1"
  4. Redémarrez le résolveur stub s'il est bloqué : sudo systemctl restart systemd-resolved

Routeur

  1. Redémarrez-le électriquement et attendez que la liaison WAN revienne avant de tester.
  2. Dans la page d'administration, définissez les serveurs DNS WAN sur une paire publique au lieu de « obtenir automatiquement » si le résolveur du FAI est suspecté.
  3. Mettez à jour le micrologiciel. Les bugs de relais DNS sont une cause fréquente pour laquelle un routeur doit être redémarré toutes les quelques semaines.
  4. Contournez-le à titre de test : connectez un téléphone aux données mobiles et résolvez le même nom. Un succès là-bas réduit la panne à votre propre réseau.

Navigateur

  1. Chrome, Edge et Firefox peuvent envoyer le DNS via HTTPS vers un fournisseur qui leur est propre, indépendamment de vos réglages système. Si le navigateur échoue alors que dig réussit, désactivez le DNS sécurisé dans les réglages de confidentialité du navigateur et retestez.
  2. Videz le cache interne de Chrome sur chrome://net-internals/#dns.

Quand la résolution est lente plutôt que cassée

Toute plainte concernant le DNS n'est pas un échec. Si les pages finissent par se charger mais restent bloquées une seconde ou deux avant que quoi que ce soit ne se passe, le résolveur répond, juste en retard, et les corrections ci-dessus ne changeront pas grand-chose. Mesurez avant de deviner :

dig example.com | grep "Query time"
dig @1.1.1.1 example.com | grep "Query time"

Tout ce qui se situe à un ou deux chiffres de millisecondes depuis un cache chaud est normal. Plusieurs centaines de millisecondes, ou un chiffre qui varie fortement d'une exécution à l'autre, signifie que le résolveur est loin, surchargé, ou qu'il dépasse le délai sur son premier serveur avant de se rabattre sur un second. C'est un diagnostic différent avec des corrections différentes, exposé dans comment corriger une résolution DNS lente.

Vérifiez-le depuis l'extérieur

Tout ce qui précède suppose que la panne est près de vous, ce qui est généralement le cas. Confirmez-le avant d'y passer un après-midi. Demandez à un résolveur qui n'a rien à voir avec votre réseau si le nom se résout :

dig @8.8.8.8 example.com +short
dig @9.9.9.9 example.com +short
nslookup example.com 1.1.1.1

Une réponse de ceux-là pendant que votre propre résolveur reste silencieux prouve que le domaine va bien et que le problème vient de votre côté. Le silence de tous prouve qu'il faut se tourner vers les serveurs de noms du domaine lui-même, qui peuvent être hors service ou injoignables depuis une partie d'Internet.

La joignabilité d'un serveur de noms n'est pas globale. Lancez la vérification de requête DNS pour envoyer la même résolution depuis des points de contrôle dans différents pays et comparer les réponses côte à côte. Quand certains emplacements obtiennent un résultat et d'autres expirent, vous êtes face à un problème de routage ou de fournisseur affectant une région, pas à un enregistrement cassé, et aucune purge de cache sur votre ordinateur portable ne vous le montrera.

Quand votre propre serveur de noms devient silencieux

Un serveur de noms qui devient silencieux met un site hors ligne aussi complètement qu'un serveur web mort, et il le fait sans produire une seule ligne dans votre journal d'accès. Personne ne vous contacte pour vous le dire, car personne ne peut vous joindre du tout. HostTracker exécute des vérifications programmées depuis plus de 300 points de contrôle répartis dans 158 villes, sur 13 types de moniteurs, de sorte qu'un nom qui cesse de se résoudre dans une région est détecté par les points de contrôle qui s'y trouvent plutôt que par un e-mail de client. Le reste de cette section se trouve dans le cluster résoudre, et si la question est de savoir si un changement DNS récent a atteint tout le monde, c'est comment vérifier la propagation DNS.

Vérifier maintenant

Lancez la vérification gratuite sur votre propre site, sans créer de compte.

Dns query

Surveiller en permanence

Soyez alerté dès que quelque chose casse : HostTracker vérifie depuis plus de 300 emplacements et vous prévient par e-mail, SMS, Slack, Telegram et plus encore.

Fonctionnalités HostTracker

Plus dans cette section: Corriger : guides pour les erreurs que l'on rencontre vraiment