DNS en panne : diagnostiquer NXDOMAIN, SERVFAIL et une délégation cassée avec dig

ParKelvin Carretero-Corrales

Un site ne répond plus, un sous-domaine vient d’être créé ou un certificat refuse de se renouveler : le DNS devient vite le suspect numéro un. Le problème, c’est qu’une commande qui ne renvoie aucune adresse ne dit pas encore pourquoi.

La bonne méthode consiste à séparer quatre questions : le nom existe-t-il, le résolveur interrogé fonctionne-t-il, la délégation mène-t-elle aux bons serveurs et la réponse autoritaire est-elle cohérente ? Avec dig, on peut répondre à chacune sans modifier la zone au hasard.

Commencer par la réponse complète

dig example.com A

Pour le premier test, évitez +short. Cette option est pratique dans un script, mais elle masque le statut, les drapeaux, la section d’autorité, le serveur interrogé et le temps de réponse. Or ce sont précisément ces informations qui permettent de diagnostiquer une panne.

Dans la sortie, regardez d’abord :

  • status dans l’en-tête : NOERROR, NXDOMAIN, SERVFAIL, REFUSED… ;
  • ANSWER : les enregistrements effectivement retournés ;
  • AUTHORITY : la zone ou les serveurs qui font autorité ;
  • flags : notamment aa pour une réponse autoritaire et ra lorsque la récursion est disponible ;
  • SERVER : le résolveur qui vous a répondu ;
  • TTL : la durée pendant laquelle la réponse peut rester en cache.

NXDOMAIN : le nom demandé n’existe pas

NXDOMAIN signifie que le nom demandé est déclaré inexistant. Cela ne veut pas forcément dire que tout le domaine est absent. Une requête sur api.example.com peut recevoir NXDOMAIN alors que example.com fonctionne très bien.

Comparez le nom exact, sa zone parente et les types utiles :

dig api.example.com A
dig api.example.com AAAA
dig example.com SOA
dig example.com NS

Ne confondez pas NXDOMAIN avec une réponse NOERROR sans enregistrement dans la section ANSWER. Dans le second cas, le nom peut exister mais ne pas posséder le type demandé. Par exemple, un nom peut avoir un enregistrement MX sans avoir d’adresse A.

Autre point important : les réponses négatives sont elles aussi mises en cache. Si vous avez interrogé le nom avant de créer l’enregistrement, certains résolveurs peuvent continuer à renvoyer l’ancienne absence jusqu’à expiration du cache négatif, selon les paramètres SOA de la zone. Modifier l’enregistrement plusieurs fois ne fera pas expirer ce cache plus vite.

SERVFAIL : le résolveur n’a pas pu terminer le travail

SERVFAIL est moins précis. Il indique que le serveur n’a pas réussi à produire une réponse exploitable. Les causes possibles incluent un serveur autoritaire injoignable, une délégation incohérente, un délai dépassé, une réponse invalide ou une erreur de validation DNSSEC.

La RFC 8914 définit les erreurs DNS étendues, ou EDE, qui peuvent ajouter un motif comme DNSSEC Bogus, Signature Expired, No Reachable Authority ou Network Error. Tous les résolveurs ne les transmettent pas, mais une version récente de dig peut les afficher lorsqu’elles sont présentes.

Comparez d’abord plusieurs résolveurs, sans conclure trop vite :

dig example.com A
dig @1.1.1.1 example.com A
dig @8.8.8.8 example.com A
dig @9.9.9.9 example.com A

Si un seul résolveur échoue, le problème peut être local à son cache, à sa politique ou à son réseau. Si tous échouent de la même manière, remontez vers la délégation et les serveurs autoritaires. Les résolveurs publics servent ici de points de comparaison ; ils ne remplacent pas automatiquement le DNS prévu par l’entreprise.

Suivre la délégation avec +trace

dig +trace example.com A

+trace reproduit une résolution itérative depuis la racine : serveurs racine, zone de premier niveau, puis serveurs faisant autorité pour le domaine. Le dernier palier atteint donne souvent la zone du problème.

  • Le trace s’arrête avant la zone : vérifiez la délégation chez le registraire.
  • Les NS du parent ne correspondent pas à ceux attendus : corrigez la délégation, pas seulement la zone enfant.
  • Un serveur NS est annoncé mais ne répond pas : contrôlez son adresse, le port 53 en UDP et TCP, son pare-feu et le chargement de la zone.
  • Les serveurs autoritaires ne donnent pas tous la même réponse : vérifiez la réplication, le numéro de série SOA et la configuration de chaque instance.

