DNS : NXDOMAIN vs SERVFAIL — comment diagnostiquer et réparer rapidement

décembre 28, 2025 • février 3, 2026 • Lecture : 29 min • Views: 6

Cet article vous a aidé ?

Quand le DNS casse, ce n’est jamais poli. Ça tombe en panne pendant que votre CEO fait une démo, pendant que votre pipeline CI « fait juste un déploiement rapide », et la moitié de l’entreprise ne peut plus atteindre « Internet » (qui, pour eux, est une page de connexion SaaS).

La manière la plus rapide de récupérer votre temps est d’arrêter de traiter chaque erreur DNS comme une ambiance. NXDOMAIN et SERVFAIL ne sont pas le même type d’échec. Ils indiquent des choses cassées différentes, appartenant à des équipes différentes, réparées par des actions différentes.

NXDOMAIN vs SERVFAIL : deux codes, deux mondes de panne

NXDOMAIN en une phrase

NXDOMAIN signifie : « Le nom de domaine que vous avez demandé n’existe pas » (plus précisément : le serveur croit que ce nom n’existe pas dans le DNS). C’est une réponse, pas un plantage.

SERVFAIL en une phrase

SERVFAIL signifie : « Je ne peux pas répondre pour le moment. » C’est un échec à produire une réponse — souvent dû à des problèmes en amont, des échecs de validation DNSSEC, des délégations lame, une récursion cassée, ou des problèmes internes du résolveur.

Le raccourci en production : ce que chaque code implique généralement

NXDOMAIN : le plus souvent un problème de données/config (mauvais nom, enregistrement manquant, mauvais zone, mismatch split-horizon, cache négatif obsolète). Le système fonctionne ; il vous dit « non ».
SERVFAIL : le plus souvent un problème de chemin/validation/disponibilité (le résolveur ne peut pas atteindre l’autorité, l’autorité se comporte mal, la chaîne DNSSEC est cassée, la récursion est bloquée, MTU/fragmentation, problèmes EDNS, timeouts). Le système ne répond pas correctement.

C’est tout le jeu. NXDOMAIN vous pousse vers « est-ce que ce nom existe là où je pense qu’il existe ? » SERVFAIL vous pousse vers « pourquoi le résolveur ne peut-il pas compléter la résolution en toute sécurité ? »

Blague #1 : Le DNS, c’est comme un annuaire téléphonique qui peut répondre « personne inconnue » ou « j’ai une mauvaise journée » — et les deux ruinent votre week-end de la même manière.

Que faire immédiatement quand vous voyez chaque cas

Si c’est NXDOMAIN :

Confirmez l’orthographe et le FQDN. Ne riez pas ; faites-le.
Vérifiez que l’enregistrement existe dans la zone autoritaire (pas seulement dans votre repo IaC).
Vérifiez que vous interrogez la bonne vue (publique vs interne / split-horizon).
Vérifiez le cache négatif (SOA minimum / TTL négatif) si vous venez de créer l’enregistrement.

Si c’est SERVFAIL :

Vérifiez si le résolveur échoue pour tout le monde ou seulement pour vous (stub local vs récursif d’entreprise vs résolveurs publics).
Vérifiez la validation DNSSEC : essayez avec et sans validation pour isoler.
Vérifiez la santé de la délégation : enregistrements NS, glue, accessibilité, et si les autorités sont « lame ».
Vérifiez les étrangetés de transport : fragmentation UDP, taille EDNS, règles de pare-feu, limitation de taux.

Playbook de diagnostic rapide (quoi vérifier en premier)

Ceci est le playbook « j’ai cinq minutes avant que le canal incident ne devienne du théâtre de rue ». Suivez-le dans l’ordre. Arrêtez-vous quand vous trouvez le goulot d’étranglement.

Étape 1 : Reproduire avec `dig` et capturer l’erreur exacte

Utilisez dig avec +norecurse et avec la récursion normale, et notez status:, flags:, et SERVER:.
Décision : si le status est NXDOMAIN, pivotez vers « données et zone ». Si SERVFAIL, pivotez vers « chemin et validation ».

Étape 2 : Changer de résolveur pour isoler où ça casse

Interrogez votre résolveur habituel, puis un résolveur public connu sain, puis le nameserver autoritaire directement.
Décision : si le public marche mais que l’entreprise échoue, c’est votre récursion/egress/politique DNSSEC. Si l’autorité échoue, c’est la zone/l’autorité elle-même.

Étape 3 : Identifier les serveurs autoritatifs et les tester individuellement

Utilisez dig NS et interrogez chaque NS pour l’enregistrement exact.
Décision : si un NS diffère, vous avez des problèmes de propagation de zone ou de master caché/transfert. Si tous échouent, c’est global à la zone.

Étape 4 : Si SERVFAIL, faire le test DNSSEC en deux étapes

