Aller au contenu principal

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

DNS_PROBE_FINISHED_NXDOMAIN : signification et correction

DNS_PROBE_FINISHED_NXDOMAIN signifie que la résolution du nom d'hôte que vous avez saisi est revenue avec « ce nom n'existe pas ». Le navigateur n'a jamais reçu d'adresse IP, il n'a donc jamais ouvert de connexion. Le problème se situe dans la résolution de noms, pas sur le serveur web du site.

Ce que signifie l'erreur

NXDOMAIN est un code de réponse DNS, abréviation de « non-existent domain ». Un résolveur le renvoie après avoir parcouru la chaîne depuis la racine jusqu'à la zone censée contenir votre nom d'hôte, et n'y avoir rien trouvé. Chrome affiche DNS_PROBE_FINISHED_NXDOMAIN. Firefox dit qu'il ne peut pas se connecter au serveur. Safari dit qu'il ne trouve pas le serveur. Les trois rapportent la même réponse.

NXDOMAIN n'est pas la même chose qu'un échec de résolveur, et la différence détermine où chercher. Si votre résolveur est injoignable ou expire, vous obtenez à la place un message « DNS server not responding ». Si la zone répond mais est cassée, par exemple une chaîne DNSSEC qui ne se valide pas, vous obtenez généralement SERVFAIL. NXDOMAIN est une réponse définitive : le nom n'est pas publié.

Une propriété de NXDOMAIN compte plus que toute autre lors du dépannage. Les réponses négatives sont mises en cache. Selon la RFC 2308, un résolveur met en cache le résultat « ce nom n'existe pas » pendant l'intervalle indiqué dans l'enregistrement SOA de la zone, généralement entre 5 et 60 minutes. Un domaine qui a commencé à fonctionner il y a deux minutes peut toujours échouer sur votre machine, et aucun rechargement n'y changera rien tant que l'entrée en cache n'aura pas expiré ou que vous ne l'aurez pas vidée.

Pourquoi cela arrive

  • Une faute de frappe dans le nom d'hôte. La cause la plus fréquente, de loin, et celle que tout le monde vérifie en dernier.
  • Le domaine n'est pas enregistré, ou a expiré. Un domaine expiré est en général retiré de la zone quelques heures après la fin du délai de grâce.
  • Aucune délégation de serveur de noms. Le domaine existe chez le bureau d'enregistrement mais n'a aucun enregistrement NS pointant vers un fournisseur DNS, donc la zone parente n'a rien vers quoi renvoyer un résolveur.
  • L'enregistrement a été supprimé ou renommé. Un A ou un CNAME manquant pour www produit un NXDOMAIN pour www.example.com alors que le domaine nu fonctionne toujours.
  • Un changement n'a pas encore atteint votre résolveur. Les nouveaux enregistrements peuvent mettre jusqu'au TTL de l'ancien enregistrement avant d'apparaître partout.
  • Une réponse négative mise en cache sur votre appareil, dans votre navigateur, ou sur le résolveur de votre fournisseur d'accès.
  • Une entrée dans le fichier hosts qui pointe le nom vers un emplacement qui n'existe plus, ou une ligne oubliée d'un ancien test.
  • Un VPN, un proxy ou un logiciel de filtrage qui répond lui-même aux requêtes DNS et bloque ou échoue à résoudre le nom.
  • Un nom d'hôte qui n'existe que sur un réseau privé auquel vous n'êtes pas actuellement connecté, comme un domaine interne .local ou d'entreprise.

Comment corriger le problème

Ressaisissez d'abord l'adresse, puis progressez de votre navigateur vers votre réseau. Testez après chaque étape plutôt que de toutes les faire d'un coup.

Navigateur

  1. Ouvrez la même URL dans une fenêtre privée. Si elle se charge là, c'est une extension ou un cookie qui est en cause, pas le DNS.
  2. Videz le cache de résolveur propre à Chrome sur chrome://net-internals/#dns, puis videz les pools de sockets sur chrome://net-internals/#sockets. Chrome garde un cache séparé de celui du système d'exploitation, donc un vidage côté OS seul ne change souvent rien.

Windows

  1. Videz le cache du résolveur : ipconfig /flushdns
  2. Renouvelez le bail réseau, ce qui reprend aussi les serveurs DNS distribués par le DHCP :
    ipconfig /release
    ipconfig /renew
  3. Redémarrez le service de cache si un vidage ne tient pas :
    net stop dnscache
    net start dnscache
  4. Vérifiez C:\Windows\System32\drivers\etc\hosts pour une ligne nommant le domaine et supprimez-la si elle est obsolète.
  5. Définissez un résolveur public : netsh interface ipv4 set dnsservers name="Wi-Fi" static 1.1.1.1 primary
  6. En dernier recours, réinitialisez la pile réseau, puis redémarrez : netsh winsock reset

