SERVFAIL DNS en amont : prouver que votre fournisseur est en cause

Ce que SERVFAIL signifie réellement (et ce qu’il ne signifie pas)

SERVFAIL est le code de réponse DNS 2. Il est volontairement vague : « le serveur de noms n’a pas pu traiter cette requête à cause d’un problème avec le serveur de noms ». En pratique, pour les résolveurs récursifs, cela signifie souvent : « j’ai tenté la récursion et j’ai rencontré une erreur interne, un blocage par politique, un échec de validation DNSSEC, un délai, ou une défaillance en amont ».

SERVFAIL n’est pas NXDOMAIN

NXDOMAIN est un « n’existe pas » clair. SERVFAIL signifie « quelque chose m’a empêché de trancher ». Traitez-les différemment. NXDOMAIN est une donnée. SERVFAIL est un événement de fiabilité.

SERVFAIL peut être de votre faute, même si ça ressemble à un problème en amont

Si vous forwardez toutes les requêtes vers un résolveur fournisseur et que votre résolveur local est configuré en pur forwarder, vous avez créé un point d’étranglement unique. Quand ce résolveur en amont se comporte mal, votre serveur local renvoie SERVFAIL et vous avez l’impression de perdre la tête. Mais la cause racine peut rester votre choix d’architecture : absence de fallback, manque de diversité, MTU incorrect, trust anchors DNSSEC cassés, ou politique trop stricte.

Nous ne sommes pas là pour philosopher. Nous sommes là pour prouver où se trouve la faute et que faire.

Blague #1 : DNS est le seul système où « c’est en cache » peut signifier « c’est OK », « c’est cassé », ou « c’est cassé mais différemment ».

Playbook de diagnostic rapide (premier/deuxième/troisième)

Premier : décider si c’est local, récursif en amont, ou autoritatif

• Interrogez votre résolveur local (celui que vos hôtes utilisent réellement). S’il renvoie SERVFAIL, continuez.
• Interrogez un résolveur public connu et sain depuis le même hôte. S’il résout, le domaine est probablement sain et votre chemin en amont est suspect.
• Réalisez une trace jusqu’à l’autoritatif (parcours non récursif). Si les serveurs autoritatifs répondent correctement, la récursion/validation en amont est probablement le problème.

Deuxième : différencier échecs DNSSEC, échecs transport, et blocages politiques

• DNSSEC : SERVFAIL sur des résolveurs validants ; fonctionne avec +cd (vérification désactivée) ou depuis des résolveurs non-validants.
• Transport/MTU/fragmentation : réponses UDP tronquées ou perdues ; fallback TCP échoue ; comportement intermittent selon le chemin réseau.
• Politique/RPZ/filtrage : SERVFAIL/NXDOMAIN constants uniquement sur les résolveurs du fournisseur ; d’autres résolveurs réussissent ; parfois le fournisseur admet un « filtrage de sécurité ».

Troisième : capturer la preuve avec horodatages, IP des résolveurs et traces de paquets

• Consignez l’IP exacte du résolveur qui a renvoyé SERVFAIL, les horodatages, le nom/type de requête, et si TCP a été tenté.
• Collectez des sorties dig avec +stats et +dnssec.
• Lancez un court tcpdump ciblé pour montrer les réponses en amont (ou leur absence).

Si vous ne faites qu’une seule chose de cet article : prouvez que la chaîne autoritative répond correctement, et montrez que seuls les résolveurs récursifs de votre fournisseur échouent. Cela transforme le « peut-être » en « ticket ».

Faits et historique importants en cas d’incident réel

1. Le DNS a précédé le web. Il a été conçu au début des années 1980 comme une base de données distribuée pour remplacer HOSTS.TXT ; les hypothèses de fiabilité étaient… optimistes.
2. Le RCODE 2 (SERVFAIL) a toujours été vague par conception. Le protocole ne voulait pas divulguer des détails internes, ce qui est bien pour la simplicité et mauvais pour l’investigation d’incident.
3. EDNS0 (1999) a changé les modes d’échec. Des paquets UDP plus grands ont réduit l’usage du TCP, mais ont introduit des problèmes de fragmentation/MTU qui causent encore des comportements « aléatoires » de SERVFAIL/timeout.
4. DNSSEC (années 2000) a fait de l’intégrité des données une priorité. Il a aussi fait en sorte que des domaines « parfaitement atteignables » échouent la validation quand les signatures, les enregistrements DS ou les horloges sont incorrects.
5. La mise en cache négative est devenue un comportement standardisé. La mise en cache de NXDOMAIN et d’autres réponses négatives améliore les performances mais peut prolonger la douleur après une correction si les TTL sont élevés.
6. Les résolveurs anycast ont changé le débogage. « 8.8.8.8 » n’est pas une seule machine ; les résolveurs fournisseurs sont souvent anycast aussi, donc le comportement peut varier selon la géographie et le moment.
7. Les enregistrements glue sont une source récurrente d’incidents. Les délégations qui reposent sur du glue peuvent casser de manière subtile lorsque les bureaux d’enregistrement/parents sont mal mis à jour.
8. Le fallback TCP pour le DNS n’est pas optionnel en pratique. Les pare-feu qui bloquent le DNS sur TCP créent des échecs qui ressemblent à des SERVFAIL en amont.
9. Les résolveurs implémentent des couches de politique. RPZ, blocage de malwares, « filtres familiaux » et politiques d’entreprise peuvent transformer une requête normale en SERVFAIL ou NXDOMAIN — volontairement.