Utilisez +dnssec et essayez aussi de désactiver la validation sur un résolveur validant (ou utilisez un résolveur non-validant que vous contrôlez).
Décision : si la désactivation de la validation fait fonctionner la requête, vous avez un problème de chaîne DNSSEC (mismatch DS, signatures expirées, DNSKEY manquant, NSEC/NSEC3 incorrect, etc.).

Étape 5 : Vérifier le cache et le comportement TTL

Si vous venez de corriger et que ça échoue toujours, purgez les caches où vous le pouvez (stub local, résolveur récursif) ou attendez la fin des TTL négatifs.
Décision : si l’autorité est correcte mais que les clients voient encore NXDOMAIN/SERVFAIL, vous êtes dans le territoire du cache.

Étape 6 : Chercher des contraintes réseau qui ressemblent à « le DNS est down »

Testez la reachabilité UDP/53 et TCP/53. Surveillez ICMP frag-needed. Vérifiez les logs du pare-feu, les timeouts NAT et les listes d’autorisation egress.
Décision : si TCP marche mais UDP échoue (ou vice versa), corrigez le réseau. Le DNS n’est que le messager.

Comment DNS arrive à NXDOMAIN ou SERVFAIL (sans le conte de fées)

La résolution DNS est une chaîne de responsabilités. Votre application interroge typiquement un stub resolver (souvent sur l’hôte), qui interroge un résolveur récursif (DNS d’entreprise, FAI, ou résolveur public), qui parcourt l’arbre en interrogeant les serveurs autoritatifs.

NXDOMAIN : un « non » autoritaire (ou un non crédible)

NXDOMAIN est renvoyé lorsque le répondant croit que le nom n’existe pas. Dans un monde propre, cela vient du serveur autoritatif pour la zone, soutenu par une preuve (SOA dans la section authority, éventuellement NSEC/NSEC3 avec DNSSEC).

Mais en production, NXDOMAIN peut aussi être :

Mismatch split-horizon : la vue interne dit « nom absent », la vue publique l’a (ou inversement).
Accidents de suffixe de recherche : le client a demandé api et le résolveur a essayé api.corp.example, obtenu NXDOMAIN, et votre appli logge « api n’existe pas ».
Cache négatif : un résolveur a mis en cache un NXDOMAIN ; vous avez créé l’enregistrement ; tout le monde continue de voir NXDOMAIN jusqu’à l’expiration du TTL négatif.
Interactions avec wildcard : vous pensiez qu’un wildcard couvrait, mais il ne couvre pas tous les types ou tous les labels comme vous le supposiez.

SERVFAIL : un résolveur refusant de mentir

SERVFAIL, c’est le résolveur qui dit « je n’ai pas réussi à obtenir une réponse fiable ». Cela peut arriver pour de nombreuses raisons, et un bon résolveur est prudent : il préfère échouer plutôt que de fournir une réponse qu’il ne peut pas valider ou compléter.

Parcours courants de SERVFAIL :

Échec de validation DNSSEC : le résolveur a obtenu une réponse, mais les signatures n’ont pas validé. Il renvoie SERVFAIL au client.
Timeouts et autorités inatteignables : la récursion ne peut pas atteindre les serveurs autoritatifs, souvent à cause de règles de pare-feu, mitigation DDoS, routes anycast cassées, ou simplement des nameservers morts.
Délégation lame : les enregistrements NS pointent vers des serveurs qui ne sont pas autoritatifs pour la zone. Les résolveurs perdent du temps ; certains renvoient SERVFAIL.
Troncation et problèmes TCP : les réponses DNS larges (DNSSEC les rend plus grosses) sont tronquées en UDP, puis TCP/53 est bloqué, causant des échecs.
Problèmes EDNS/fragmentation : tailles EDNS, PMTU blackholes, ou middleboxes qui suppriment les UDP fragmentés.

Blague #2 : SERVFAIL, c’est le DNS qui dit « je pourrais vous le dire, mais il faudrait que je vous valide d’abord ».

Un modèle mental utile : « Où est stockée la vérité, et qui échoue à la récupérer ? »

Les serveurs autoritatifs stockent la vérité. Les résolveurs récursifs la récupèrent, la valident et la mettent en cache. NXDOMAIN est généralement un problème de vérité. SERVFAIL est généralement un problème de récupération/validation.

Faits et historique qui aident vraiment pendant les incidents

Ce ne sont pas des faits pour un quiz. Ils changent votre façon de déboguer.

