DNS « bogus/validation failed » : corriger les problèmes DNSSEC en pratique

Ce que « bogus/validation failed » signifie réellement

« Bogus » n’est pas une impression. C’est un verdict. Un résolveur validant dispose d’une preuve cryptographique que la réponse reçue n’est pas ce que le propriétaire de la zone a signé, ou que le résolveur ne parvient pas à construire une chaîne de confiance fiable depuis la racine jusqu’à l’enregistrement demandé.

Cette distinction compte :

• « Insecure » signifie « pas de DNSSEC ici ». Le résolveur renvoie les réponses normalement.
• « Secure » signifie « validé ». Le résolveur renvoie les réponses normalement.
• « Bogus » signifie « validation échouée ». Le résolveur renvoie SERVFAIL parce que renvoyer des données non fiables va à l’encontre du but de DNSSEC.

Les échecs de validation DNSSEC ont quelques causes récurrentes, qui se répartissent en deux catégories :

1. Ruptures de chaîne de confiance : DS erroné/manquant, DNSKEY incompatible, mauvais rollover, algorithme incorrect, mauvais key tag, signatures manquantes, preuve NSEC/NSEC3 incorrecte.
2. Problèmes réels : dérive d’heure, UDP tronqué + fallback TCP cassé, middleboxes altérant EDNS0, résolveurs mal configurés, caches conservant d’anciennes données pendant un rollover.

Approche pratique : traitez-le comme tout autre problème de système distribué. Rassemblez des preuves depuis plusieurs points de vue, identifiez le premier composant qui émet une mauvaise hypothèse, et appliquez la mitigation la plus petite qui restaure le service sans masquer la cause racine pour toujours.

Idée paraphrasée de Werner Vogels (fiabilité et exploitation) : Tout échoue, et c’est votre travail de concevoir et d’opérer comme si c’était normal.

Une chose de plus : les échecs DNSSEC sont embarrassamment binaires. Soit les calculs cryptographiques tiennent, soit non. Il n’y a pas de « signé à moitié », pas de « ça marche sur mon résolveur », et pas de « ça a passé la mise en scène ».

Playbook de diagnostic rapide

Voici l’ordre qui vous amène le plus vite au goulot réel, avec un minimum d’agitation. Respectez-le. Errer au hasard dans les résolveurs à 3 h du matin est la façon dont vous vous retrouvez à déboguer le Wi‑Fi de votre propre laptop.

1) Confirmer que c’est lié à DNSSEC (et non une panne DNS générale)

• Interrogez un résolveur validant connu et un résolveur non-validant connu.
• Si le domaine fonctionne sans validation mais échoue avec validation, vous êtes en terrain DNSSEC.

2) Identifier où la chaîne de confiance casse

• Vérifiez le DS dans la zone parente.
• Vérifiez le DNSKEY dans la zone enfant.
• Vérifiez que les RRSIG existent et sont dans des fenêtres de validité.

3) Écarter rapidement les « problèmes de réalité »

• Synchronisation horaire des résolveurs (timedatectl), MTU/fragmentation, troncation UDP, problèmes EDNS0.
• Assurez-vous que votre résolveur n’est pas bloqué sur des trust anchors obsolètes ou ne met pas en cache d’anciens ensembles DNSKEY.

4) Appliquer une mitigation sûre pendant que vous corrigez en amont

• Si vous exploitez des résolveurs validants pour des utilisateurs : utilisez une Negative Trust Anchor (NTA) pour la zone affectée afin de restaurer temporairement la disponibilité.
• Si vous êtes le propriétaire de la zone : corrigez DS/DNSKEY et les signatures correctement ; ne « désactivez pas DNSSEC » à la légère à moins de pouvoir retirer proprement le DS d’abord.

Règle de décision : Si vous ne pouvez pas corriger la cause racine en moins de 30 minutes et que l’impact client est élevé, atténuez. Puis corrigez proprement.

Faits et historique utiles en cas d’incident