Modèle mental : stub → récursif → autoritatif

La plupart des incidents deviennent confus parce que les gens ne s’accordent pas sur ce que « serveur DNS » signifie. Vous avez besoin d’un modèle mental clair :

• Stub resolver : la bibliothèque client sur votre hôte (souvent via systemd-resolved), qui demande à quelqu’un d’autre de faire la récursion.
• Résolveur récursif : votre serveur de cache/validation (Unbound, BIND, Knot Resolver) ou le résolveur managé de votre fournisseur, réalisant la récursion et la mise en cache des résultats.
• Serveurs autoritatifs : les serveurs pour le domaine, répondant depuis les données de zone (souvent derrière des fournisseurs DNS, des load balancers et de l’anycast).
• Zone parente : délégation et enregistrements DS situés au-dessus (.com, .net, etc.). Beaucoup de « problèmes autoritatifs » sont en réalité des problèmes parent/registrar.

« SERVFAIL depuis l’amont » signifie généralement : votre stub a interrogé votre récursif, et votre récursif a interrogé son forwarder en amont. Ce forwarder en amont a renvoyé SERVFAIL ou a expiré. Votre récursif a alors renvoyé SERVFAIL au stub. L’astuce est de prouver exactement quel saut a échoué et pourquoi.

Une idée paraphrasée souvent attribuée à un leader des opérations : « L’espoir n’est pas une stratégie ; mesurez et vérifiez. » (idée paraphrasée, Gene Kim)

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

Ces tâches sont conçues pour construire une chaîne de preuves. Exécutez-les depuis : (1) un hôte affecté, (2) un hôte dans un segment réseau différent, et idéalement (3) un petit VM propre en dehors de votre fournisseur.

Tâche 1 : identifier quel résolveur l’hôte utilise réellement

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.0.0.53
       DNS Servers: 10.0.0.53 10.0.0.54

Ce que cela signifie : Votre hôte envoie le DNS vers 10.0.0.53/10.0.0.54. Ce sont vos premiers suspects, pas « Internet ».

Décision : Tous les tests suivants doivent interroger explicitement ces résolveurs. Si vous sautez cette étape, vous « prouverez » la mauvaise chose.

Tâche 2 : reproduire le SERVFAIL contre le résolveur utilisé

cr0x@server:~$ dig @10.0.0.53 www.example.com A +norecurse

; <<>> DiG 9.18.24 <<>> @10.0.0.53 www.example.com A +norecurse
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 41277
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; QUERY SECTION:
;www.example.com.                IN      A

;; Query time: 58 msec
;; SERVER: 10.0.0.53#53(10.0.0.53) (UDP)
;; WHEN: Tue Dec 31 12:04:55 UTC 2025
;; MSG SIZE  rcvd: 40

Ce que cela signifie : Le résolveur a renvoyé SERVFAIL rapidement (58 ms). Ce n’est pas un timeout générique ; c’est une voie d’échec active.

Décision : Testez maintenant le même nom contre plusieurs autres résolveurs pour isoler la portée.

Tâche 3 : comparer avec un résolveur public sain depuis le même hôte

cr0x@server:~$ dig @1.1.1.1 www.example.com A +stats

; <<>> DiG 9.18.24 <<>> @1.1.1.1 www.example.com A +stats
; (1 server found)
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 5013
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; ANSWER SECTION:
www.example.com.         300     IN      A       93.184.216.34

;; Query time: 14 msec
;; SERVER: 1.1.1.1#53(1.1.1.1) (UDP)
;; WHEN: Tue Dec 31 12:05:08 UTC 2025
;; MSG SIZE  rcvd: 60

Ce que cela signifie : Le domaine se résout correctement ailleurs. Cela écarte une panne autoritative et pointe vers le chemin récursif/comportement du fournisseur.

Décision : Commencez à construire la preuve « seuls ces IP résolveurs échouent ».

Tâche 4 : vérifier si c’est lié à DNSSEC (le piège classique SERVFAIL)

cr0x@server:~$ dig @10.0.0.53 www.example.com A +dnssec +multi