NXDOMAIN est défini comme RCODE 3. Ce n’est pas « pas de données ». « Pas de données » est une réponse NOERROR avec une section answer vide (souvent appelée NODATA).
SERVFAIL est RCODE 2. Il est volontairement vague : il couvre de nombreux échecs internes, y compris les timeouts en amont et les échecs de validation DNSSEC.
Le cache négatif est standardisé. Les résolveurs mettent en cache NXDOMAIN et NODATA en utilisant les valeurs SOA de la zone (couramment le champ minimum SOA / comportement TTL négatif), d’où le fait que « je viens d’ajouter l’enregistrement » peut encore sembler cassé.
Le DNS a été conçu d’abord pour UDP. TCP existe pour les transferts de zone et les réponses tronquées, mais les réseaux réels traitent souvent TCP/53 comme suspect. C’est une recette pour SERVFAIL quand les réponses deviennent grosses.
DNSSEC a rendu les réponses plus volumineuses et le débogage plus tranchant. Les échecs de validation apparaissent souvent comme SERVFAIL au résolveur, même quand les serveurs autoritatifs servent correctement des données.
La « délégation lame » est un mode d’échec classique. Déléguer vers des nameservers qui ne servent pas réellement la zone brûle le temps des résolveurs et augmente la latence de queue — parfois jusqu’à SERVFAIL.
EDNS(0) a été introduit pour étendre le DNS sans le casser. Les middleboxes perturbent parfois EDNS, entraînant des comportements étranges : timeouts, boucles de troncation, ou SERVFAIL selon la logique du résolveur.
Les infrastructures root et TLD ont évolué pour réduire la fragilité. Les déploiements anycast et les multiples enregistrements NS visent à améliorer la disponibilité, mais peuvent aussi masquer des pannes partielles jusqu’à ce qu’un changement de route les expose.
Les domaines de recherche (resolv.conf) sont une arme à feu d’entreprise. Ils créent des requêtes que vous n’aviez pas l’intention d’émettre. Le débogage nécessite des noms pleinement qualifiés pour éviter des NXDOMAIN fantômes.

Une idée de fiabilité à garder : si vous concevez pour que la panne soit normale, vous passerez moins de temps à prétendre qu’elle est exceptionnelle.

Tâches pratiques : commandes, sorties, décisions (12+)

Voici les choses que vous lancez réellement à 02:00. Chaque tâche inclut : la commande, un exemple de ce que vous pouvez voir, ce que cela signifie, et ce que vous faites ensuite.

Tâche 1 : Obtenir le statut de base et confirmer quel résolveur a répondu

cr0x@server:~$ dig api.example.com A

; <<>> DiG 9.18.24 <<>> api.example.com A
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 42118
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; QUESTION SECTION:
;api.example.com.            IN      A

;; AUTHORITY SECTION:
example.com.         300     IN      SOA     ns1.example.net. hostmaster.example.com. 2025123101 7200 3600 1209600 300

;; Query time: 21 msec
;; SERVER: 10.10.0.53#53(10.10.0.53) (UDP)
;; WHEN: Wed Dec 31 10:12:01 UTC 2025
;; MSG SIZE  rcvd: 115

Signification : Votre résolveur récursif à 10.10.0.53 renvoie NXDOMAIN. Il affiche aussi un SOA, ce qui suggère que le résolveur croit avoir une preuve autoritaire de non-existence (ou une preuve mise en cache).

Décision : Ne poursuivez pas le réseau pour l’instant. Vérifiez si api.example.com existe dans la zone autoritaire et si vous interrogez la bonne vue DNS.

Tâche 2 : Comparer avec un autre résolveur récursif

cr0x@server:~$ dig @1.1.1.1 api.example.com A

; <<>> DiG 9.18.24 <<>> @1.1.1.1 api.example.com A
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 5329
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; ANSWER SECTION:
api.example.com.     60      IN      A       203.0.113.10

;; SERVER: 1.1.1.1#53(1.1.1.1) (UDP)
;; Query time: 18 msec

Signification : La récursion publique renvoie un enregistrement A valide ; votre résolveur d’entreprise renvoie NXDOMAIN. Ce n’est pas « le DNS est down ». C’est un problème de politique/vue/cache chez vous.

Décision : Vérifiez la configuration split-horizon, les règles de forwarding, RPZ/listes de blocage, ou le cache négatif obsolète sur le résolveur d’entreprise.

Tâche 3 : Forcer un nom pleinement qualifié pour éviter les mensonges des search domains

cr0x@server:~$ dig api A

; <<>> DiG 9.18.24 <<>> api A
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 1204
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
;; QUESTION SECTION:
;api.                          IN      A

;; AUTHORITY SECTION:
.                       86400   IN      SOA     a.root-servers.net. nstld.verisign-grs.com. 2025123100 1800 900 604800 86400

Signification : Vous avez demandé api. (le nom littéral au niveau racine), pas api.example.com. Les applications et les humains font cela accidentellement via les suffixes de recherche et les points manquants.

Décision : Utilisez des FQDN dans les configs. En débogage d’incident, interrogez toujours le nom complet finissant par un point si vous voulez être pointilleux : api.example.com.

Tâche 4 : Vérifier si c’est NXDOMAIN vs NODATA (NOERROR, réponse vide)

cr0x@server:~$ dig www.example.com AAAA

; <<>> DiG 9.18.24 <<>> www.example.com AAAA
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 64430
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; AUTHORITY SECTION:
example.com.         300     IN      SOA     ns1.example.net. hostmaster.example.com. 2025123101 7200 3600 1209600 300

Signification : Le nom existe, mais il n’y a pas d’enregistrement AAAA. Ce n’est pas NXDOMAIN, et la correction est différente.