1. DNSSEC a été spécifié à la fin des années 1990, mais son déploiement large a pris des années car la complexité opérationnelle l’a emporté sur la cryptographie dans la vraie vie.
2. La zone racine a été signée en 2010, ce qui a rendu la validation de bout en bout pratique à grande échelle — avant cela, on devait assembler des trust anchors manuellement.
3. Les enregistrements DS vivent dans la zone parente (comme .com), ce qui signifie que votre registrar fait partie de votre périmètre de sécurité que vous le vouliez ou non.
4. Les rollovers de clés sont le premier motif d’erreurs humaines en DNSSEC : minutage, cache et « quelle clé signe quoi » importent tous.
5. L’agilité d’algorithme est réelle : les anciens algorithmes (comme RSA/SHA-1) sont devenus indésirables ; migrer d’algorithme peut casser des validateurs si c’est fait négligemment.
6. NSEC3 existe principalement pour limiter le zone walking ; il ajoute aussi de la complexité et ses propres modes de défaillance (mauvaises salt/itérations aggravent les pannes).
7. EDNS0 a permis des réponses DNS UDP plus grandes ; il a aussi introduit la classe de problèmes « les middleboxes cassent le DNS » qui se manifestent comme des échecs DNSSEC.
8. Il y a eu un KSK rollover majeur de la racine (2018), qui a montré combien de résolveurs étaient mal configurés ou obsolètes — une leçon d’hygiène opérationnelle.
9. Certaines implémentations ferment par principe : quand la validation échoue, elles préfèrent la panne à un risque de cache poisoning. C’est le but, mais cela change votre playbook d’incident.

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

Ci‑dessous, des tâches pratiques à exécuter pendant un incident. Chaque tâche inclut une commande, la forme de sortie attendue, ce que cela signifie, et la décision à prendre.

Task 1 — Voir le symptôme utilisateur : SERVFAIL vs NOERROR

cr0x@server:~$ dig +noall +comments +answer www.example.com A
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 12014

Signification : Le résolveur n’a pas pu produire une réponse qu’il approuve. Ce n’est pas forcément NXDOMAIN ; probablement validation DNSSEC, timeout amont ou échec de récursion.

Décision : Comparez immédiatement avec un autre résolveur et avec un comportement sans DNSSEC pour confirmer que c’est de la validation.

Task 2 — Comparer résolveurs validants vs non‑validants

cr0x@server:~$ dig +noall +answer www.example.com A @8.8.8.8
www.example.com. 300 IN A 93.184.216.34
cr0x@server:~$ dig +noall +comments +answer www.example.com A @9.9.9.9
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 5112

Signification : Différents résolveurs, résultats différents. Cela indique souvent des différences de validation DNSSEC, d’état de cache, ou des problèmes de transport.

Décision : Passez aux requêtes spécifiques DNSSEC (+dnssec, delv) et vérifiez la chaîne DS/DNSKEY.

Task 3 — Demander les enregistrements DNSSEC et chercher le bit AD

cr0x@server:~$ dig +dnssec www.example.com A @1.1.1.1
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; ANSWER SECTION:
www.example.com. 300 IN A 93.184.216.34
www.example.com. 300 IN RRSIG A 13 3 300 20260101000000 20251201000000 12345 example.com. ...

Signification : ad indique que le résolveur a validé la réponse. Si vous ne voyez jamais ad depuis un résolveur sensé valider, il se peut qu’il ne valide pas ou qu’il ne puisse pas valider.

Décision : Si votre propre résolveur n’envoie pas AD alors que des résolveurs publics le font, déboguez la configuration du résolveur / les trust anchors d’abord.

Task 4 — Utiliser delv pour obtenir l’explication du validateur

cr0x@server:~$ delv www.example.com A
; fully validated
www.example.com. 300 IN A 93.184.216.34

Signification : delv effectue la validation DNSSEC et tend à indiquer ce qui a échoué.

Décision : Si delv dit « fully validated » mais que votre résolveur de production dit bogus, suspectez l’état de cache, la dérive horaire ou des problèmes logiciels du résolveur.

Task 5 — Capturer une vraie raison d’échec DNSSEC depuis delv

cr0x@server:~$ delv broken.example A
; validation failed: no valid signature found
; resolution failed: DNSSEC validation failure

Signification : La zone a répondu, mais les signatures n’ont pas validé contre le DNSKEY, ou le RRSIG adéquat est manquant/expiré.

