DNS_PROBE_FINISHED_NXDOMAIN : mon poste ou mon domaine ?

Quand dns probe finished nxdomain apparaît, la première question n’est pas de vider un cache au hasard, mais de trancher vite entre un problème local et un problème de zone DNS. Pour un administrateur, le bon réflexe est simple : interroger un résolveur public depuis une autre machine. Si le domaine ne résout pas ailleurs aussi, l’erreur DNS navigateur n’est qu’un symptôme, pas la cause.

Le point clé tient en une phrase : un seul test fait gagner du temps. Depuis une machine distincte, sur un autre accès réseau si possible, lancez une requête vers 1.1.1.1 ou 8.8.8.8 pour le nom en cause. Si la réponse reste NXDOMAIN, vous êtes côté domaine, délégation ou zone. Si la réponse est correcte, vous êtes côté poste, cache, résolveur local ou réseau d’accès.

Dans l’administration Réseau, ce genre de triage évite de traiter comme panne client ce qui relève en fait du DNS autoritatif.

Le test qui tranche entre le poste et le domaine

Depuis une autre machine, idéalement hors du réseau concerné, interrogez un résolveur public :

• dig @1.1.1.1 exemple.com A
• dig @8.8.8.8 exemple.com A
• nslookup exemple.com 1.1.1.1

Ce que vous cherchez :

• Si la réponse contient status: NXDOMAIN, le nom n’existe pas pour ce résolveur.
• Si vous obtenez un ou plusieurs enregistrements A ou AAAA, la résolution DNS fonctionne et le souci est probablement local.
• Si vous obtenez SERVFAIL, le nom existe peut-être, mais une erreur serveur, DNSSEC ou de délégation empêche la réponse.

Faites ensuite la même requête sur le résolveur du poste affecté. L’écart entre les deux résultats suffit souvent à isoler la panne. Si vous avez besoin de revoir les bases du DNS et de la résolution de noms, faites-le avant de modifier une zone ou le DHCP.

Quand le problème vient vraiment du poste

Ce versant existe, mais il ne mérite pas de monopoliser tout le diagnostic. Si le domaine résout correctement depuis une autre machine via un résolveur public, regardez côté client :

• cache DNS local du système ;
• cache du navigateur ;
• résolveur poussé par le DHCP ;
• VPN, proxy, filtrage sécurité ;
• fichier hosts ;
• incident sur la box ou le réseau local.

Sur Windows, ipconfig /flushdns vide le cache du résolveur. Sur systemd-resolved, resolvectl flush-caches. Sur macOS, la commande dépend de la version du système. Pour Chrome, le cache hôte interne peut aussi conserver un état obsolète, mais ce n’est utile que si les résolveurs externes répondent correctement.

Si plusieurs machines du même LAN échouent, mieux vaut vérifier si le problème vient du poste ou du réseau local avant d’accuser la zone DNS.

Quand le domaine ne résout nulle part

Si plusieurs requêtes externes aboutissent à nxdomain, le navigateur n’a rien cassé. Le problème se situe presque toujours dans l’un de ces cas :

• l’enregistrement A ou AAAA manque pour le nom demandé ;
• la délégation des serveurs de noms est incomplète ou erronée chez le registraire ;
• la zone n’a pas été rechargée après modification ;
• le domaine est expiré, suspendu ou non renouvelé ;
• un sous-domaine est interrogé alors qu’aucun enregistrement ne l’annonce.

Commencez par interroger le nom exact, puis sa zone parente :

• dig exemple.com A
• dig www.exemple.com A
• dig exemple.com NS
• dig +trace exemple.com

Le +trace est particulièrement utile : il montre la chaîne de délégation, depuis la racine jusqu’aux serveurs autoritatifs. Si la chaîne s’interrompt ou pointe vers des NS qui ne répondent pas de façon cohérente, vous avez un début d’explication solide.

Lire les réponses : A manquant, NS cassés, zone absente

Quelques motifs reviennent souvent.

Enregistrement A manquant

Vous obtenez NOERROR sans section Answer pour le type A. Le nom existe, mais aucune IPv4 n’est publiée. Dans ce cas, le domaine ne résout pas pour les clients qui attendent un A, même si d’autres types d’enregistrements existent.

Délégation incomplète chez le registraire

La requête dig exemple.com NS renvoie des serveurs différents de ceux réellement configurés, ou certains NS annoncés ne servent pas la zone. Vérifiez la liste des nameservers déclarés au registraire, puis comparez-la à la configuration effective des serveurs autoritatifs.

Zone non rechargée