Décision : Si votre appli nécessite IPv6, ajoutez un AAAA ou corrigez le comportement du client. Sinon, ignorez et arrêtez de vous alerter inutilement.

Tâche 5 : Trouver les serveurs de noms autoritatifs (et vérifier que la délégation semble saine)

cr0x@server:~$ dig example.com NS +noall +answer

example.com.     172800  IN  NS  ns1.example.net.
example.com.     172800  IN  NS  ns2.example.net.

Signification : Ce sont les serveurs que le monde interrogera pour example.com.

Décision : Interrogez chaque NS directement pour l’enregistrement. Si les réponses diffèrent, vous avez probablement des problèmes de synchronisation de zone.

Tâche 6 : Interroger le serveur autoritatif directement pour confirmer la réalité

cr0x@server:~$ dig @ns1.example.net api.example.com A +norecurse

; <<>> DiG 9.18.24 <<>> @ns1.example.net api.example.com A +norecurse
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 33201
;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; ANSWER SECTION:
api.example.com.     60      IN      A       203.0.113.10

Signification : L’autorité dit que ça existe et marque la réponse comme autoritaire (drapeau aa). Si votre résolveur récursif renvoie NXDOMAIN, le problème est le cache, le filtrage, le split-horizon, ou la chaîne de forwarders.

Décision : Enquêtez sur le résolveur récursif : état du cache, RPZ, vues, forwarding, et comportement DNSSEC.

Tâche 7 : Vérifier la délégation lame

cr0x@server:~$ dig @ns2.example.net example.com SOA +norecurse

; <<>> DiG 9.18.24 <<>> @ns2.example.net example.com SOA +norecurse
;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 9012
;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

Signification : Le serveur listé comme NS refuse de répondre de manière autoritaire. C’est un problème de délégation (ou d’ACL), et les résolveurs peuvent finir par renvoyer SERVFAIL sous charge ou par sélection malchanceuse.

Décision : Corrigez les enregistrements NS pour pointer vers des serveurs réellement autoritatifs, ou corrigez les ACL du serveur afin qu’il réponde de manière autoritaire pour la zone.

Tâche 8 : Vérifier DNSSEC à la frontière du résolveur

cr0x@server:~$ dig secure.example.com A +dnssec

; <<>> DiG 9.18.24 <<>> secure.example.com A +dnssec
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 4411
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; SERVER: 10.10.0.53#53(10.10.0.53) (UDP)

Signification : SERVFAIL avec DNSSEC en jeu signale souvent un échec de validation, surtout si d’autres résolveurs se comportent différemment.

Décision : Comparez avec un résolveur connu validant correctement, et inspectez la chaîne DS/DNSKEY/RRSIG pour la zone.

Tâche 9 : Utiliser `+trace` pour suivre la délégation étape par étape

cr0x@server:~$ dig secure.example.com A +trace

; <<>> DiG 9.18.24 <<>> secure.example.com A +trace
.                       518400  IN  NS  a.root-servers.net.
...
com.                    172800  IN  NS  a.gtld-servers.net.
...
example.com.             172800  IN  NS  ns1.example.net.
example.com.             172800  IN  NS  ns2.example.net.
secure.example.com.      60      IN  A   203.0.113.20

Signification : Le trace montre la chaîne : racine → TLD → vos serveurs autoritatifs → enregistrement final. Si ça casse au milieu, vous savez à quel niveau de délégation se situe le problème.

Décision : Si le trace échoue au niveau TLD, vérifiez les NS/DS côté registrar. Si ça échoue chez vos NS, corrigez votre infrastructure autoritative.

Tâche 10 : Vérifier le fallback TCP (problèmes de troncation)

cr0x@server:~$ dig dnssec-heavy.example.com DNSKEY +dnssec +ignore +bufsize=4096

; <<>> DiG 9.18.24 <<>> dnssec-heavy.example.com DNSKEY +dnssec +ignore +bufsize=4096
;; Truncated, retrying in TCP mode.
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 20031
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

Signification : La réponse ne tenait pas dans UDP, le résolveur a réessayé en TCP. Si TCP/53 est bloqué quelque part, les clients peuvent voir SERVFAIL ou des timeouts.

Décision : Assurez-vous que TCP/53 est autorisé entre les résolveurs récursifs et les serveurs autoritatifs (et parfois entre clients et résolveurs, selon l’architecture).

Tâche 11 : Confirmer ce que votre hôte utilise réellement pour le DNS

cr0x@server:~$ resolvectl status

Global
       Protocols: -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
resolv.conf mode: stub

Link 2 (eth0)
    Current Scopes: DNS
         Protocols: +DefaultRoute
Current DNS Server: 10.10.0.53
       DNS Servers: 10.10.0.53 10.10.0.54
        DNS Domain: corp.example

Signification : Votre systemd-resolved stub transfère vers des résolveurs d’entreprise et ajoute corp.example comme domaine de recherche.