Attention : +trace interroge directement les serveurs successifs et peut se comporter différemment d’une résolution normale derrière un pare-feu restrictif. Ce n’est pas une preuve isolée ; c’est une carte du chemin.

Interroger directement les serveurs autoritaires

Récupérez les serveurs annoncés, puis questionnez-les un par un sans demander de récursion :

dig example.com NS

dig @ns1.example.net example.com A +norecurse
dig @ns2.example.net example.com A +norecurse
dig @ns1.example.net example.com SOA +norecurse
dig @ns2.example.net example.com SOA +norecurse

Une réponse autoritaire doit normalement porter le drapeau aa. Pour le SOA, comparez surtout le numéro de série. Si les deux serveurs n’ont pas le même, une mise à jour ou un transfert de zone peut être bloqué.

Si les serveurs autoritaires répondent correctement mais qu’un résolveur récursif renvoie encore une ancienne valeur, le problème est probablement dans le cache. Attendez l’expiration du TTL au lieu de relancer une série de changements qui rendrait le diagnostic encore plus confus.

Contrôler DNSSEC sans tirer de fausse conclusion

dig +dnssec example.com A
dig example.com DS
dig example.com DNSKEY +dnssec

+dnssec active le bit DO et demande au serveur d’inclure les données DNSSEC disponibles. Cette option ne transforme pas dig en validateur complet. La présence de signatures ne prouve donc pas, à elle seule, que toute la chaîne est valide.

En cas de SERVFAIL suspect, un test comparatif avec le drapeau CD peut aider :

dig @1.1.1.1 example.com A
dig @1.1.1.1 example.com A +cdflag

Si la requête normale échoue mais que celle avec +cdflag reçoit une réponse, une erreur DNSSEC devient une piste forte. Ce test ne sécurise rien et ne constitue pas une correction : il demande au résolveur de ne pas bloquer la réponse sur l’échec de validation. La vraie réparation consiste à contrôler les enregistrements DS chez le parent, les DNSKEY de la zone, les signatures RRSIG, leurs dates de validité et l’horloge des serveurs.

Une méthode de diagnostic en huit commandes

# 1. Réponse complète via le résolveur courant
dig example.com A

# 2. Comparaison avec deux résolveurs externes
dig @1.1.1.1 example.com A
dig @9.9.9.9 example.com A

# 3. Délégation publiée
dig example.com NS

# 4. Parcours depuis la racine
dig +trace example.com A

# 5. Réponse de chaque autorité
dig @ns1.example.net example.com A +norecurse
dig @ns2.example.net example.com A +norecurse

# 6. Cohérence des numéros de série
dig @ns1.example.net example.com SOA +norecurse
dig @ns2.example.net example.com SOA +norecurse

# 7. Présence des éléments DNSSEC
dig +dnssec example.com A

# 8. Comparaison diagnostique sans blocage de validation
dig @1.1.1.1 example.com A +cdflag

Les erreurs qui font perdre du temps

  • Utiliser uniquement +short et perdre le statut de la réponse.
  • Tester un seul résolveur puis parler de « propagation mondiale ».
  • Confondre une absence de réponse DNS avec un problème HTTP, TLS ou applicatif.
  • Modifier simultanément les NS, le contenu de zone et DNSSEC.
  • Vider uniquement le cache local alors que la réponse négative est conservée par un résolveur distant.
  • Désactiver DNSSEC pour faire disparaître SERVFAIL sans corriger la chaîne de confiance.
  • Oublier que DNS utilise aussi TCP sur le port 53, notamment pour certaines réponses volumineuses et opérations entre serveurs.

Conclusion

Une panne DNS se résout plus vite quand on arrête de parler vaguement de propagation. Identifiez le statut, comparez les résolveurs, suivez la délégation, interrogez les autorités et contrôlez DNSSEC séparément. Chaque étape réduit le périmètre sans ajouter une nouvelle modification à la zone.

Pour un domaine, un site ou un service devenu inaccessible, FuretSplick propose un diagnostic et une remise en service en commençant par isoler l’origine du problème avant d’agir.

Sources

Publications similaires