Décision : Inspectez l’ensemble DNSKEY et les fenêtres de validité des RRSIG ; vérifiez un mauvais rollover ou une panne du processus de signature.

Task 6 — Inspecter le DS chez le parent (point de contrôle de la chaîne)

cr0x@server:~$ dig +noall +answer example.com DS @a.gtld-servers.net
example.com. 86400 IN DS 12345 13 2 8B4F...A1C9

Signification : Le parent publie un DS pointant vers un DNSKEY enfant (par key tag, algorithme, digest).

Décision : Si un DS existe mais que le DNSKEY enfant ne correspond pas, vous aurez du bogus. Corrigez le DS (chez le registrar/parent) ou corrigez les clés de l’enfant pour correspondre au DS.

Task 7 — Inspecter le DNSKEY dans la zone enfant

cr0x@server:~$ dig +noall +answer example.com DNSKEY @ns1.example.net
example.com. 3600 IN DNSKEY 257 3 13 AwEAAbc...KSK...
example.com. 3600 IN DNSKEY 256 3 13 AwEAAc9...ZSK...

Signification : Vous devriez voir au moins un KSK (flag 257) et un ZSK (256) pour les configurations typiques. Les algorithmes doivent correspondre au DS.

Décision : Si les DNSKEY ont changé récemment, vérifiez si le DS a été mis à jour (rollover KSK) et si des caches pourraient encore détenir l’ancien DS/DNSKEY.

Task 8 — Vérifier le timing des RRSIG (les signatures expirées sont classiques)

cr0x@server:~$ dig +dnssec +noall +answer example.com SOA @ns1.example.net
example.com. 3600 IN SOA ns1.example.net. hostmaster.example.com. 2025123101 7200 3600 1209600 3600
example.com. 3600 IN RRSIG SOA 13 2 3600 20251231120000 20251201000000 12345 example.com. ...

Signification : RRSIG a des temps d’inception et d’expiration. Si votre pipeline de signature a été cassé, les expirations arrivent et les validateurs commencent à échouer.

Décision : Si expiré/proche de l’expiration, corrigez l’automatisation de signature immédiatement et re-signez la zone. Si les temps semblent « dans le futur », vérifiez la dérive d’horloge sur les serveurs autoritaires ou le signateur.

Task 9 — Vérifier l’heure de votre résolveur (oui, encore)

cr0x@server:~$ timedatectl
               Local time: Wed 2025-12-31 02:21:10 UTC
           Universal time: Wed 2025-12-31 02:21:10 UTC
                 RTC time: Wed 2025-12-31 02:21:10
                Time zone: Etc/UTC (UTC, +0000)
System clock synchronized: yes
              NTP service: active

Signification : DNSSEC dépend des fenêtres temporelles de validité. Si votre résolveur croit que l’heure est la semaine dernière, les signatures paraîtront « pas encore valides » ou « expirées ».

Décision : Si la synchronisation de l’horloge est défaillante, corrigez NTP/chrony avant de toucher la configuration DNSSEC. Ne « déboguez pas la crypto » avec une horloge cassée.

Task 10 — Lire les logs d’Unbound pour la raison spécifique

cr0x@server:~$ sudo journalctl -u unbound --since "10 min ago" | tail -n 20
... unbound[1123]: info: validation failure <example.com. A IN>: no keys have a DS with algorithm 13
... unbound[1123]: info: resolving example.com. A
... unbound[1123]: info: error: SERVFAIL example.com. A IN

Signification : Cette ligne est de l’or : elle vous dit que le résolveur attendait une relation DS/algorithme qui n’existe pas.

Décision : Vérifiez l’algorithme du DS chez le parent et l’algorithme des DNSKEY chez l’enfant. C’est souvent un rollover d’algorithme raté ou un DS obsolète.

Task 11 — Lire les logs de BIND named pour « bogus » et les IDs de clé

cr0x@server:~$ sudo journalctl -u named --since "10 min ago" | tail -n 30
... named[905]: validating example.com/A: no valid signature found
... named[905]: resolving example.com/A: got insecure response; treating as bogus

Signification : BIND donne un récit similaire. « No valid signature found » signifie souvent RRSIG manquant/expiré ou jeu de DNSKEY erroné.