Décision : Si vous voyez des requêtes surprenantes, désactivez ou contraignez les domaines de recherche pour les services critiques. Vérifiez aussi que les deux serveurs DNS listés se comportent de la même façon.

Tâche 12 : Détecter « un résolveur est malade » en interrogeant les deux explicitement

cr0x@server:~$ dig @10.10.0.53 api.example.com A +time=1 +tries=1

;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 31990
;; Query time: 1001 msec
;; SERVER: 10.10.0.53#53(10.10.0.53) (UDP)

cr0x@server:~$ dig @10.10.0.54 api.example.com A +time=1 +tries=1

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 31991
;; ANSWER SECTION:
api.example.com. 60 IN A 203.0.113.10

Signification : Un résolveur récursif échoue ; l’autre marche. C’est plus courant qu’on ne le veut : cache mauvais, amont bloqué, thrash CPU, état DNSSEC cassé.

Décision : Retirez le résolveur défaillant de la rotation (option DHCP, load balancer, retrait anycast), puis déboguez-le hors ligne.

Tâche 13 : Vérifier les logs BIND/unbound pour les erreurs de validation et upstream

cr0x@server:~$ sudo journalctl -u unbound --since "10 minutes ago" | tail -n 10

Dec 31 10:05:22 resolver1 unbound[1321]: info: validation failure <secure.example.com. A>: signature expired
Dec 31 10:05:22 resolver1 unbound[1321]: info: resolving secure.example.com. A
Dec 31 10:05:22 resolver1 unbound[1321]: info: error: SERVFAIL secure.example.com. A IN

Signification : Le résolveur indique explicitement que la signature DNSSEC est expirée. C’est une des causes de SERVFAIL les plus nettes que vous puissiez obtenir.

Décision : Corrigez la signature DNSSEC pour la zone (re-signer, corriger la synchronisation temporelle du signataire, assurer les rollovers automatisés). Mesure temporaire : rediriger les clients critiques vers un résolveur qui ne valide pas (avec précaution), mais traitez cela comme un pansement d’urgence, pas comme une solution durable.

Tâche 14 : Confirmer la santé du serveur autoritatif et le chargement des zones

cr0x@server:~$ sudo rndc status

version: BIND 9.18.24 (Stable Release)
running on ns1: Linux x86_64 6.5.0
boot time: Wed, 31 Dec 2025 08:12:07 GMT
last configured: Wed, 31 Dec 2025 09:58:41 GMT
number of zones: 128
debug level: 0
xfers running: 0
up time: 1h 59m

Signification : BIND est en marche et n’est pas visiblement surchargé. Cela ne prouve pas que votre zone est correcte, mais cela écarte « named est mort ».

Décision : Si vous suspectez des échecs de chargement de zone, inspectez les logs et confirmez le serial et les enregistrements de la zone.

Tâche 15 : Vérifier le serial de zone et si les secondaires sont synchronisés

cr0x@server:~$ dig @ns1.example.net example.com SOA +noall +answer
example.com. 300 IN SOA ns1.example.net. hostmaster.example.com. 2025123101 7200 3600 1209600 300

cr0x@server:~$ dig @ns2.example.net example.com SOA +noall +answer
example.com. 300 IN SOA ns1.example.net. hostmaster.example.com. 2025123009 7200 3600 1209600 300

Signification : Les serials diffèrent. Un nameserver sert une zone plus ancienne. Cela peut se manifester par des NXDOMAIN intermittents (selon le NS choisi par le résolveur).

Décision : Corrigez les transferts de zone (clés TSIG, ACL allow-transfer, configuration notify, reachabilité réseau). N’optez pas pour un « DNS eventual consistency » à moins d’aimer les pannes mystérieuses.

Trois mini-histoires d’entreprise (et leurs enseignements)

Incident 1 : La panne causée par une mauvaise hypothèse (NXDOMAIN faisant croire à une panne réseau)

Dans une entreprise moyenne avec une configuration cloud hybride, une équipe a migré un service interne de api.int.corp vers api.internal.corp. Ils ont fait les choses polies : mis à jour la découverte de service, changé quelques configs, mergé le PR, et sont passés à autre chose.

Puis un on-call a été alerté : « Service inaccessible. » Les logs applicatifs montraient des NXDOMAIN répétés pour api.int.corp. L’on-call a supposé une panne du résolveur parce que « NXDOMAIN veut dire que DNS ne peut pas le trouver, donc le DNS doit être en panne. » Cette supposition leur a fait perdre une heure.

Le problème réel était ennuyeux. Un job batch legacy avait l’ancien hostname en dur. Il tournait une fois par heure, déclenchait des retries, et faisait suffisamment de bruit pour ressembler à un problème de plateforme. Le DNS fonctionnait parfaitement et disait la vérité : ce nom n’existait plus.

La correction n’a pas été héroïque. Ils ont cherché la chaîne dans le repo de gestion de configuration, trouvé le job, déployé le nouveau nom, et ajouté un CNAME temporaire de l’ancien nom vers le nouveau pendant une semaine. Ils ont aussi affiné la surveillance pour différencier les pics NXDOMAIN par nom, pas juste « erreurs DNS ».

