ERR_NAME_NOT_RESOLVED : ce que ça signifie et comment le corriger

Ce que signifie ERR_NAME_NOT_RESOLVED

Avant qu'un navigateur ne puisse se connecter à quoi que ce soit, il transforme un nom d'hôte en adresse IP via le DNS. ERR_NAME_NOT_RESOLVED est le fourre-tout de Chrome pour cette résolution qui échoue d'une manière autre qu'un nom confirmé comme inexistant : le résolveur n'a pas répondu à temps, a renvoyé une réponse vide ou mal formée, ou la propre pile réseau du navigateur n'a pas pu atteindre de résolveur du tout.

Cela se confond facilement avec DNS_PROBE_FINISHED_NXDOMAIN, qui est un cas plus étroit et plus spécifique. NXDOMAIN signifie qu'un résolveur a répondu clairement : ce nom n'existe pas dans la zone. ERR_NAME_NOT_RESOLVED signifie que la résolution elle-même a échoué ou est revenue sans rien d'utilisable, ce qui inclut un résolveur cassé, un délai dépassé, un réseau sans aucun accès DNS, ou une surcharge DNS locale qui a mal tourné. Si vous savez déjà que le domaine fonctionnait auparavant et que rien concernant le domaine lui-même n'a changé, ERR_NAME_NOT_RESOLVED pointe davantage vers le chemin de résolution que vers les propres enregistrements du domaine.

Comment l'erreur apparaît

Chrome et Edge affichent « This site can't be reached - example.com's server IP address could not be found. Try running Windows Network Diagnostics. » avec le code ERR_NAME_NOT_RESOLVED. Firefox affiche « Hmm. We're having trouble finding that site » avec le message « we can't connect to the server at example.com ».

dig montre ce qu'un résolveur spécifique renvoie, et +trace parcourt la chaîne complète depuis la racine :

dig example.com A
;; ANSWER SECTION:
example.com.  300  IN  A  203.0.113.10

dig +trace example.com
; <<>> DiG 9.18 <<>> +trace example.com
.  518400  IN  NS  a.root-servers.net.
...
com.  172800  IN  NS  a.gtld-servers.net.
...
example.com.  300  IN  A  203.0.113.10

nslookup est une vérification de bon sens plus rapide quand vous avez juste besoin d'une réponse oui ou non :

nslookup example.com
Server:   8.8.8.8
Address:  8.8.8.8#53

Name:     example.com
Address:  203.0.113.10

Si l'une ou l'autre commande dépasse son délai, renvoie SERVFAIL, ou ne renvoie rien sous ANSWER SECTION, la résolution a réellement échoué, distinct d'une réponse NXDOMAIN qui dirait clairement « no such name ».

Ce qui provoque ERR_NAME_NOT_RESOLVED

• Un enregistrement A ou AAAA manquant. Le domaine résout pour d'autres types d'enregistrement, ou la zone existe, mais aucun enregistrement d'adresse n'est publié pour le nom d'hôte demandé (y compris un enregistrement manquant pour un sous-domaine spécifique alors même que le domaine racine fonctionne).
• Un enregistrement de domaine expiré. Une fois qu'un domaine expire, ses serveurs de noms cessent généralement de répondre pour lui entièrement, ce qui produit exactement cet échec plutôt qu'un NXDOMAIN propre.
• Une panne ou une mauvaise configuration de serveur de noms. Si les serveurs de noms faisant autorité du domaine sont injoignables ou renvoient des réponses mal formées, chaque résolveur essayant de répondre pour ce domaine échoue de la même façon.
• Un échec de validation DNSSEC. Un résolveur validant qui ne peut pas vérifier une signature DNSSEC (une signature expirée, une chaîne de confiance cassée) refuse de renvoyer une réponse du tout, plutôt que d'en renvoyer une à laquelle il ne peut pas faire confiance.
• Le propre résolveur du visiteur est en panne ou injoignable, couramment sur un VPN cassé, un portail Wi-Fi captif, ou un routeur mal configuré pointant vers un serveur DNS qui n'existe plus.
• Un cache DNS local corrompu sur la machine du visiteur, contenant une entrée obsolète ou cassée d'avant que le domaine ne soit configuré correctement.

Comment savoir de qui vient la faute

Interrogez un résolveur public directement, comme dig example.com @8.8.8.8, en contournant ce que le réseau local est configuré pour utiliser. Si cela échoue aussi, le problème vient de la propre configuration DNS du domaine, pas du réseau du visiteur. Une recherche DNS lancée depuis plusieurs emplacements rend cela immédiat : un échec constant partout pointe vers les serveurs de noms ou l'enregistrement du domaine, tandis qu'un échec depuis un seul emplacement ou résolveur pointe vers quelque chose de local à ce point d'observation.

Comment corriger ERR_NAME_NOT_RESOLVED

Si vous êtes visiteur