; <<>> DiG 9.18.24 <<>> @10.0.0.53 www.example.com A +dnssec +multi
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 60172
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

Ce que cela signifie : Toujours SERVFAIL. Pas encore concluant.

Décision : Essayez +cd (checking disabled). Si cela fonctionne, vous avez probablement une défaillance de validation DNSSEC dans le chemin du résolveur en amont.

Tâche 5 : interroger avec la vérification désactivée pour isoler les échecs de validation

cr0x@server:~$ dig @10.0.0.53 www.example.com A +cd +stats

; <<>> DiG 9.18.24 <<>> @10.0.0.53 www.example.com A +cd +stats
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 28212
;; flags: qr rd ra cd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; ANSWER SECTION:
www.example.com.         300     IN      A       93.184.216.34

;; Query time: 31 msec
;; SERVER: 10.0.0.53#53(10.0.0.53) (UDP)
;; WHEN: Tue Dec 31 12:06:01 UTC 2025
;; MSG SIZE  rcvd: 60

Ce que cela signifie : Avec la vérification DNSSEC désactivée, cela se résout. Cela suggère fortement une défaillance de validation DNSSEC dans le chemin du résolveur (trust anchor, mauvais DS, signatures expirées, dérive d’horloge, ou bug en amont).

Décision : Rassemblez la chaîne DNSSEC et vérifiez les logs du résolveur ; préparez-vous à dire au fournisseur « valider incorrectement » plutôt que « DNS en panne ».

Tâche 6 : parcourir la chaîne de délégation avec trace (preuve du chemin autoritatif)

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

; <<>> DiG 9.18.24 <<>> +trace www.example.com A
.                       518400  IN      NS      a.root-servers.net.
...
com.                    172800  IN      NS      a.gtld-servers.net.
...
example.com.            172800  IN      NS      a.iana-servers.net.
example.com.            172800  IN      NS      b.iana-servers.net.
www.example.com.        300     IN      A       93.184.216.34

Ce que cela signifie : Vous pouvez atteindre la chaîne autoritative et obtenir un enregistrement A. C’est votre reçu « l’autoritatif est OK ».

Décision : Si la trace fonctionne de manière fiable pendant que le résolveur du fournisseur renvoie SERVFAIL, vous avez un solide dossier contre le résolveur en amont.

Tâche 7 : confirmer que c’est bien le résolveur du fournisseur qui échoue (interrogez-le directement)

cr0x@server:~$ dig @203.0.113.53 www.example.com A +stats

; <<>> DiG 9.18.24 <<>> @203.0.113.53 www.example.com A +stats
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 1400
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; Query time: 22 msec
;; SERVER: 203.0.113.53#53(203.0.113.53) (UDP)
;; WHEN: Tue Dec 31 12:06:44 UTC 2025
;; MSG SIZE  rcvd: 40

Ce que cela signifie : Une IP de résolveur récursif en amont spécifique a renvoyé SERVFAIL rapidement. C’est de l’or pour l’escalade : précis et reproductible.

Décision : Répétez contre les résolveurs secondaires du fournisseur. Si un seul échoue, vous avez probablement touché un POP anycast ou une panne partielle.

Tâche 8 : vérifier si le fallback TCP fonctionne (suspect de fragmentation/MTU)

cr0x@server:~$ dig @203.0.113.53 www.example.com DNSKEY +tcp +dnssec +stats

; <<>> DiG 9.18.24 <<>> @203.0.113.53 www.example.com DNSKEY +tcp +dnssec +stats
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 32999
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
;; Query time: 35 msec
;; SERVER: 203.0.113.53#53(203.0.113.53) (TCP)
;; WHEN: Tue Dec 31 12:07:18 UTC 2025
;; MSG SIZE  rcvd: 1102

Ce que cela signifie : Le TCP fonctionne et renvoie DNSKEY. Si les requêtes UDP donnent SERVFAIL mais que le TCP réussit, vous avez peut-être des problèmes de chemin UDP, de perte de fragments, ou de pare-feu bizarre.

Décision : Si le TCP fonctionne mais pas l’UDP, concentrez-vous sur MTU/EDNS0 et le filtrage réseau plutôt que « le serveur DNS est hors service ».

Tâche 9 : forcer un petit buffer EDNS0 pour éviter la fragmentation

cr0x@server:~$ dig @203.0.113.53 www.example.com A +bufsize=1232 +stats

; <<>> DiG 9.18.24 <<>> @203.0.113.53 www.example.com A +bufsize=1232 +stats
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 49811
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; ANSWER SECTION:
www.example.com.         300     IN      A       93.184.216.34

;; Query time: 20 msec
;; SERVER: 203.0.113.53#53(203.0.113.53) (UDP)
;; WHEN: Tue Dec 31 12:07:47 UTC 2025
;; MSG SIZE  rcvd: 60