Décision : Confirmez la présence et la validité des RRSIG depuis les serveurs autoritaires directement. Si elles manquent, corrigez la signature. Si elles sont présentes, cherchez une incompatibilité entre le DNSKEY publié et le signataire indiqué par la RRSIG.

Task 12 — Interroger directement les serveurs autoritaires (bypasser la récursion)

cr0x@server:~$ dig +norecurse +dnssec example.com DNSKEY @ns1.example.net
;; flags: qr aa; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; ANSWER SECTION:
example.com. 3600 IN DNSKEY 257 3 13 AwEAAbc...KSK...
example.com. 3600 IN RRSIG DNSKEY 13 2 3600 20251231120000 20251201000000 12345 example.com. ...

Signification : aa confirme que le serveur est autoritaire et a retourné des DNSKEY signés. Si l’autoritaire manque de RRSIG/DNSKEY, vous avez un problème de signature ou de publication.

Décision : Si les données autoritatives sont erronées, corrigez à la source. Si l’autoritatif est correct mais que les validateurs échouent, examinez le DS chez le parent ou des problèmes de transport/middlebox.

Task 13 — Vérifier la troncation et les problèmes de fallback TCP

cr0x@server:~$ dig +dnssec +noall +comments example.com DNSKEY @ns1.example.net +bufsize=512
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 39011
;; flags: qr aa tc; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

Signification : tc signifie réponse UDP tronquée. Un résolveur devrait retenter en TCP. Si le TCP est bloqué, la validation peut échouer de façon mystérieuse.

Décision : Assurez la connectivité TCP/53 vers les serveurs autoritaires et depuis les résolveurs. Si vous voyez souvent tc, pensez au dimensionnement des réponses (moins de clés, hygiène de rollover) et aux chemins MTU.

Task 14 — Confirmer la connectivité TCP/53 quand l’UDP tronque

cr0x@server:~$ dig +tcp +dnssec +noall +answer example.com DNSKEY @ns1.example.net
example.com. 3600 IN DNSKEY 257 3 13 AwEAAbc...KSK...
example.com. 3600 IN DNSKEY 256 3 13 AwEAAc9...ZSK...

Signification : Si le TCP fonctionne alors que l’UDP tronque, votre réseau doit autoriser le fallback TCP. Certains dispositifs « de sécurité » cassent cela et appellent ça une fonctionnalité.

Décision : Si le TCP est bloqué, corrigez la politique de pare‑feu. Ne désactivez pas DNSSEC pour accommoder un middlebox défaillant.

Task 15 — Utiliser une Negative Trust Anchor (NTA) dans Unbound pour atténuer

cr0x@server:~$ sudo unbound-control status
version: 1.17.1
verbosity: 1
threads: 2
modules: 2 [ subnetcache validator iterator ]
uptime: 86400 seconds
options: control(ssl)
cr0x@server:~$ sudo unbound-control neg_anchor_add example.com
ok
cr0x@server:~$ sudo unbound-control list_neg_anchors
example.com

Signification : Vous avez indiqué au validateur de traiter cette zone comme insecure temporairement, contournant ainsi les échecs de validation DNSSEC pour elle.

Décision : N’utilisez ceci que comme mitigation limitée dans le temps. Créez un ticket pour retirer la NTA une fois que l’amont a corrigé DS/DNSKEY/signatures. Ajoutez un monitoring pour éviter qu’elle ne reste en place indéfiniment.

Task 16 — Vider le cache du résolveur après les corrections amont (avec prudence)

cr0x@server:~$ sudo unbound-control flush_zone example.com
ok

Signification : D’anciens DNSKEY/DS/entrées négatives en cache peuvent vous maintenir en panne après que l’amont soit corrigé.

Décision : VideZ uniquement la zone affectée quand c’est possible. Un flush complet du cache en heures de pointe est une auto-DDoS contre vos upstreams.

Blague #1 : Les pannes DNSSEC sont excellentes pour la cohésion d’équipe — vous regarderez tous les mêmes chaînes hexadécimales ensemble, en vous demandant en silence quelles décisions de vie vous ont menés là.

Trois mini-récits d’entreprises du terrain

