DNS_PROBE_FINISHED_NXDOMAIN : le domaine ne répond plus

Ce que signifie l'erreur

Avant d'ouvrir un site, le navigateur demande au DNS l'adresse derrière le nom. NXDOMAIN est la réponse « ce nom n'existe pas ». Chrome l'affiche sous la forme DNS_PROBE_FINISHED_NXDOMAIN (« Ce site est inaccessible »), Firefox « Hum, nous ne parvenons pas à trouver ce site », Safari « Safari ne parvient pas à trouver le serveur ». Aucune connexion n'a été tentée : le navigateur n'a jamais reçu d'adresse.

Bonne nouvelle sur un point : le serveur web n'est pas en cause. Le problème est dans le DNS, chez le visiteur (faute de frappe, vieux cache, mauvais résolveur) ou chez le propriétaire (le domaine ou ses enregistrements ont disparu).

Causes fréquentes

Chez le visiteur

1. Une faute de frappe, ou un lien vers un domaine qui n'existe plus.
2. Un cache DNS (ordinateur, navigateur, routeur) qui garde une vieille réponse « n'existe pas ».
3. Un VPN ou un réseau d'entreprise qui bloque le domaine, un filtre parental, un antivirus.

Chez le propriétaire

4. Le domaine a expiré. Le registrar retire les serveurs de noms, et le nom cesse d'exister. La cause la plus fréquente pour un site qui marchait hier.
5. L'enregistrement A ou AAAA manque. Après un déménagement, l'enregistrement pour www ou pour le domaine nu n'a jamais été créé chez le nouveau prestataire.
6. Serveurs de noms changés, zone vide. Vous avez pointé le domaine vers un nouveau prestataire sans y copier les enregistrements avant.
7. DNSSEC cassé. Un enregistrement DS erroné chez le registrar fait échouer les résolveurs qui valident ; le navigateur affiche NXDOMAIN ou une erreur voisine.
8. La propagation. Après un changement de serveurs de noms, certains résolveurs voient encore l'ancienne zone, désormais vide, jusqu'à l'expiration du TTL.

Si vous êtes visiteur

1. Vérifiez l'orthographe de l'adresse et essayez avec et sans www.
2. Videz le cache DNS : sur macOS sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder, sur Linux sudo resolvectl flush-caches.
3. Ouvrez le site sur votre smartphone sans wifi. Si cela fonctionne là, le résolveur de votre réseau est en cause.
4. Configurez un résolveur public dans les réglages réseau (1.1.1.1 ou 9.9.9.9).
5. Si rien n'y fait, le domaine est vraiment cassé, et seul le propriétaire peut corriger.

Si c'est votre site : vérifier d'abord

Lancez le Site down checker : il vous dit si le domaine se résout depuis un point neutre. Si non, lisez la suite. Si oui, le problème est chez le visiteur : envoyez-lui la liste ci-dessus.

Puis, en ligne de commande :

# le nom se résout-il, et qui répond ?
dig +short example.com A
dig +short www.example.com A
dig example.com NS +short

# interroger le serveur de noms autoritaire (contourne tout cache)
dig @ns1.votre-prestataire-dns.fr example.com A

# état de l'enregistrement et date d'expiration
whois example.com | grep -iE 'expir|status'

# DNSSEC : une chaîne cassée donne SERVFAIL
dig @1.1.1.1 example.com A +dnssec | grep -E 'status|flags'

Une réponse vide de dig avec status: NXDOMAIN dans la sortie complète signifie que l'enregistrement n'existe pas sur le serveur autoritaire. Si whois affiche clientHold, redemptionPeriod ou pendingDelete, c'est l'enregistrement du domaine qui pose problème, pas la zone.

Solutions pour le propriétaire

1. Domaine expiré

Connectez-vous chez votre registrar et renouvelez. Pendant le délai de grâce, le domaine revient peu après le paiement ; dans la phase de rédemption qui suit, cela coûte des frais de restauration et prend plus de temps. Activez le renouvellement automatique et gardez le moyen de paiement à jour : un domaine expiré coupe d'un coup le site, le courrier et les sous-domaines.

2. Enregistrement manquant

Créez l'enregistrement manquant chez votre prestataire DNS. Pour un site web, c'est en général :

example.com.      A      203.0.113.10
www.example.com.  CNAME  example.com.

Utilisez l'IP de votre serveur web (hostname -I, ou l'adresse donnée par votre hébergeur). Si le serveur a une adresse IPv6, ajoutez un AAAA ; sinon, supprimez un AAAA erroné. Les modifications prennent effet dans le délai du TTL.

3. Zone vide après un changement de serveurs de noms

Avant de changer de serveurs de noms, exportez la zone chez l'ancien prestataire et importez-la chez le nouveau. Si c'est déjà fait, recréez les enregistrements : A pour le domaine nu et www, MX et TXT pour le courrier, plus vos sous-domaines.

4. DNSSEC

Si dig +dnssec renvoie SERVFAIL alors que la requête simple au serveur autoritaire passe, l'enregistrement DS chez le registrar ne correspond pas aux clés du prestataire DNS. Supprimez le DS chez le registrar, ou copiez-y le nouveau DS fourni par le prestataire.

5. Sur votre propre serveur

Rien sur le serveur web ne provoque NXDOMAIN ; il n'y a rien à redémarrer. Vérifiez quand même que le serveur résout lui-même les noms (dig +short example.com @127.0.0.53), sinon mises à jour et courrier échouent aussi.

Si le problème vient de votre hébergeur

Si votre hébergeur gère aussi votre DNS (courant en hébergement mutualisé) et que les enregistrements semblent corrects dans l'espace client mais ne se résolvent pas de l'extérieur, envoyez-lui :

Bonjour, mon domaine example.com ne se résout plus depuis environ 11 h 00 (UTC) (NXDOMAIN). Les enregistrements dans l'espace client semblent corrects et le domaine est renouvelé. Pourriez-vous vérifier la zone DNS sur vos serveurs de noms et que le domaine leur est toujours délégué ?

Pour que cela ne se reproduise pas

Un NXDOMAIN sur votre propre domaine, c'est presque toujours le renouvellement oublié ou l'enregistrement non copié. Un moniteur DNS compare vos enregistrements aux valeurs attendues et vous alerte dès que l'un change ; une vérification depuis l'extérieur attrape l'instant où le nom cesse de se résoudre. Les deux font partie du monitoring de site web, gratuit pour commencer. Si les enregistrements sont sur votre propre serveur, l'intervention approfondie les rétablit, 24 h/24. Le domaine se résout, mais le serveur refuse la connexion ? C'est un autre cas : ERR_CONNECTION_REFUSED.