Ce que cela signifie : Avec une taille de buffer conservative, cela réussit. Cela implique des problèmes de fragmentation/PMTUD entre vous et le résolveur ou entre le résolveur et les serveurs autoritatifs.

Décision : Votre fournisseur peut être correct mais le chemin réseau (éventuellement leur edge) laisse tomber les fragments. C’est toujours leur problème, mais maintenant vous pouvez le décrire en paquets, pas en sentiments.

Tâche 10 : inspecter la configuration de votre résolveur cache/forwarder (exemple Unbound)

cr0x@server:~$ sudo unbound-control status
version: 1.19.0
verbosity: 1
threads: 2
modules: 2 [ subnetcache validator ]
uptime: 38122 seconds
options: control(ssl)
unbound (pid 1221) is running...

Ce que cela signifie : Unbound effectue la validation (module validator chargé). Si l’amont échoue seulement sur les requêtes validantes, cela compte.

Décision : Si vous forwardez vers un résolveur validant tout en validant localement, ne le faites pas. Choisissez un seul point de validation et rendez-le prévisible.

Tâche 11 : vérifier les logs du résolveur pour les échecs de validation (systemd-journald)

cr0x@server:~$ sudo journalctl -u unbound --since "10 min ago" | tail -n 8
Dec 31 12:05:59 server unbound[1221]: info: validation failure <www.example.com. A>: signature expired
Dec 31 12:06:00 server unbound[1221]: info: error: SERVFAIL <www.example.com. A>: validation failure

Ce que cela signifie : C’est explicite : signatures expirées (ou apparaissant comme expirées). Cela peut être réel ou dû à une dérive d’horloge.

Décision : Vérifiez immédiatement l’heure système et la santé NTP sur le résolveur. Si l’heure est correcte, cela devient un problème DNSSEC côté fournisseur ou domaine.

Tâche 12 : vérifier la synchronisation temporelle (DNSSEC y tient beaucoup)

cr0x@server:~$ timedatectl
               Local time: Tue 2025-12-31 12:08:21 UTC
           Universal time: Tue 2025-12-31 12:08:21 UTC
                 RTC time: Tue 2025-12-31 12:08:21
                Time zone: Etc/UTC (UTC, +0000)
System clock synchronized: yes
              NTP service: active
          RTC in local TZ: no

Ce que cela signifie : L’horloge est synchronisée. Bien. Une erreur de moins à se reprocher.

Décision : Si les échecs DNSSEC persistent avec l’heure correcte, la défaillance est en amont ou dans la chaîne de signatures/DS du domaine.

Tâche 13 : vérifier si le TCP/53 est bloqué (localement ou par une politique réseau)

cr0x@server:~$ nc -vz 203.0.113.53 53
Connection to 203.0.113.53 53 port [tcp/domain] succeeded!

Ce que cela signifie : TCP/53 est joignable. S’il échouait, vous vous attendriez à ce que la troncature UDP devienne SERVFAIL/timeouts sur des réponses plus grandes.

Décision : Si TCP/53 est bloqué, corrigez cela avant d’accuser qui que ce soit. Si vous ne pouvez pas, vous devez réduire agressivement la taille EDNS0.

Tâche 14 : capture de paquets pour prouver le comportement en amont

cr0x@server:~$ sudo tcpdump -ni eth0 host 203.0.113.53 and port 53 -vv -c 6
tcpdump: listening on eth0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
12:09:01.120001 IP 10.0.1.20.53422 > 203.0.113.53.53: 41277+ A? www.example.com. (33)
12:09:01.141883 IP 203.0.113.53.53 > 10.0.1.20.53422: 41277 ServFail 0/0/1 (40)
12:09:02.001220 IP 10.0.1.20.39511 > 203.0.113.53.53: 5013+ A? www.example.com. (33)
12:09:02.015430 IP 203.0.113.53.53 > 10.0.1.20.39511: 5013 1/0/1 A 93.184.216.34 (60)
6 packets captured
6 packets received by filter
0 packets dropped by kernel

Ce que cela signifie : Vous avez un enregistrement horodaté, sur le lien, montrant que le résolveur du fournisseur émet parfois SERVFAIL et parfois réussit. Si le comportement est intermittent, c’est ainsi que vous prouvez que c’est réel.

Décision : Si le SERVFAIL arrive rapidement depuis l’amont, ce n’est pas votre pare-feu qui bloque les réponses. S’il n’y a pas de réponse, pivotez vers la vérification de la connectivité/perte de paquets/problèmes de chemin anycast.

Tâche 15 : tester plusieurs chemins anycast en interrogeant depuis un autre namespace réseau ou hôte

cr0x@server:~$ dig @203.0.113.53 www.example.com A +stats
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 21001
;; Query time: 19 msec
;; SERVER: 203.0.113.53#53(203.0.113.53) (UDP)