Mini-récit 1 : L’incident causé par une mauvaise hypothèse

L’entreprise avait une mentalité « frontière de responsabilité » propre : l’équipe appli s’occupe de l’appli, l’équipe plateforme s’occupe de Kubernetes, l’équipe réseau gère le DNS. Le domaine était géré par le marketing via un compte registrar dans lequel aucun ingénieur ne s’était jamais connecté. Ça semblait correct parce que le DNS autoritatif était hébergé par un fournisseur réputé et que « DNSSEC est activé ».

Puis un job de renouvellement de certificat a commencé à échouer. Pas parce que l’ACME était down, mais parce que le worker de renouvellement ne pouvait pas résoudre de manière fiable le endpoint API du fournisseur DNS. Parfois ça fonctionnait depuis des laptops, parfois pas depuis la production. Le canal d’incident s’est rempli des suspects habituels : NAT gateways, pare‑feux egress, résolveur VPC, « peut‑être IPv6 ».

L’hypothèse erronée était subtile : « Si le fournisseur DNS est sain, DNSSEC doit l’être aussi. » En réalité, le DS chez le parent avait été changé lors d’un workflow de « sécurité » du registrar. Personne ne l’a remarqué parce que le DNS autoritatif continuait de servir les enregistrements normalement, et les résolveurs non‑validants continuaient de résoudre normalement. Seuls les résolveurs validants ont commencé à renvoyer SERVFAIL.

Ils l’ont prouvé en interrogeant le DS depuis les serveurs TLD et en le comparant avec l’ensemble DNSKEY. Le DS pointait vers un key tag qui n’existait plus. La zone était signée, le fournisseur fonctionnait, mais la chaîne de confiance était rompue un niveau plus haut — chez le registrar. La correction n’a pas été héroïque. Il a fallu se connecter au registrar, corriger le DS pour qu’il corresponde au KSK courant, et attendre la stabilisation des caches.

La leçon réelle : si vous ne contrôlez pas votre registrar et votre workflow DS comme une infrastructure de production, vous ne contrôlez pas DNSSEC. Vous avez un modèle de sécurité basé sur l’espoir.

Mini-récit 2 : L’optimisation qui s’est retournée contre eux

Une équipe plateforme voulait réduire la latence DNS et la dépendance externe. Raisonnable. Ils ont déployé des résolveurs validants locaux sur chaque pool de nœuds et forcé les pods à les utiliser. Ils ont aussi resserré les règles de pare‑feu, car « pourquoi le DNS aurait besoin de TCP ? » Dans leur modèle de menace, TCP/53 semblait suspect.

Quelques mois plus tard, un domaine partenaire a roulé ses clés et a brièvement servi une réponse DNSKEY plus volumineuse. En UDP elle tronquait fréquemment. Les résolveurs locaux ont tenté de retenter en TCP. Le pare‑feu bloquait. La validation échouait de manière intermittente, et parce que les résolveurs étaient locaux, le rayon d’impact était énorme : toutes les charges sur ce pool de nœuds voyaient des échecs sporadiques pour atteindre l’API du partenaire.

L’on‑call a passé des heures à traquer une « instabilité réseau aléatoire », car les graphiques de perte de paquets étaient normaux et les serveurs autoritatifs étaient atteignables en UDP. L’indice se trouvait dans les logs du résolveur : troncation répétée et échecs de retry TCP, suivis par bogus et SERVFAIL.

L’« optimisation » utile était d’avoir des résolveurs locaux ; c’était bien. Le contrecoup fut d’assumer que le DNS est UDP‑only et de traiter TCP comme optionnel. DNSSEC a rendu les réponses plus volumineuses plus courantes. La troncation est normale. Le fallback TCP n’est pas un luxe.

Ils ont corrigé en autorisant l’egress TCP/53, et en ajoutant un test canari qui vérifie explicitement une requête DNSKEY en TCP depuis chaque cluster. Ce test a détecté le prochain changement de pare‑feu avant son déploiement.

Mini-récit 3 : La pratique ennuyeuse mais correcte qui a sauvé la mise

