ERR_NAME_NOT_RESOLVED / NXDOMAIN : le domaine ne résout pas

Le problème : le domaine ne se résout plus en IP

Ce matin, un site tournait parfaitement hier soir. Ce matin, plus rien : le navigateur affiche ERR_NAME_NOT_RESOLVED sur Chrome, ou DNS_PROBE_FINISHED_NXDOMAIN, ou encore un message du type « ce serveur est introuvable ». Sur un terminal, une requête nslookup renvoie NXDOMAIN, littéralement « ce nom de domaine n’existe pas » aux yeux du système de résolution DNS.

Cette erreur n’a rien à voir avec le serveur qui héberge le site. Le problème se situe une étape avant : le nom de domaine (par exemple monsite.fr) n’arrive pas à être traduit en adresse IP. C’est comme composer un numéro qui n’est associé à aucun abonné : l’appel ne part même pas. Le serveur peut être parfaitement sain, si le DNS ne pointe pas correctement, personne ne l’atteint jamais.

Bonne nouvelle : dans l’immense majorité des cas, ce n’est ni une catastrophe ni une perte de données. C’est une histoire de configuration ou de propagation, et ça se diagnostique en quelques commandes. Ce guide donne la méthode complète, du plus simple (vider un cache local) au plus technique (corriger une zone DNS mal configurée).

Pourquoi ça arrive

Plusieurs causes, souvent cumulées, expliquent une résolution DNS en échec :

• Le domaine a expiré ou est en statut « redemption » chez le registrar, et n’est plus routé du tout.
• Les serveurs de noms (nameservers) pointent encore vers l’ancien hébergeur après une migration, ou ont été mal renseignés chez le registrar.
• La zone DNS ne contient pas (ou plus) l’enregistrement A ou AAAA attendu pour le domaine ou le sous-domaine.
• Une faute de frappe dans un enregistrement (IP erronée, CNAME vers une cible qui n’existe plus).
• Le changement DNS est trop récent : la propagation mondiale peut prendre de quelques minutes à 48 heures selon le TTL (durée de vie en cache) des anciens enregistrements.
• Le cache DNS local (sur l’ordinateur, le routeur, ou chez le fournisseur d’accès) garde une réponse périmée ou une absence de réponse.
• Un enregistrement NS mal formé dans la zone chez le fournisseur DNS, qui casse la délégation.

Le point commun : c’est presque toujours corrigeable sans toucher au serveur ni au code du site. Si le problème persiste après migration d’hébergeur, la checklist de site inaccessible après un changement d’hébergeur couvre des causes voisines.

1. Confirmer que c’est bien un problème DNS, pas autre chose

Avant de chercher du côté DNS, élimine deux pistes courantes qui donnent des symptômes similaires :

• Teste sur un autre réseau (4G du téléphone, ou un service en ligne de vérification DNS). Si le site répond ailleurs mais pas chez toi, le problème vient probablement de ton propre cache ou de ta box.
• Vérifie que ce n’est pas plutôt un serveur injoignable une fois le DNS résolu : dans ce cas, l’erreur ressemblerait plutôt à ERR_CONNECTION_TIMED_OUT ou ERR_CONNECTION_REFUSED. ERR_NAME_NOT_RESOLVED et NXDOMAIN interviennent avant toute tentative de connexion au serveur : le nom n’a même pas d’adresse.

Si le doute persiste, l’arbre de décision de site inaccessible : le diagnostic complet aide à trancher rapidement entre panne DNS, panne serveur, ou panne réseau local.

2. Vider le cache DNS local

Le cache DNS local garde en mémoire les dernières résolutions, y compris les échecs. Un changement récent peut donc rester invisible tant que ce cache n’est pas purgé.

Sur Windows (invite de commande) :

ipconfig /flushdns

Sur macOS (Terminal) :

sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

Sur Linux (selon le service utilisé) :

sudo systemd-resolve --flush-caches

Dans le navigateur Chrome, tape chrome://net-internals/#dns et clique sur « Clear host cache ». Redémarre aussi le navigateur.

Sur la box internet : un simple redémarrage de la box vide généralement son cache DNS interne. Utile si plusieurs appareils du même réseau sont touchés.

Si le site répond après ces manipulations, le problème était uniquement un cache périmé côté client, rien à corriger sur le domaine lui-même.

3. Diagnostiquer avec nslookup et dig