Leçon : NXDOMAIN est souvent le DNS qui fait son travail. Quand vous voyez NXDOMAIN, suspectez d’abord vos inputs : noms, zones, vues, caches. Ne « redémarrez pas le DNS » pour corriger une faute de frappe embarquée dans 200 nœuds.

Incident 2 : L’optimisation qui a mal tourné (SERVFAIL via DNSSEC + histoire des paquets plus petits)

Une équipe plateforme voulait un DNS plus rapide. Ils ont ajusté leurs résolveurs récursifs : tailles de buffer UDP plus petites, timeouts agressifs, et quelques réglages EDNS « on n’en a pas besoin » copiés d’un vieux fil de forum. Les graphiques avaient l’air bien pendant un mois. Latence réduite, dashboards verts. Tout le monde hochait la tête.

Puis un partenaire a activé DNSSEC sur une zone dont dépendait la société. Soudain, une fraction des requêtes a commencé à renvoyer SERVFAIL. Pas toutes. Juste assez pour ruiner les connexions client dans une géographie et faire douter le responsable incident.

La racine n’était pas le partenaire. C’était l’« optimisation » : taille EDNS réduite provoquait plus de troncation, forçait le fallback TCP. Mais la sortie TCP/53 de ces résolveurs était autorisée de façon incohérente à travers les NAT gateways. Parfois ça marchait ; parfois non. Les résolveurs qui ne pouvaient pas compléter la validation renvoyaient SERVFAIL. Le DNSSEC du partenaire avait juste grossi les paquets assez pour tomber dans le piège.

La correction était peu glamour : revenir sur les tweaks EDNS, standardiser la politique de pare-feu pour autoriser TCP/53 depuis les résolveurs récursifs, et définir des timeouts basés sur le comportement réel en amont plutôt que sur de l’idéologie. Ils ont aussi ajouté un canari qui interroge volontairement un enregistrement lourd DNSSEC pour s’assurer que le fallback TCP fonctionne.

Leçon : Les « optimisations » DNS qui ignorent le protocole complet (UDP et TCP, EDNS, DNSSEC) sont juste des bombes à retardement avec de meilleurs métriques.

Incident 3 : La pratique ennuyeuse qui a sauvé la mise (vérifications de délégation cohérentes)

Une grande entreprise gérait son propre DNS autoritatif plus un fournisseur secondaire managé. Chaque changement passait par une checklist : mettre à jour la zone, incrémenter le serial, valider la syntaxe, pousser vers le hidden master, confirmer que les secondaires ont le nouveau serial, puis lancer une vérification externe de délégation depuis au moins deux réseaux.

Un jour, un changement côté registrar est intervenu lors d’un projet de consolidation de domaines. Les enregistrements NS ont été mis à jour. Un changement raisonnable — sauf qu’un des nameservers listés ne servait pas encore la zone. Délégation lame : manuel scolaire.

La différence a été que leur vérification post-change l’a détectée en minutes. Ils ont interrogé l’ensemble NS listé individuellement, vu qu’un répondait REFUSED, et ont rollbacké la délégation avant que les caches Internet n’absorbent l’état erroné. Les utilisateurs n’ont rien remarqué. Le chef de projet a quand même obtenu sa consolidation.

Leçon : La validation de délégation est ennuyeuse comme la ceinture de sécurité. On ne la sent pas fonctionner. On remarque juste quand elle manque.

Erreurs courantes : symptôme → cause racine → correction

1) « NXDOMAIN pour un enregistrement que nous venons de créer »

Symptôme : dig renvoie NXDOMAIN pour un nom que vous avez ajouté il y a quelques minutes.

Cause racine : Cache négatif chez les résolveurs récursifs (NXDOMAIN mis en cache), ou vous avez mis à jour une seule vue/zone (interne vs publique), ou les secondaires ne sont pas synchronisés.

Correction : Interrogez l’autorité directement pour confirmer l’existence. Vérifiez le serial SOA sur chaque NS. Si l’autorité est correcte, attendez l’expiration du TTL négatif ou videz les caches des résolveurs que vous contrôlez.

2) « NXDOMAIN intermittent »

Symptôme : Parfois ça résout, parfois NXDOMAIN.

Cause racine : Jeu d’autoritatifs split-brain (certains NS ont l’enregistrement, d’autres non), ou nœuds anycast servant différentes versions de la zone.

Correction : Interrogez chaque NS autoritatif directement. Comparez les serials SOA. Corrigez les transferts/notify et assurez un déploiement atomique sur les nœuds autoritatifs.

3) « SERVFAIL depuis le DNS d’entreprise, mais les résolveurs publics fonctionnent »

Symptôme : dig @10.10.0.53 renvoie SERVFAIL ; dig @1.1.1.1 fonctionne.

Cause racine : Échec de validation DNSSEC dû à des trust anchors obsolètes, mauvaise synchronisation temporelle sur les résolveurs, filtrage de politique (RPZ), ou TCP/53 bloqué empêchant la validation.