Une autre organisation gérait son propre DNS autoritatif avec une pipeline de signature séparée. Rien de spécial. Mais ils avaient un rituel ennuyeux : chaque changement DNSSEC nécessitait une pré‑exécution qui comparait DS, DNSKEY et la validité des RRSIG depuis trois réseaux indépendants. Pas seulement « ça résout depuis mon laptop », mais une vraie validation.

Pendant un KSK rollover planifié, le signateur a produit le nouveau matériel clé selon le calendrier. Les admins DNS ont publié les nouveaux DNSKEY, puis mis à jour le DS chez le registrar. Tout semblait bon en interne. La pré‑exécution, cependant, a échoué depuis un point de vue externe : le parent servait toujours le vieux DS pour ce réseau, probablement à cause d’un délai de propagation et d’un comportement de cache sur certains chemins récursifs.

Parce que l’équipe avait anticipé cela, elle n’a pas paniqué. Ils ont gardé les deux clés publiées plus longtemps que le minimum, évité de réduire agressivement les TTL qui provoquent des « stampedes » de résolveurs, et attendu la convergence du DS observée dans les trois validations. Ensuite, ils ont procédé à la suppression de l’ancienne clé.

Pas de panne. Pas de drame. La cause racine qui n’est jamais devenue incident était « nous avons supposé que la propagation est uniforme ». Elle ne l’est pas. Leur pratique ennuyeuse a transformé un internet imprévisible en un processus de déploiement gérable.

Blague #2 : Internet ne fait pas de « propagation uniforme », il fait du « finalement, avec des opinions ».

Erreurs courantes : symptômes → cause racine → correctif

1) Symptom: Certains résolveurs renvoient NOERROR, d’autres SERVFAIL

Cause racine : Différences de validation DNSSEC (l’un valide, l’autre non), ou caches à différents états de rollover.

Correctif : Utilisez delv et dig +dnssec pour confirmer la validation. Vérifiez la correspondance DS vs DNSKEY. Purgez les zones affectées sur vos résolveurs après correction en amont.

2) Symptom: Tout a rompu juste après « avoir désactivé DNSSEC »

Cause racine : Le DS est resté dans le parent alors que la zone avait cessé de servir des données signées. Les validateurs attendent désormais des signatures qui n’existent plus.

Correctif : Retirez le DS chez le registrar/parent d’abord (ou simultanément), continuez à servir DNSKEY/RRSIG jusqu’à ce que le DS soit parti, puis désactivez la signature.

3) Symptom: Unbound dit « no keys have a DS with algorithm X »

Cause racine : Mismatch d’algorithme/digest DS avec les DNSKEY publiés ; fréquent après un rollover d’algorithme ou une mise à jour DS erronée.

Correctif : Recalculez le DS à partir du KSK voulu et publiez le DS correct chez le parent. Assurez‑vous que l’enfant publie bien ce KSK.

4) Symptom: « no valid signature found » mais le DNSKEY existe

Cause racine : RRSIG manquant pour l’ensemble RRset, signatures expirées, ou RRSIG créée avec une clé qui n’est plus publiée.

Correctif : Re‑signez la zone ; confirmez que les signatures couvrent tous les RRsets critiques (SOA, NS, A/AAAA, etc.). Validez la synchronisation horaire sur le signateur et les serveurs autoritatifs.

5) Symptom: Ça marche pour de petites requêtes, échoue sur DNSKEY ou ANY

Cause racine : Troncation UDP plus TCP bloqué, ou problèmes EDNS0/fragmentation provoquant l’échec des réponses DNSSEC volumineuses.

Correctif : Autorisez TCP/53 ; vérifiez le path MTU ; évitez les réponses surdimensionnées en nettoyant les clés obsolètes et en ne publiant pas de DNSKEY superflu.

6) Symptom: L’échec apparaît « aléatoire » selon les sites

Cause racine : DNS split‑horizon renvoyant des DNSKEY/RRSIG différents selon la source, ou nœuds anycast hors synchro, ou jeux autoritatifs différents selon la géographie.

Correctif : Assurez‑vous que le matériel DNSSEC est cohérent sur tous les nœuds/edges autoritatifs. Évitez le split‑horizon pour les zones signées sauf si vous savez précisément ce que vous faites.