Ces deux outils interrogent directement les serveurs DNS et montrent ce qui est réellement publié, sans passer par le cache local.

Avec nslookup (disponible sur Windows, macOS, Linux) :

nslookup monsite.fr
nslookup monsite.fr 8.8.8.8

La seconde commande force l’interrogation du DNS public de Google, ce qui permet de comparer avec la réponse du DNS habituel du réseau.

Avec dig (macOS, Linux, ou via WSL sous Windows) :

dig monsite.fr A
dig monsite.fr NS
dig monsite.fr +trace

• dig monsite.fr A affiche l’adresse IP publiée. Une réponse vide ou une section ANSWER absente confirme l’absence d’enregistrement.
• dig monsite.fr NS liste les serveurs de noms qui font autorité sur le domaine. Compare cette liste à celle réellement configurée chez ton hébergeur ou ton fournisseur DNS (Cloudflare, OVH, etc.).
• dig +trace suit toute la chaîne de résolution, des serveurs racine jusqu’à la réponse finale, utile pour repérer où la chaîne casse.

Si NXDOMAIN apparaît dans la réponse, le domaine n’a strictement aucun enregistrement visible à cet endroit de la chaîne : soit il n’est pas délégué, soit la zone est vide, soit le domaine a expiré.

4. Vérifier les nameservers chez le registrar

Le registrar (là où le domaine a été acheté) doit pointer vers les bons serveurs de noms, ceux de l’hébergeur du site, ou ceux d’un fournisseur DNS comme Cloudflare.

Un cas fréquent : après une migration, seuls les enregistrements DNS ont été mis à jour chez le nouvel hébergeur, mais les nameservers restent ceux de l’ancien prestataire. Résultat : les modifications récentes n’ont aucun effet, car elles ne sont pas consultées.

Va dans l’espace client du registrar, section « DNS » ou « Serveurs de noms », et confirme qu’ils correspondent bien à l’infrastructure actuelle. Si le domaine a été laissé entre les mains d’un ancien prestataire injoignable, la marche à suivre est détaillée dans récupérer le contrôle de son nom de domaine et dans prestataire web disparu : récupérer son site.

5. Corriger les enregistrements dans la zone DNS

Une fois les nameservers confirmés, l’étape suivante consiste à vérifier la zone DNS elle-même :

• L’enregistrement A (ou AAAA pour IPv6) du domaine racine (@) pointe vers l’IP correcte du serveur.
• L’enregistrement A du sous-domaine www existe (souvent via un CNAME vers le domaine racine).
• Aucun enregistrement en doublon ou contradictoire (deux A différents pour le même nom, par exemple).
• Le TTL n’est pas anormalement élevé (86400 secondes = 24h par défaut ; le baisser temporairement à 300 secondes avant une migration facilite les changements rapides ensuite).

Les guides pas-à-pas pour chaque fournisseur détaillent l’interface exacte : configurer ses DNS sur Cloudflare, sur OVH via o2switch, sur IONOS, ou sur Hostinger. Le principe reste identique partout : un enregistrement manquant ou erroné empêche toute résolution.

6. Patienter (ou forcer) la propagation

Même avec une configuration correcte, un changement DNS met du temps à se diffuser mondialement : chaque résolveur (FAI, box, DNS public) garde en cache l’ancienne réponse jusqu’à expiration du TTL précédent. Ce délai peut aller de quelques minutes à 48 heures dans les cas extrêmes.

Pour vérifier objectivement où en est la propagation, dig interrogé sur plusieurs résolveurs publics (8.8.8.8, 1.1.1.1) donne une bonne indication. Si la réponse est correcte sur ces résolveurs mais pas en local, le cache personnel (étape 2) est probablement en cause, pas la configuration.

Pour une analyse plus large des blocages DNS (mauvais pointage, sous-domaines oubliés, conflits multilingues), voir DNS qui ne propage pas : diagnostic et résolution.

Tableau récapitulatif : cause → solution

FAQ

Quand passer la main à un pro

Si dig +trace montre une chaîne de résolution cassée sur plusieurs niveaux, si le domaine dépend d’un ancien prestataire injoignable, ou si le site est multilingue avec des sous-domaines et redirections complexes, mieux vaut faire vérifier la configuration complète plutôt que de tâtonner enregistrement par enregistrement. Une maintenance par abonnement inclut justement ce type de surveillance DNS avant que le problème ne devienne visible pour les visiteurs.