Après une modification sur BIND, Knot ou NSD, la configuration peut être correcte sur disque mais non chargée en mémoire. Dans ce cas, l’ancien état continue à répondre. Le journal du service DNS et une requête directe vers l’autoritatif permettent de le confirmer :

• dig @ns1.exemple.net exemple.com A

Interrogez chaque serveur annoncé séparément. Si l’un répond et pas l’autre, la zone n’est pas cohérente partout.

Domaine expiré

Un WHOIS peut montrer une date d’expiration passée, un statut de suspension ou un changement de délégation. Selon le registre et le bureau d’enregistrement, la publication DNS peut s’arrêter ou devenir partielle. La commande exacte et la sortie dépendent du TLD, mais la vérification WHOIS reste standard.

Les commandes utiles pour administrer le diagnostic

Pour un diagnostic rapide et documenté, gardez cette séquence :

• dig @1.1.1.1 nom A : verdict depuis un résolveur public.
• dig @8.8.8.8 nom A : comparaison avec un autre acteur.
• dig nom NS : contrôle de la délégation visible.
• dig +trace nom : lecture de la chaîne complète.
• dig @nsX zone A : comparaison entre autoritatifs.
• whois domaine.tld : état administratif du domaine.

Si vous gérez plusieurs incidents en parallèle, appliquez une méthode de diagnostic réseau pour consigner l’heure, le résolveur interrogé, le type de requête et le code de réponse. C’est ce qui évite les faux positifs dus au cache.

Après une correction, gardez en tête que les caches DNS ne s’actualisent pas tous au même rythme. Le délai dépend du TTL publié et des résolveurs intermédiaires, ce que détaille la propagation DNS et ses délais.

Corriger durablement, pas seulement faire disparaître l’erreur

Une fois la cause trouvée, la correction doit correspondre au niveau de panne :

• si le nom manque, créez l’enregistrement A ou AAAA attendu ;
• si les NS sont faux, corrigez-les chez le registraire puis vérifiez la réponse autoritative ;
• si la zone n’est pas chargée, rechargez le service et relisez les logs ;
• si le domaine a expiré, renouvelez-le puis contrôlez la republication ;
• si le souci est local, corrigez le résolveur distribué par DHCP, le cache ou le filtrage.

Cette discipline vaut aussi en amont, dès le choix et la gestion d’un nom de domaine, car beaucoup d’erreurs de délégation viennent d’un inventaire mal tenu des zones, des NS et des dates de renouvellement.

La réserve

Le test par résolveur public est le meilleur raccourci pour séparer poste et domaine, mais il a une limite : certains environnements utilisent une vue DNS interne, avec des enregistrements privés absents de l’Internet public. Dans ce cas, un NXDOMAIN sur 1.1.1.1 n’est pas forcément une panne, il peut être normal hors du réseau de l’entreprise. Autre contrepartie, un résolveur public peut masquer temporairement un changement récent à cause du cache. Il faut donc toujours confronter le résultat externe, la réponse autoritative et le contexte de publication réel.

Questions frequentes

Comment résoudre le problème DNS_PROBE_FINISHED_NXDOMAIN ?

Commencez par interroger le nom depuis une autre machine avec un résolveur public, par exemple dig @1.1.1.1 domaine.tld A. Si vous obtenez NXDOMAIN partout, le problème vient du domaine, de sa zone, de sa délégation ou de son état administratif. Si le nom résout ailleurs, regardez le poste, le cache DNS, le résolveur local, le VPN ou le réseau d’accès. C’est ce test qui évite de perdre du temps sur le navigateur quand le domaine ne résout pas réellement.

Comment vider le cache DNS sur Google Chrome ?

Dans Chrome, ouvrez la page interne des sockets et videz le cache hôte, puis relancez le navigateur si nécessaire. Cela peut aider quand Chrome conserve une ancienne résolution, mais seulement si le domaine répond correctement sur des résolveurs externes. Si 1.1.1.1 ou 8.8.8.8 renvoient toujours NXDOMAIN, vider le cache de Chrome ne corrigera rien, car la panne se situe en amont, côté DNS publié.

Comment débloquer le DNS ?

Il faut d’abord savoir ce qui bloque. Si le résolveur local échoue mais qu’un résolveur public répond, changez temporairement de DNS ou corrigez le résolveur fourni par le réseau. Si tous les résolveurs renvoient NXDOMAIN, le DNS n’est pas à débloquer côté client : il faut corriger l’enregistrement manquant, la délégation NS, la zone non rechargée ou le statut du domaine. Le bon niveau d’action dépend donc du code de réponse observé.