Diagnostiquer NXDOMAIN, SERVFAIL et un site injoignable

Partir du nom exact et du type

La barre d’adresse fait foi. www.exemple.fr et exemple.fr sont deux noms. L’un peut être un CNAME sain et l’autre un NXDOMAIN. On note aussi le type dont l’application a besoin : A ou AAAA pour le web, MX pour le courrier, TXT pour une vérification. Tester « le domaine » sans type mélange des pannes différentes.

On interroge ensuite au moins un résolveur public et un serveur autoritatif. L’outil le fait pour les quatre résolveurs 1.1.1.1, 8.8.8.8, 9.9.9.9 et 94.140.14.14, puis pour les NS découverts. Le code de chaque ligne se range dans un petit nombre de cas. Le reste de ce guide est ce tri.

On garde l’heure. Un NXDOMAIN de 10 heures du matin, corrigé à 10 h 05 dans la zone, peut survivre dans un cache jusqu’au TTL négatif. Sans l’heure et sans le TTL, on rouvre un ticket déjà résolu côté zone.

NXDOMAIN : le nom n’existe pas

NXDOMAIN affirme que le nom n’est pas dans la zone qui fait autorité. Le 23 octobre 2026, la question A pour cette-etiquette-nexiste-pas.wikipedia.org vers 1.1.1.1 renvoyait :

status: NXDOMAIN
wikipedia.org. 3600 IN SOA ns0.wikimedia.org. hostmaster.wikimedia.org. 2026060420 43200 7200 1209600 3600

Le SOA en section authority confirme quelle zone a répondu non. Le TTL 3600 est celui du cache négatif, égal au champ minimum du SOA de wikipedia.org relevé le même jour. Un autre exemple, nom-inexistant-zz.example, renvoyait NXDOMAIN avec le SOA de la racine (a.root-servers.net, série 2026102300) : ici c’est le suffixe .example qui n’existe pas comme délégation, pas une étiquette oubliée dans une zone réelle.

Pistes, dans l’ordre : faute de frappe, enregistrement créé dans la mauvaise zone, nom encore jamais publié, cache négatif antérieur à la création. Si l’autoritatif dit déjà NOERROR avec des données et qu’un résolveur dit encore NXDOMAIN, c’est le cache, pas la zone. Le délai est borné par le TTL négatif. Le guide TTL et caches explique pourquoi vider le cache du poste ne suffit pas.

Ne « corrigez » pas un NXDOMAIN en ajoutant un wildcard au hasard. Un wildcard masque les fautes de frappe et complique les réponses négatives. On crée le nom qui manque.

NOERROR vide : le type n’est pas publié

Un statut NOERROR avec une section answer vide ne veut pas dire que le nom est inconnu. Il veut dire que ce type n’a pas de donnée. Le 23 octobre 2026, le CAA d’example.com était dans ce cas : pas de CAA, SOA en authority, TTL 1800. Le A du même nom existait. Conclure « example.com est en panne » à partir du CAA serait faux. Conclure « le CAA est absent » est exact.

Pour un site, un NODATA en A et en AAAA signifie qu’aucune adresse n’est publiée. Le nom peut exister par un NS, un TXT ou un SOA au sommet. Le navigateur, lui, n’a rien à connecter. On ajoute l’enregistrement du bon type, ou l’on répare le CNAME dont la cible n’a pas d’adresse. Ce deuxième cas ressemble à un NODATA vu de l’utilisateur final alors que le premier nom, lui, a bien un CNAME. Il faut demander le type CNAME explicitement, pas seulement le A si une interface intermédiaire a avalé l’alias.

MX vide et MX nul ne sont pas le même diagnostic. L’absence de MX fait tenter, chez beaucoup de serveurs de courrier, une livraison vers le A du sommet. Un MX 0 . interdit la livraison. example.com est dans le second cas, avec un SPF -all. On ne le traite pas comme un oubli.

SERVFAIL : la réponse n’a pas pu être construite

SERVFAIL ne dit pas « le nom n’existe pas ». Il dit « je n’ai pas réussi ». Les causes courantes sont un autoritatif injoignable, une zone que le serveur refuse de charger, ou une validation DNSSEC en échec. Le 23 octobre 2026, dnssec-failed.org en type A chez 1.1.1.1 donnait SERVFAIL et l’explication étendue EDE 9, DNSKEY manquante par rapport au DS. Un dig sans DNSSEC vers l’autoritatif peut encore montrer des données : la panne est alors dans la validation, pas dans l’absence du site. Le guide DNSSEC donne l’ordre de réparation : DS, clés, signatures, horloge.

Si tous les autoritatifs expirent (timeout) et que les résolveurs finissent en SERVFAIL, la piste est réseau ou système : mauvaise adresse de glue, pare-feu qui bloque le port 53, NS qui ne portent plus la zone. Si un seul résolveur est en SERVFAIL et les autres en NOERROR avec les mêmes valeurs, on n’y touche pas dans la zone. Ce résolveur-là a un problème, au moins pour ce nom, à cet instant.

Un code REFUSED ou un renvoi (RENVOI dans l’outil) se distingue du SERVFAIL. REFUSED est un choix du serveur. Un renvoi sans drapeau aa signifie que vous n’avez pas parlé à la zone. On recommence vers les NS indiqués, après avoir vérifié la délégation.

Quand le DNS est bon et le site non

Si les A et AAAA attendus sont identiques chez les résolveurs et les autoritatifs, le DNS a fini son travail. Un refus de connexion, un délai TCP ou une erreur TLS se déboguent sur l’adresse obtenue : service arrêté, mauvais virtual host, certificat qui ne couvre pas le nom, pare-feu, hébergeur qui n’a pas encore déployé le site. Changer les NS à ce stade déplace un problème qui n’est pas dans la zone.

On vérifie quand même le nom jusqu’au bout de la chaîne. Un CNAME vers une cible saine, puis un A vers une adresse qui ne répond pas, est un problème d’hébergement à cette adresse. Un A juste, puis un CAA qui bloque le renouvellement, laisse le site marcher jusqu’à l’expiration du certificat : la panne arrive plus tard et ressemble à « tout le DNS est cassé » alors qu’un seul type est en cause. Les combinaisons sont revues dans le guide CNAME, MX et TXT.

La méthode tient en une phrase : code par code, type par type, autoritatif d’abord, caches ensuite, machine en dernier. Le lexique rappelle NXDOMAIN, SERVFAIL, NOERROR, TTL et FQDN quand il faut écrire le compte rendu sans ambiguïté.