7) Symptom: Les validateurs rapportent « NSEC/NSEC3 proof failed » pour NXDOMAIN

Cause racine : Réponses négatives cassées : NSEC/NSEC3 manquants/invalides ou signatures défectueuses lors d’un glitch de signature.

Correctif : Re‑signez la zone et assurez‑vous que le signateur génère correctement les preuves négatives. Confirmez que les serveurs autoritatifs servent la même chaîne NSEC/NSEC3.

8) Symptom: Seuls vos résolveurs internes échouent ; les résolveurs publics réussissent

Cause racine : Vos résolveurs ont des trust anchors obsolètes, validation mal configurée, forwarders qui cassent les enregistrements, ou dérive d’heure.

Correctif : Vérifiez la config du résolveur, les mises à jour des trust anchors, NTP, et si vous forwardez vers un résolveur qui supprime DNSSEC.

Checklists / plan pas-à-pas

Checklist A — Vous êtes opérateur de résolveur (vous exploitez des résolveurs validants)

1. Confirmez que DNSSEC est le déclencheur : comparez les résultats de votre résolveur et d’un résolveur validant externe avec dig +dnssec et vérifiez le bit AD.
2. Collectez des preuves : logs du résolveur (Unbound/BIND), DS du parent, DNSKEY de l’enfant, timing des RRSIG pour les RRsets affectés.
3. Écartez l’environnement local : synchronisation horaire, reachability TCP/53, comportement buffer EDNS0, fragmentation de paquets, stripping par les forwarders.
4. Décidez de la mitigation : Si l’impact business est élevé et que la correction amont n’est pas immédiate, ajoutez une NTA pour la portée minimale (idéalement la zone exacte, pas tout le TLD).
5. Communiquez clairement : « Nous avons une défaillance de validation DNSSEC pour la zone X ; impact service ; mitigation appliquée ; propriétaire amont engagé. » Pas « Le DNS est down. »
6. Supprimez la mitigation : après validation de la correction amont depuis plusieurs réseaux ; videz le cache de la zone ; retirez la NTA ; confirmez le retour du bit AD.

Checklist B — Vous êtes propriétaire de la zone (vous contrôlez le DNS autoritatif et DNSSEC)

1. Identifiez le type de défaillance :
   • Si mismatch DS : le DS parent ne correspond pas au KSK enfant.
   • Si signatures manquantes/expirées : pipeline de signature ou publication cassée.
   • Si transport : réponses tronquées et TCP bloqué quelque part.
2. Corrigez la justesse DS/DNSKEY avant toute autre chose : publiez les clés correctes ; mettez à jour le DS ; gardez un chevauchement pour les rollovers ; ne retirez pas trop vite les anciennes clés.
3. Validez les réponses négatives : les NXDOMAIN doivent être signés avec des preuves NSEC/NSEC3 correctes.
4. Gérez les TTL comme un adulte : réduire les TTL accélère les changements, mais peut aussi augmenter la charge de requêtes et exposer des comportements de résolveurs fragiles en incident.
5. Coordonnez‑vous avec le registrar : Les changements DS sont des changements de production. Traitez‑les comme tels.

Checklist C — Vous êtes coincé parce que « l’amont ne va pas corriger vite »

1. Atténuez localement : NTA (Unbound) ou contournement basé sur une politique lorsque pertinent.
2. Limitez le rayon d’impact : ne contournEZ que la zone affectée, pas la validation globale.
3. Fixez une échéance : rappel calendrier, ticket et alerte de monitoring pour la NTA toujours présente après la date butoir.
4. Escaladez avec des preuves : fournissez la sortie DS, la sortie DNSKEY, et le message d’erreur exact du validateur. Les fournisseurs répondent mieux aux preuves qu’aux impressions.

FAQ

1) Que signifie « bogus » en termes DNSSEC ?

Cela signifie que la validation a échoué : le résolveur ne peut pas vérifier cryptographiquement la réponse contre la chaîne signée de confiance, il renvoie donc SERVFAIL.

2) Pourquoi certains résolveurs résolvent-ils quand un domaine est bogus ?

Parce qu’ils ne valident pas, ou qu’ils sont configurés pour ne pas appliquer la validation. De plus, certains peuvent avoir en cache des données antérieures à la rupture. Le comportement de validation est une politique.