cr0x@server:~$ ssh cr0x@bastion 'dig @203.0.113.53 www.example.com A +stats'
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 10442
;; Query time: 12 msec
;; SERVER: 203.0.113.53#53(203.0.113.53) (UDP)

Ce que cela signifie : Même IP de résolveur, point de vue différent, résultat différent. C’est l’inconsistance classique d’un POP anycast ou du filtrage régional.

Décision : Votre escalade doit inclure « échoue depuis ASN/lieu A, réussit depuis ASN/lieu B », avec horodatages.

Tâche 16 : confirmer si votre résolveur effectue du forwarding (et vers qui)

cr0x@server:~$ sudo grep -R "forward-addr" /etc/unbound/unbound.conf /etc/unbound/unbound.conf.d 2>/dev/null
/etc/unbound/unbound.conf.d/forward.conf:forward-addr: 203.0.113.53
/etc/unbound/unbound.conf.d/forward.conf:forward-addr: 203.0.113.54

Ce que cela signifie : Votre récursion est externalisée. Ce n’est pas forcément mauvais, mais maintenant le résolveur du fournisseur est une dépendance que vous devez traiter comme telle.

Décision : Si le fournisseur est instable et que vous ne pouvez pas les faire corriger rapidement, basculez vers la récursion complète locale ou diversifiez les forwarders (avec précaution).

Comment construire une preuve exploitable par le fournisseur (sans drame)

Les fournisseurs ne sont pas maléfiques. Ils sont occupés. Leur première réponse est souvent « ça marche pour nous ». Votre travail est de rendre cette réponse impossible.

À quoi ressemble une « preuve » pour une équipe opérations DNS

• IP exacte du résolveur qui renvoie SERVFAIL (pas « votre DNS »).
• Requête exacte : nom, type, bits DO/CD si pertinent, et UDP ou TCP.
• Horodatages avec fuseau et fréquence (« 1/20 requêtes échouent » ou « échoue pendant 7 minutes »).
• Données de comparaison : même requête réussit contre un autre résolveur récursif.
• Sanité du chemin autoritatif : dig +trace fonctionne (ou montre où ça casse).
• Extrait de capture de paquets montrant le code SERVFAIL ou l’absence de réponses.
• Contexte réseau : votre plage IP source/ASN, région, si le NAT est impliqué.

N’envoyez pas un roman ; envoyez un dossier

Une bonne escalade est concise :

• Un paragraphe résumé : ce qui est cassé, impact, quand ça a commencé.
• Une liste à puces des IP résolveurs testées et des résultats.
• Trois sorties de commandes maximum dans le premier message. Joignez le reste si le ticket le permet.
• Un extrait tcpdump ou un pcap si le fournisseur l’accepte.

À éviter

• « Le DNS est en panne. » Non. Nommez le résolveur et la requête.
• « C’est aléatoire. » C’est intermittent. Fournissez un taux d’échec, une fenêtre temporelle, et si cela corrèle avec la taille EDNS0.
• « On a rebooté des trucs. » Ça sent l’approximation, pas la preuve.

Blague #2 : La façon la plus rapide d’obtenir une action d’un fournisseur est de dire « j’ai une capture de paquets », car maintenant c’est leur problème en haute définition.

Trois mini-récits d’entreprise (anonymisés, plausibles techniquement et douloureusement familiers)

Incident causé par une mauvaise hypothèse : « SERVFAIL signifie que l’autoritatif est down »

Une entreprise SaaS de taille moyenne a commencé à recevoir des alertes : les taux d’erreur API ont monté en flèche, et quelques régions signalaient des échecs de connexion. L’on-call voyait SERVFAIL pour le nom d’hôte du fournisseur d’identité et a fait ce que beaucoup font sous stress : supposer que le DNS autoritatif du domaine était cassé.

Ils ont escaladé vers le fournisseur, ouvert un ticket de sévérité et commencé à rédiger une notification client. Le fournisseur a répondu que ses autoritatifs étaient sains et a fourni ses propres logs de requêtes montrant un trafic normal. L’on-call a persisté. « Mais mon dig dit SERVFAIL. »

Un ingénieur plus calme a posé une question basique : « Quel résolveur avez-vous interrogé ? » La réponse était le forwarder de l’entreprise, qui forwardait vers un service récursif managé inclus par leur fournisseur de connectivité. Les requêtes vers un résolveur public fonctionnaient instantanément. dig +trace montrait la délégation et des réponses autoritatives correctes.

La vraie défaillance était la validation DNSSEC dans un POP anycast du résolveur managé. Le résolveur du fournisseur renvoyait rapidement SERVFAIL pour des réponses DNSSEC-valides pendant une fenêtre de rollover de clés. Le forwarder de l’entreprise n’avait pas de diversité ; il forwardait exclusivement vers ce service managé.