1. Videz le cache DNS local. Sur Windows : ipconfig /flushdns. Sur macOS : sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder. Sur Linux avec systemd-resolved : sudo resolvectl flush-caches.
2. Passez à un résolveur DNS public comme 8.8.8.8 ou 1.1.1.1 dans vos réglages réseau, remplaçant temporairement ce que votre FAI ou routeur fournit par défaut.
3. Vérifiez le fichier hosts (/etc/hosts sur macOS/Linux, C:\Windows\System32\drivers\etc\hosts sur Windows) à la recherche d'une entrée manuelle obsolète qui surcharge le domaine.
4. Déconnectez-vous d'un VPN et réessayez ; certains clients VPN routent le DNS à travers un résolveur lui-même injoignable ou mal configuré.
5. Redémarrez le routeur si chaque site du réseau échoue à se résoudre, pas seulement un.

Si vous gérez le site

1. Confirmez que l'enregistrement A/AAAA existe pour le nom d'hôte exact que les visiteurs utilisent, y compris tout sous-domaine : dig www.example.com A et dig example.com A sont deux résolutions distinctes.
2. Vérifiez le statut d'enregistrement et d'expiration du domaine via votre registraire ; un domaine expiré de façon inattendue est une cause courante et facilement négligée.
3. Vérifiez que les serveurs de noms listés chez le registraire correspondent à ceux servant réellement la zone, et qu'ils répondent : dig NS example.com suivi d'une interrogation directe de chaque serveur de noms renvoyé.
4. Si vous utilisez DNSSEC, validez la chaîne avec dig +dnssec example.com et cherchez un enregistrement RRSIG expiré, une cause fréquente et auto-infligée d'échecs de résolution.
5. Lancez dig +trace pour voir exactement où dans la chaîne de la racine au serveur faisant autorité la résolution s'effondre, plutôt que de deviner.

Erreurs associées

• DNS_PROBE_FINISHED_NXDOMAIN est l'erreur sœur pour une réponse confirmée « ce nom n'existe pas », plutôt qu'une résolution échouée ou vide.
• La propagation DNS explique pourquoi un enregistrement fraîchement modifié peut se résoudre correctement depuis certains résolveurs et pas d'autres pendant un certain temps.

Comment prévenir ERR_NAME_NOT_RESOLVED

Les échecs DNS sont faciles à manquer en interne, puisqu'un réseau de bureau stable et ses enregistrements en cache peuvent continuer à fonctionner bien après que des visiteurs ailleurs commencent à échouer. Une vérification DNS qui s'exécute depuis plus de 300 points de contrôle dans 158 villes détecte une panne de serveur de noms, un enregistrement expirant, ou un enregistrement cassé dès que cela commence à affecter la résolution, plutôt qu'après qu'une boîte de support se soit remplie. HostTracker surveille des sites web depuis 2004 et alerte par e-mail, SMS, appel vocal, Slack, Telegram et bien plus.

Questions fréquentes

Quelle est la différence entre ERR_NAME_NOT_RESOLVED et DNS_PROBE_FINISHED_NXDOMAIN ?

NXDOMAIN est une réponse définitive : le résolveur a vérifié et le nom n'existe pas dans la zone. ERR_NAME_NOT_RESOLVED est plus large et couvre une résolution qui a échoué, a dépassé son délai, ou n'a rien renvoyé d'utilisable, ce qui inclut les cas où le domaine existe bien mais où ses serveurs de noms sont injoignables.

Un domaine expiré peut-il causer cette erreur ?

Oui, et c'est l'une des causes les plus courantes. Une fois qu'un domaine expire, ses serveurs de noms deviennent généralement silencieux, donc chaque résolution pour lui échoue au lieu de renvoyer une réponse propre « n'existe pas ».

Pourquoi le site fonctionne-t-il sur les données mobiles de mon téléphone mais pas sur mon Wi-Fi domestique ?

Cela pointe vers le résolveur que votre réseau domestique utilise, soit le serveur DNS configuré de votre routeur, soit le résolveur de votre FAI. Passer à un résolveur public comme 1.1.1.1 sur le réseau affecté confirme et corrige généralement le problème.

Je viens d'ajouter un nouveau sous-domaine et il ne se résout pas. Pourquoi ?

Un nouvel enregistrement a besoin de se propager à travers les caches DNS après sa création, et il doit aussi réellement exister : confirmez avec dig subdomain.example.com A directement contre le serveur de noms faisant autorité avant de supposer qu'il ne s'agit que d'un délai de propagation.

DNSSEC cause-t-il parfois cette erreur sur un domaine par ailleurs correct ?

Oui. Si les signatures DNSSEC expirent ou si la chaîne de confiance se casse, un résolveur validant refuse de répondre plutôt que de renvoyer des données qu'il ne peut pas vérifier, ce qui ressemble en tout point à un échec de résolution du côté du visiteur.