Correction : Consultez les logs du résolveur pour les erreurs de validation. Assurez-vous que NTP est correct. Vérifiez la sortie TCP/53. Passez en revue les hits RPZ et les exceptions.

4) « SERVFAIL uniquement pour les domaines activés DNSSEC »

Symptôme : Certaines zones renvoient toujours SERVFAIL, d’autres sont correctes.

Cause racine : Problèmes de chaîne DNSSEC (RRSIG expiré, mismatch DS après rollover de clé, DNSKEY incorrect).

Correction : Utilisez dig +trace +dnssec et vérifiez le DS au parent vs DNSKEY dans l’enfant. Re-signez la zone ou corrigez le DS chez le registrar/parent.

5) « Tout échoue dans Kubernetes, mais les nœuds peuvent résoudre »

Symptôme : Les pods voient SERVFAIL/NXDOMAIN ; l’hôte résout correctement.

Cause racine : Mauvaise config CoreDNS upstream, problèmes NodeLocal DNSCache, règles iptables, ou différences de stub resolver.

Correction : Interrogez depuis l’intérieur du pod vers l’IP du service CoreDNS et vers l’amont. Vérifiez les logs CoreDNS, le configmap, et les network policies pour UDP/TCP 53.

6) « NOERROR mais l’appli dit ‘host not found’ »

Symptôme : Le DNS renvoie NOERROR sans réponse ; l’appli échoue.

Cause racine : Vous avez interrogé un type d’enregistrement qui n’existe pas (AAAA vs A), ou l’appli nécessite SRV/TXT et vous n’avez vérifié que A.

Correction : Interrogez les types d’enregistrements exacts utilisés par l’appli. Pour la découverte de services moderne, vérifiez SRV/TXT et le comportement des bibliothèques.

7) « Pics de SERVFAIL après activation d’une protection DDoS »

Symptôme : SERVFAIL soudain sous charge ou après des changements de sécurité.

Cause racine : Limitation de taux ou règles de pare-feu supprimant des fragments, bloquant TCP/53, ou filtrant le trafic EDNS.

Correction : Validez les chemins UDP et TCP. Ajustez les limites de taux. Si vous devez filtrer, faites-le en connaissance de cause et testez les réponses lourdes DNSSEC.

8) « NXDOMAIN pour un nom interne depuis des laptops en VPN »

Symptôme : Sur VPN ça échoue ; hors VPN ça marche (ou inversement).

Cause racine : DNS split non correctement poussé par le VPN, ou les vues du résolveur d’entreprise dépendent des plages d’IP source.

Correction : Vérifiez quels résolveurs les clients utilisent en VPN. Confirmez les ACL des vues et que les pools d’adresses VPN sont inclus.

Checklists / plan pas-à-pas

Checklist A : Quand vous voyez NXDOMAIN

Confirmez le FQDN exact interrogé (incluant le point final et le comportement des suffixes de recherche).
Interrogez l’autorité directement pour le type d’enregistrement concerné (A, AAAA, CNAME, SRV).
Vérifiez le split-horizon : interrogez depuis l’intérieur et l’extérieur ; interrogez autorités internes et publiques.
Vérifiez le serial SOA sur chaque NS autoritatif ; confirmez qu’ils correspondent.
Si c’était récemment créé/changé, tenez compte du cache négatif : attendez ou videz les caches que vous contrôlez.
Confirmez que vous n’avez pas publié uniquement un CNAME sans sa cible, ou publié un enregistrement dans la mauvaise zone.
Corrigez à la source de vérité (fichier de zone / fournisseur DNS), pas dans des résolveurs aléatoires.

Checklist B : Quand vous voyez SERVFAIL

Identifiez quel résolveur renvoie SERVFAIL (stub local, récursif d’entreprise, public).
Interrogez le même nom via plusieurs résolveurs pour isoler l’étendue.
Faites dig +trace pour voir où la chaîne casse.
Testez les serveurs autoritatifs individuellement ; cherchez timeouts, REFUSED, ou réponses inconsistantes.
Examinez DNSSEC : comparez DS et DNSKEY, vérifiez les signatures expirées, confirmez la synchronisation temporelle sur signataires et résolveurs.
Testez le comportement UDP et TCP (troncation et fallback). Assurez-vous que TCP/53 n’est pas bloqué.
Consultez les logs du résolveur pour des échecs de validation, timeouts amont, ou avertissements de « lame delegation ».
Mitigation : basculez les clients vers des résolveurs sains, retirez des nœuds anycast cassés, ou désactivez temporairement la validation seulement si le risque est compris.

Plan pas-à-pas : le flux « restaurer le service d’abord, puis corriger la cause »