Ils ont corrigé l’incident immédiat en changeant temporairement de forwarder et durablement en exécutant la récursion locale dans deux régions avec des upstreams diversifiés. Le postmortem contenait une ligne gênante : « Nous avons escaladé vers la mauvaise partie parce que nous n’avons pas vérifié le chemin autoritatif. » Cette ligne a évité des embarras futurs.

Optimisation qui s’est retournée contre eux : « Forwardons tout pour réduire la latence »

Une société financière avait un cluster Unbound bien réglé effectuant la récursion complète, avec cache et validation DNSSEC. Quelqu’un a remarqué que le cloud proposait des « résolveurs basse-latence » dans le VPC, et a proposé une « optimisation simple » : configurer Unbound pour forwarder toutes les requêtes vers ces résolveurs cloud.

En temps normal, c’était excellent. La latence médiane a chuté. L’utilisation CPU du résolveur a baissé. Tout le monde a applaudi le changement dans une réunion où personne n’a interrogé les modes d’échec.

Trois semaines plus tard, un sous-ensemble de domaines a commencé à renvoyer SERVFAIL de manière intermittente. Pas tous les domaines, pas toutes les requêtes. L’équipe a cherché des fantômes : retries applicatifs, pools de connexions, même TLS. C’était le DNS, mais seulement parfois, et seulement via les résolveurs cloud.

Cause racine : la flotte de résolveurs cloud avait un problème de fragmentation EDNS0 sur un chemin spécifique vers certains serveurs autoritatifs. Les réponses UDP au-delà d’une certaine taille étaient perdues, et le fallback TCP était incohérent à cause d’une appliance de sécurité. La récursion complète sur leurs propres boîtes Unbound gérait mieux cela auparavant car elles utilisaient des paramètres EDNS0 conservateurs et un comportement TCP prévisible.

L’« optimisation » a créé un nouveau rayon d’impact : une dépendance managée qu’ils ne pouvaient pas régler. Ils sont revenus à la récursion complète et ont gardé le résolveur cloud comme forwarder secondaire uniquement pour des zones internes spécifiques. La leçon n’était pas « ne jamais utiliser le DNS managé ». C’était : n’externalisez pas un chemin critique sans pouvoir l’observer et sans fallback.

Pratique ennuyeuse mais correcte qui a sauvé la mise : résolveurs diversifiés + sondes continues

Une plateforme retail avait déjà été brulée par le DNS auparavant. Pas catastrophiquement — juste assez pour devenir coûteux. Ils ont donc mis en place une politique que personne ne trouvait excitante : chaque région aurait deux résolveurs récursifs, chacun capable de récursion complète, chacun avec une connectivité amont indépendante. Les clients auraient deux résolveurs dans resolv.conf, et leur mesh de services utiliserait aussi la diversité de résolveurs.

Ils ont aussi exécuté des sondes continues : chaque minute, depuis chaque région, ils interrogeaient un petit ensemble de noms critiques (leurs propres endpoints d’auth, la passerelle de paiement, et quelques dépendances externes) contre chaque résolveur, journalisant RCODE, latence, et usage TCP.

Un après-midi, une piscine de résolveurs a commencé à renvoyer SERVFAIL pour un domaine de passerelle de paiement, mais seulement dans une région. Parce qu’ils avaient de la télémétrie par résolveur, le problème était évident en quelques minutes : le résolveur A dans cette région était mauvais ; le résolveur B était OK. Les clients ont basculé automatiquement, donc l’impact client a été minimal.

Lorsqu’ils ont ouvert un ticket avec le fournisseur de connectivité, ils n’ont pas dit « le DNS est instable ». Ils ont dit : « L’IP résolveur X renvoie SERVFAIL pour le nom Y à partir de T ; l’IP résolveur Z ne le fait pas. Voici les comptes RCODE minute par minute et un extrait tcpdump. » Le fournisseur a réparé un nœud validant cassé dans ce POP le jour même.

Rien d’héroïque n’est arrivé. C’est pourquoi cela a fonctionné.

Erreurs courantes : symptômes → cause racine → correction

1) Symptôme : SERVFAIL uniquement sur le résolveur du fournisseur ; les résolveurs publics fonctionnent

Cause racine : panne récursive du fournisseur, inconsistence d’un POP anycast, ou politique du fournisseur (filtrage/RPZ).

Correction : Interrogez des IP résolveurs spécifiques directement, collectez des captures tcpdump, et basculez/augmentez les résolveurs à court terme. Escaladez avec l’IP résolveur + horodatages.

2) Symptôme : le SERVFAIL disparaît avec +cd

Cause racine : échec de validation DNSSEC (chaîne DS cassée, signatures expirées, trust anchor incorrect, ou horloge du résolveur).

Correction : Vérifiez la synchronisation temporelle ; lancez dig +trace et inspectez la chaîne DS/DNSKEY ; si le résolveur validant en amont est fautif, escaladez avec « validation échoue sur l’IP résolveur X ; fonctionne ailleurs ».