macOS

  1. Videz le cache : sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder
  2. Voyez quels serveurs sont utilisés : scutil --dns | grep nameserver
  3. Pointez l'interface vers un résolveur public : sudo networksetup -setdnsservers Wi-Fi 1.1.1.1 1.0.0.1
  4. Inspectez /etc/hosts et supprimez toute ligne concernant le domaine.

Linux

  1. Sous systemd-resolved : sudo resolvectl flush-caches, puis confirmez les serveurs utilisés avec resolvectl status.
  2. Sous dnsmasq : sudo systemctl restart dnsmasq. Sous nscd : sudo systemctl restart nscd.
  3. Lisez /etc/resolv.conf pour voir quel résolveur vous interrogez, et /etc/hosts pour une surcharge obsolète.
  4. Avec NetworkManager, changez le résolveur directement sur la connexion :
    nmcli con mod "Wired connection 1" ipv4.dns "1.1.1.1 1.0.0.1"
    nmcli con up "Wired connection 1"

Routeur

  1. Redémarrez le routeur. La plupart des routeurs grand public font tourner un petit résolveur relais avec son propre cache, et un redémarrage le vide.
  2. Dans la page d'administration du routeur, regardez les serveurs DNS du WAN ou du DHCP. S'ils pointent vers un ancien serveur interne ou un service de filtrage, remplacez-les.
  3. Testez avec un téléphone sur les données mobiles plutôt qu'en Wi-Fi. Si le nom se résout là, le problème est à l'intérieur de votre réseau.

Si vous êtes propriétaire du domaine

Un NXDOMAIN sur votre propre site est un problème de publication, et il n'y a que quelques endroits d'où il peut venir. Vérifiez d'abord l'état de l'enregistrement et sa date d'expiration. Puis confirmez la délégation, l'étape que tout le monde saute :

dig NS example.com +short
dig example.com +trace

Une réponse NS vide signifie que la zone parente n'a aucune délégation, donc aucun résolveur ne peut atteindre votre fournisseur DNS, quels que soient les enregistrements que vous y avez créés. La sortie de +trace montre la chaîne de renvois et l'étape exacte où elle s'arrête. Si la délégation est correcte, interrogez directement le serveur de noms de votre fournisseur pour confirmer que l'enregistrement existe dans la zone que vous modifiez :

dig @ns1.example-dns.net www.example.com A

Quand vous ajoutez un enregistrement manquant, l'ancienne réponse négative reste en cache ailleurs aussi longtemps que le minimum du SOA le permet, laissez donc ce délai s'écouler avant de conclure que la correction n'a pas fonctionné.

Vérifier depuis l'extérieur

Chaque correction ci-dessus modifie votre propre machine. Aucune ne vous dit si le nom se résout pour quelqu'un d'autre, et c'est ce que vous voulez savoir en premier. Lancez la requête contre deux résolveurs publics et comparez :

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

nslookup example.com 8.8.8.8

Si votre résolveur par défaut ne renvoie rien et que 1.1.1.1 renvoie une adresse, l'enregistrement existe et votre résolveur retient une réponse négative obsolète ou filtre le nom. Si tous les résolveurs ne renvoient rien, l'enregistrement est réellement absent.

Deux résolveurs ne couvrent encore qu'un seul point de vue, et les réponses DNS diffèrent par région plus souvent qu'on ne le pense. Lancez la vérification de requête DNS pour résoudre le nom depuis des points de contrôle dans plusieurs pays à la fois et lire ce que chacun a renvoyé. Un résultat partagé, certains emplacements répondant et d'autres non, indique un changement encore en propagation ou un serveur de noms d'un fournisseur injoignable depuis une partie d'internet. Cette lecture dans le temps est la propagation DNS, qui a son propre guide sur comment vérifier la propagation DNS.

Détecter un nom qui cesse de se résoudre

Un enregistrement qui disparaît ne laisse aucune trace de votre côté. Rien ne l'enregistre, car aucune requête n'arrive jamais, et le seul signe est un graphique de trafic qui chute. La solution dans tous les cas est une résolution qui s'exécute selon un horaire régulier depuis un autre endroit que votre bureau. HostTracker surveille des sites web depuis 2004 et exécute aujourd'hui des vérifications depuis plus de 300 points de contrôle répartis dans 158 villes, en alertant par e-mail, SMS, appel vocal, Slack, Telegram et bien d'autres canaux quand un nom cesse de se résoudre ou commence à répondre avec la mauvaise adresse. Les autres guides de cette section se trouvent dans le cluster résoudre, et les deux plus proches de celui-ci sont le serveur DNS ne répond pas, pour quand le résolveur ne répond jamais du tout, et comment corriger une résolution DNS lente, pour quand il répond mais met trop de temps à le faire.

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