Stabiliser : si un résolveur échoue, retirez-le de la rotation. Si un autoritatif est cassé, retirez-le de l’ensemble NS (avec précaution) ou réparez-le rapidement.
Confirmer la vérité : interrogez les sources autoritatives directement. Déterminez si l’enregistrement existe et est cohérent sur les NS.
Corriger la justesse : pour NXDOMAIN, corrigez les données de zone. Pour SERVFAIL, réparez la reachabilité/validation/délégation.
Corriger la propagation : assurez-vous que les transferts de zone se terminent, que le serial est incrémenté, et que les caches expirent ou sont vidés.
Prévenir la récurrence : ajoutez des vérifications de délégation, surveillance d’expiration DNSSEC, tests de reachabilité TCP/53, et des canaris depuis plusieurs réseaux.

FAQ

1) NXDOMAIN est-il toujours une réponse autoritaire ?

Non. Il est censé refléter une non-existence autoritaire, mais vous pouvez voir NXDOMAIN depuis des caches récursifs, des politiques RPZ, ou la mauvaise vue DNS. Vérifiez toujours en interrogeant directement les NS autoritatifs.

2) Quelle est la différence entre NXDOMAIN et « pas de réponse » ?

NXDOMAIN signifie que le nom n’existe pas. « Pas de réponse » est généralement NOERROR avec une section answer vide (NODATA) : le nom existe, mais pas ce type d’enregistrement.

3) Pourquoi SERVFAIL arrive-t-il alors que le serveur autoritatif semble correct ?

Parce que les résolveurs valident et appliquent des politiques. Les échecs de validation DNSSEC, le fallback TCP bloqué, ou les timeouts amont peuvent causer SERVFAIL même si l’autorité sert des données.

4) Un pare-feu peut-il provoquer NXDOMAIN ?

Les pare-feux provoquent plus souvent des timeouts ou SERVFAIL, mais ils peuvent indirectement contribuer à NXDOMAIN si votre résolveur bascule sur une vue ou une chaîne de forwarder qui renvoie NXDOMAIN. Considérez cela comme « improbable mais possible », et isolez en interrogeant l’autorité directement.

5) Pourquoi SERVFAIL est-il parfois intermittent ?

Les résolveurs peuvent choisir différents serveurs autoritatifs à chaque fois. Si un NS est inatteignable, lame, ou sert un DNSSEC cassé, certains chemins réussiront et d’autres échoueront. C’est pourquoi les interrogations directes par NS sont indispensables.

6) Comment savoir si DNSSEC est le problème sans devenir cryptographe ?

Faites un test comparatif : interrogez un résolveur validant et un résolveur non-validant que vous contrôlez, puis utilisez dig +trace +dnssec. Les logs du résolveur indiquent souvent la cause (signatures expirées, mismatch DS).

7) Dois-je désactiver la validation DNSSEC pour « réparer SERVFAIL » ?

Uniquement comme mitigation temporaire, explicitement acceptée et uniquement si vous contrôlez la politique du résolveur. La vraie correction est de réparer la chaîne DNSSEC ou les problèmes de transport.

8) Pourquoi passer à TCP résout-il certains problèmes DNS ?

Les réponses volumineuses (surtout avec DNSSEC) ne rentrent pas toujours en UDP. Le DNS utilise la troncation pour signaler « ré-essayer en TCP ». Si la fragmentation UDP ou EDNS est cassée, TCP peut être plus fiable — à condition que TCP/53 soit autorisé.

9) Quel est le moyen le plus rapide de prouver un DNS split-horizon ?

Interrogez le même FQDN contre des résolveurs internes et externes, et comparez. Si le public renvoie NOERROR et l’interne NXDOMAIN (ou des IPs différentes), vous avez un comportement split-horizon volontaire ou accidentel.

10) Comment éviter d’être trompé par des échecs mis en cache ?

Incluez toujours une interrogation directe de l’autorité dans votre workflow. Si l’autorité est correcte et que la récursion est fausse, vous traitez du cache, de la politique, ou de la santé du résolveur — pas d’enregistrements manquants.

Conclusion : quoi faire la prochaine fois

NXDOMAIN et SERVFAIL ne sont pas seulement deux variations d’un « DNS en colère ». Ce sont des panneaux différents.

NXDOMAIN : supposez que le système répond. Vérifiez le nom, la zone, la vue, et les caches.
SERVFAIL : supposez que le résolveur n’a pas pu compléter la résolution en toute sécurité. Enquêtez sur DNSSEC, la santé de la délégation, la reachabilité, et le comportement UDP/TCP.

Actions pratiques à faire cette semaine :

Créez une petite page de runbook commençant par « NXDOMAIN vs SERVFAIL » et incluant les commandes Étapes 1–4 ci-dessus.
Ajoutez une vérification périodique de cohérence de délégation/autorité (interroger chaque NS et comparer les serials SOA).
Ajoutez un canari interrogeant un enregistrement lourd DNSSEC qui valide le fallback TCP de bout en bout.
Apprenez à votre processus d’incident à capturer la sortie dig incluant status, SERVER, et flags. Les captures d’écran ne sont pas de la télémétrie.

Le DNS continuera de casser. Mais il ne vous fera plus perdre autant de temps à être mystérieux à son sujet.