3) Symptôme : petites réponses fonctionnent ; grandes réponses donnent SERVFAIL/timeout

Cause racine : fragmentation EDNS0/PMTUD ; TCP/53 bloqué ; middleboxes altérant les fragments.

Correction : Testez avec +bufsize=1232 et +tcp. Si cela corrige, ajustez la taille EDNS0 du résolveur, assurez-vous que TCP/53 est autorisé, et escaladez avec des captures de paquets.

4) Symptôme : SERVFAIL intermittent varie selon la région

Cause racine : routage anycast vers différents nœuds résolveurs ; un POP est malade ; état de cache/validation incohérent.

Correction : Testez depuis plusieurs points de vue ; incluez l’IP source/région dans la preuve ; demandez au fournisseur de drainer/réparer le POP.

5) Symptôme : SERVFAIL pour un domaine que vous venez de mettre à jour

Cause racine : délégation/DS cassée pendant un rollover DNSSEC ; mise en cache négative obsolète ; propagation autoritative incohérente.

Correction : Vérifiez dig +trace pour la délégation/DS correcte ; réduisez les TTL avant les changements ; si déjà cassé, coordonnez le correctif avec le registrar/parent et attendez la purge des caches.

6) Symptôme : seulement certains clients échouent ; d’autres réussissent sur le même réseau

Cause racine : résolveurs différents configurés (DHCP), DNS split, VPN poussant des résolveurs, ou différences de stub cache locales.

Correction : Vérifiez la configuration de chaque client (resolvectl), standardisez les options DHCP, et cessez de compter sur « le DNS que l’ordinateur portable a reçu aujourd’hui ».

7) Symptôme : SERVFAIL mais vos logs de résolveur sont vides

Cause racine : vous n’interrogez pas réellement le résolveur que vous croyez ; ou les requêtes sont interceptées par un stub local / sidecar / appareil NAT.

Correction : Utilisez dig @IP explicitement ; capturez les paquets côté client ; confirmez que le trafic atteint l’IP résolveur attendue.

8) Symptôme : SERVFAIL après des changements de « durcissement »

Cause racine : blocage du DNS sur TCP, blocage des fragments, désactivation incorrecte d’EDNS0 ; paramètres DNSSEC trop stricts.

Correction : Réactivez TCP/53 et la possibilité de fragments si besoin ; ajustez la taille EDNS0 ; validez DNSSEC avec des tests contrôlés avant de déployer massivement.

Listes de contrôle / plan étape par étape

Étape par étape : de la première alerte à l’escalade au fournisseur

1. Confirmer la portée de l’impact : est-ce un nom d’hôte, un résolveur, une région ou global ?
2. Identifier le résolveur actif sur un hôte affecté (resolvectl status).
3. Reproduire avec des requêtes explicites : dig @resolver name type +stats.
4. Comparer avec un second résolveur (public ou interne alternatif). Notez les différences de RCODE et de latence.
5. Exécuter dig +trace pour prouver que la chaîne autoritative fonctionne (ou localiser l’échec).
6. Tester l’angle DNSSEC : exécuter avec et sans +cd ; vérifier les logs du résolveur validant ; contrôler la synchronisation temporelle.
7. Tester l’angle transport : +tcp, +bufsize=1232, et vérifier la reachabilité TCP/53.
8. Capturer des paquets montrant SERVFAIL provenant de l’amont ou l’absence de réponses.
9. Documenter la « matrice » de preuves : IP résolveurs × points de vue × résultats.
10. Mitiger : basculer vers des résolveurs alternatifs, activer le fallback, ou désactiver temporairement la validation DNSSEC seulement si vous comprenez le risque et avez l’accord.
11. Escalader : envoyer un résumé court plus les preuves clés, demander une investigation POP/nœud si anycast suspecté.
12. Suivi : continuer à sonder et ajouter une surveillance permanente ; rédiger un postmortem incluant « comment nous détecterons cela en 2 minutes la prochaine fois ».

Checklist de mitigation rapide (quand la production saigne)

• Basculez les clients vers au moins deux résolveurs divers (préférer différents fournisseurs si possible).
• Sur les forwarders, ajoutez plusieurs upstreams et faites des vérifications de santé ; préférez ceux avec des réseaux anycast indépendants.
• Si fragmentation suspectée : réduisez la taille UDP EDNS0 et assurez-vous que TCP/53 est autorisé.
• Si DNSSEC suspecté : vérifiez d’abord le temps ; ne désactivez pas la validation globalement comme premier réflexe.
• Réduisez la dépendance à un seul résolveur récursif : c’est un point de défaillance unique même s’il est anycast et a un SLA élégant.

Checklist du paquet de preuves (à joindre au ticket)