3) Désactiver DNSSEC sur mon résolveur est‑ce une bonne solution d’urgence ?

En dernier recours, temporairement, et seulement avec une acceptation explicite des risques. Mieux : appliquez une NTA pour la zone spécifique. Cela restaure le service tout en conservant DNSSEC pour le reste.

4) Nous avons « désactivé DNSSEC » sur la zone mais les utilisateurs ont eu plus d’échecs. Pourquoi ?

Si le DS reste dans la zone parente, les validateurs attendent des signatures. Désactiver la signature sans retirer le DS casse la validation encore plus sévèrement. Retirez d’abord le DS, puis désactivez la signature.

5) Comment la dérive d’horloge peut‑elle provoquer un échec DNSSEC ?

Les RRSIG ont des temps d’inception et d’expiration. Si l’horloge de votre résolveur est fausse, des signatures valides peuvent sembler « expirées » ou « pas encore valides ». Corrigez NTP avant toute autre opération.

6) Quelle est la différence opérationnelle entre DS et DNSKEY ?

DNSKEY est publié dans la zone enfant. DS est publié dans la zone parente et pointe (par digest) vers un KSK enfant. DS est ce qui relie la chaîne de confiance.

7) Pourquoi TCP/53 est‑il important pour DNSSEC ?

DNSSEC ajoute des signatures et des clés, ce qui augmente la taille des réponses. L’UDP peut tronquer ; les résolveurs retentent en TCP. Si TCP/53 est bloqué, les réponses signées volumineuses peuvent échouer.

8) Dois‑je vider les caches des résolveurs après avoir corrigé DNSSEC ?

Souvent oui, au moins pour la zone affectée. Les résolveurs peuvent mettre en cache DNSKEY, l’état lié au DS, et des réponses négatives. Préférez les vidages de zone ciblés plutôt que les wipes complets.

9) Quelle est une méthode sûre pour valider depuis plusieurs points de vue ?

Exécutez delv ou dig +dnssec depuis au moins deux réseaux (par ex. votre DC et une VM cloud) et comparez DS/DNSKEY et le comportement du bit AD.

10) Si les serveurs autoritatifs répondent correctement, pourquoi des validateurs échoueraient‑ils ?

Parce que le DS chez le parent peut être incorrect, ou parce que les signatures n’apparaissent pas valides même si elles existent. De plus, des problèmes de transport intermédiaire peuvent empêcher les validateurs de récupérer des enregistrements nécessaires de façon fiable.

Conclusion : étapes suivantes pour éviter les répétitions

Si vous retenez une chose, que ce soit celle‑ci : les échecs DNSSEC ne sont généralement pas mystérieux. Ils sont distribués, mis en cache, et détenus par plusieurs parties. La sortie passe par une collecte de preuves disciplinée et des mitigations contrôlées.

À faire ensuite

1. Ajoutez un canari DNSSEC qui exécute delv (ou équivalent) contre vos domaines critiques depuis au moins deux réseaux, et alertez sur les échecs de validation — pas seulement NXDOMAIN/timeout.
2. Documentez la propriété DS : qui peut modifier le DS chez le registrar, comment fonctionnent les approbations, comment effectuer un rollback. Si la réponse est « marketing », corrigez votre organigramme ou vos contrôles d’accès.
3. Rendez TCP/53 non négociable pour les résolveurs. Si quelqu’un veut le bloquer, qu’il prouve d’abord qu’il comprend la troncation et le comportement EDNS0.
4. Entraînez‑vous aux rollovers de clés avec un runbook qui inclut des vérifications externes et des périodes de chevauchement explicites. « On va juste faire une rotation » est la façon d’acheter un nouvel incident.
5. Privilégiez des mitigations ciblées (NTA par zone) plutôt que de désactiver la validation globalement. Si vous devez contourner, fixez une date d’expiration et une alerte.

DNSSEC, c’est comme la ceinture de sécurité : légèrement irritant jusqu’au jour où vous en avez besoin. L’astuce est de faire en sorte qu’elle ne se bloque pas parce que quelqu’un l’a installée à l’envers.