• IPs des résolveurs testées et leurs RCODEs (SERVFAIL vs NOERROR) pour la même requête.
• Horodatages et fuseau horaire.
• Sortie dig +trace montrant les réponses autoritatives.
• Sortie dig montrant la différence avec +cd si DNSSEC suspecté.
• Extrait tcpdump ou pcap montrant la réponse SERVFAIL de l’amont.
• Votre IP source/egress publique et région (surtout si anycast).

FAQ

1) Pourquoi mon résolveur renvoie-t-il SERVFAIL au lieu de timeout ?

Parce que quelque chose en amont a répondu SERVFAIL ou parce que votre résolveur a rencontré une erreur de validation/politique. Un SERVFAIL rapide est souvent une décision intentionnelle, pas une perte de paquets.

2) Si dig +trace fonctionne, le fournisseur peut-il quand même être en faute ?

Oui. +trace contourne la récursion en parcourant la hiérarchie. Si la trace fonctionne mais que le résolveur du fournisseur renvoie SERVFAIL, le résolveur en amont échoue sur la récursion, la mise en cache, la validation, le transport ou la politique.

3) SERVFAIL signifie-t-il toujours un problème DNSSEC ?

Non. DNSSEC est une cause commune, mais il peut aussi s’agir d’une panne en amont, d’un rate limiting, de timeouts vers les autoritatifs, d’un fallback TCP cassé, ou d’interférence par des middleboxes.

4) Que signifie quand +cd fait réussir la requête ?

Cela suggère fortement une défaillance de validation DNSSEC sur le résolveur interrogé. Ce n’est pas la preuve d’un problème de domaine à elle seule — des résolveurs mal configurés et des horloges erronées peuvent aussi en être la cause.

5) Dois-je simplement désactiver la validation DNSSEC pour arrêter l’incident ?

Uniquement comme mitigation limitée dans le temps avec acceptation explicite du risque. Désactiver la validation échange l’intégrité contre la disponibilité. Parfois c’est le bon choix business ; souvent c’est une panique qui devient permanente.

6) Pourquoi seules certaines régions voient SERVFAIL quand les résolveurs sont anycast ?

L’anycast vous route vers un POP proche, et le « proche » peut changer avec les événements de routage. Un POP peut être cassé tandis que d’autres sont sains. Vos preuves doivent inclure des vantage points régionaux.

7) Comment prouver que ce n’est pas notre pare-feu/NAT ?

Si vous capturez des paquets montrant une réponse SERVFAIL en provenance de l’amont, ce n’est pas votre pare-feu qui supprime les réponses. Si vous voyez les requêtes partir sans réponses, vous devez tester TCP vs UDP, la taille EDNS et effectuer des vérifications depuis un autre chemin d’egress.

8) Pourquoi réduire +bufsize à 1232 aide-t-il ?

Cela évite la fragmentation sur des chemins internet courants et suit les recommandations opérationnelles modernes pour DNS sur UDP. Si cela aide, vous avez probablement une perte de fragments ou un problème PMTUD.

9) Les « DNS de sécurité » du fournisseur peuvent-ils causer SERVFAIL ?

Oui. Certaines implémentations de filtrage renvoient NXDOMAIN, d’autres renvoient SERVFAIL, et certaines font des redirections « utiles ». Si les résolveurs publics réussissent et que ceux du fournisseur échouent de manière consistante, suspectez une politique.

10) Que dois-je demander au fournisseur de vérifier ?

Demandez-leur d’investiguer l’IP résolveur/POP spécifique pour des échecs de récursion ou de validation DNSSEC, vérifier les problèmes de fragmentation/fallback TCP, et confirmer si un filtrage/RPZ est appliqué.

Conclusion : étapes pratiques suivantes

SERVFAIL n’est pas un diagnostic. C’est une invitation à poser de meilleures questions. La voie la plus rapide vers la clarté est une comparaison contrôlée : votre résolveur vs un autre, récursion vs trace, validation activée vs désactivée, UDP vs TCP. Ensuite, capturez la preuve.

Étapes suivantes que vous pouvez faire aujourd’hui :

• Notez les IP résolveurs que votre parc utilise réellement. Mettez-les en surveillance.
• Ajoutez un petit ensemble de sondes DNS continues qui enregistrent RCODE, latence et usage TCP par résolveur et par région.
• Assurez-vous que TCP/53 est autorisé là où c’est nécessaire, et réglez EDNS0 de façon conservative si vous exploitez des résolveurs.
• Concevez pour la diversité des résolveurs. Un seul upstream récursif est un point unique de défaillance, même s’il est anycast et a un joli SLA.
• Quand le fournisseur est en faute, escaladez avec un dossier : IP résolveur, requête exacte, horodatages, preuve trace, et paquets. Vous obtiendrez de l’action plutôt que de la poésie.