DNSSEC échoue aléatoirement : diagnostiquer les erreurs de validation sans panique

janvier 4, 2026 • février 3, 2026 • Lecture : 27 min • Views: 6

Cet article vous a aidé ?

Il est 02:13. La moitié de votre parc atteint une API partenaire ; l’autre moitié obtient SERVFAIL. Quelqu’un dit « le DNS est en panne ». Un autre dit « c’est DNSSEC ». Vous avez envie de redémarrer un résolveur et d’espérer que personne ne remarque.

Ne le faites pas. Les échecs DNSSEC « aléatoires » sont généralement déterministes. Ils semblent simplement aléatoires parce que des résolveurs différents, des chemins différents, des caches différents, des MTU différents, des horloges différentes et des états de clés différents produisent des résultats différents. Voici un guide de terrain pour transformer la panique en une courte liste de vérifications, avec des commandes à exécuter pendant que le canal d’incident discute encore de qui a fait la modification.

Ce que signifie vraiment « échec DNSSEC aléatoire »

La validation DNSSEC est une opération binaire : soit la chaîne de confiance valide pour l’ensemble RRset au moment où vous l’avez demandée, soit elle ne valide pas. Alors pourquoi cela semble-t-il intermittent ?

Des résolveurs différents voient des données différentes. L’état du cache, la mise en cache négative, l’NSEC agressif et le préfetch signifient que deux résolveurs peuvent être « corrects » et néanmoins diverger pendant des minutes.
Des chemins différents traitent différemment les gros UDP. Les réponses DNSSEC sont plus volumineuses. EDNS0 augmente la taille des paquets UDP ; certains réseaux laissent tomber les fragments ou bloquent les ICMP « Fragmentation needed ». Résultat : un client retente en TCP, un autre non.
Le temps compte. Les RRSIG ont une inception/expiration. Un décalage d’horloge sur le validateur peut transformer des signatures valides en « expirées » ou « pas encore valides ».
États différents des trust anchors. Les trust anchors gérés et le comportement RFC 5011 peuvent entraîner des « ça marche ici, ça échoue là » lors de rollovers de clés ou après une longue panne.
Différences en amont. Si vos résolveurs relaient vers des upstreams différents (ou découvrent automatiquement), vous comparez peut-être des pommes et des oranges en feu.

L’objectif est d’arrêter de le traiter comme un fantôme. Vous allez identifier : quel résolveur échoue, pour quel nom/type, avec quel statut DNSSEC, et pourquoi.

Faits et historique importants en pratique

Voici quelques points concrets qui ne sont pas triviaux — ils changent la manière de déboguer :

Les spécifications centrales de DNSSEC datent de 2005 (RFC 4033/4034/4035). Beaucoup d’outils « DNS hérités » les précèdent et omettent des détails.
La zone root a été signée en 2010. Avant cela, la validation s’arrêtait à la racine ; après cela, les échecs peuvent se propager globalement si la chaîne casse.
Les rollovers d’algorithmes sont des événements réels, pas une théorie. Les digests DS basés sur SHA‑1 (et d’anciens algorithmes) ont été progressivement abandonnés ; des mismatches apparaissent souvent pendant les transitions.
DNSKEY et DS ne sont pas la même chose. Le DS se situe chez le parent ; le DNSKEY dans l’enfant. Si vous changez les clés sans mettre à jour le DS, les validateurs déclareront (correctement) votre zone « bogus ».
Les grandes réponses DNS étaient historiquement fragiles. DNS a commencé avec des réponses UDP de 512 octets ; DNSSEC a rendu les « grosses réponses » courantes, d’où EDNS0 et plus de fallback TCP.
NSEC3 a été introduit pour réduire le zone‑walking. Il augmente aussi la complexité et la taille des réponses ; vous le verrez dans les preuves d’absence d’existence.
Certains résolveurs mettent en cache des décisions « bogus » brièvement. Cela peut faire paraître une mauvaise configuration plus longue qu’elle ne l’était, et c’est la raison pour laquelle « on a réparé mais ça échoue encore » arrive.
Il y a eu un grand rollover de KSK root en 2018. Cela a appris à tout le monde que la « gestion des trust anchors » est du travail opérationnel, pas une case à cocher.

Une citation pour rester lucide, parce que les incidents punissent l’optimisme :

« L’espoir n’est pas une stratégie. » — Général Gordon R. Sullivan

Playbook de diagnostic rapide

Quand des utilisateurs disent « DNSSEC est instable », vous avez besoin d’une boucle serrée. Voici l’ordre qui trouve le goulot d’étranglement le plus vite dans des systèmes réels.

1) Confirmer que c’est la validation DNSSEC (et pas le DNS simple)

Choisissez un client en échec et un client connu bon.
Interrogez la même IP de résolveur directement (ne comptez pas sur /etc/resolv.conf, les domaines de recherche ou le DNS partagé).
Comparez les drapeaux AD, RA, et le code de réponse réel (NOERROR, SERVFAIL, NXDOMAIN).

2) Identifier le validateur en échec et l’isoler

Si vous avez un pool de résolveurs, vérifiez-les un par un. Intermittent signifie souvent « un sous‑ensemble ».
Si vous relaiez vers des résolveurs upstream, contournez temporairement le forwarding (ou testez la récursion directe) pour localiser où la validation casse.

3) Vérifier la chaîne : DS chez le parent, DNSKEY chez l’enfant, signatures valides « maintenant »

Utilisez delv ou drill -D pour forcer une trace complète de validation.
Vérifiez mismatch DS, RRSIG manquant, signatures expirées, ou algorithme non supporté.

4) Vérifier MTU / fragmentation / fallback TCP

Recherchez des motifs « udp truncated », une augmentation des requêtes TCP, ou des timeouts uniquement sur certains réseaux.
Testez en réduisant la taille EDNS pour reproduire.

5) Vérifier le temps et les trust anchors

Le décalage d’horloge sur les validateurs est un tueur silencieux.
Des trust anchors root périmés apparaissent après de longues pannes ou des images figées.

Règle de décision : si la même requête au même résolveur bascule entre AD et SERVFAIL sans aucun changement de zone, suspectez d’abord le chemin réseau/fragmentation ou un résolveur surchargé, pas la cryptographie.

Modèle mental : où la validation DNSSEC peut échouer

Pensez en couches. DNSSEC n’est pas une seule chose ; c’est plusieurs dépendances alignées, chacune pouvant échouer de façons qui se ressemblent.

Couche A : Transport (UDP/TCP, EDNS0, fragmentation)

DNSSEC augmente souvent la taille des réponses : ensembles DNSKEY, enregistrements DS, RRSIG, preuves NSEC/NSEC3. Si des paquets UDP sont fragmentés et que des fragments sont perdus, le résolveur peut ne jamais assembler la réponse, peut réessayer, ou peut marquer l’amont comme « lame ».

Couche B : Intégrité des données (signatures et chaîne de confiance)

La validation exige un chemin depuis une trust anchor (généralement la racine) via DS et DNSKEY jusqu’à l’ensemble RR que vous avez demandé. Cassez le lien DS, publiez de mauvaises signatures, ou laissez des signatures expirer, et un validateur doit renvoyer SERVFAIL (ou marquer « bogus » en interne). C’est tout l’objet.

Couche C : Temps (fenêtres de validité RRSIG)

L’inception/expiration des RRSIG n’est pas indulgente. Un validateur avec une mauvaise horloge peut invalider des zones parfaitement valides. C’est l’un des rares problèmes DNS réellement résolus par NTP, pas par des discussions plus poussées.

Couche D : Comportement du validateur (cache, RFC 5011, NSEC agressif)

Les résolveurs ne sont pas identiques. Unbound, BIND, PowerDNS Recursor et d’autres diffèrent par défaut : agressivité du cache, gestion du préfetch, verbosité des logs, et gestion des trust anchors. Si vous exploitez une flotte mixte, vous exploitez aussi un ensemble mixte de modes de défaillance.

Blague #1 : DNSSEC, c’est comme la sécurité aéroportuaire : ça améliore la sécurité, mais ça vous fera enlever vos chaussures au pire moment possible.

Tâches pratiques : commandes, sorties, décisions

Le moyen le plus rapide de déboguer DNSSEC est de collecter des « preuves », pas des impressions. Ci‑dessous se trouvent de vraies tâches à exécuter sur un client, un résolveur, ou les deux. Chaque tâche a : une commande, ce que signifie la sortie typique, et la décision suivante à prendre.

Tâche 1 : Vérifier si le résolveur valide (drapeau AD)

cr0x@server:~$ dig @192.0.2.53 www.cloudflare.com A +dnssec +multi

; <<>> DiG 9.18.24 <<>> @192.0.2.53 www.cloudflare.com A +dnssec +multi
; (1 server found)
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 1122
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; ANSWER SECTION:
www.cloudflare.com.  300 IN A 104.16.132.229
www.cloudflare.com.  300 IN RRSIG A 13 3 300 20260101000000 20251201000000 34505 cloudflare.com. ...

;; Query time: 21 msec
;; SERVER: 192.0.2.53#53(192.0.2.53) (UDP)

Sens : ad indique que le résolveur a validé la réponse. La présence de RRSIG montre que les données DNSSEC ont été demandées.

Décision : Si le cas en échec n’a pas ad ou retourne SERVFAIL, continuez l’investigation. S’il retourne NOERROR sans ad, le résolveur peut être non‑validant ou configuré pour supprimer AD.

Tâche 2 : Confirmer que le `SERVFAIL` provient de la validation, pas d’un timeout amont

cr0x@server:~$ dig @192.0.2.53 broken.dnssec-failed.org A +dnssec +comments

;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 44110
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available

Sens : SERVFAIL est ambigu en soi. L’important est de le corréler avec les logs du résolveur (tâches ci‑dessous) et de tester avec un outil validant (delv).

Décision : Si plusieurs noms non liés retournent SERVFAIL, suspectez l’état ou la connectivité du résolveur. Si un seul zone, suspectez les données DNSSEC de la zone ou des problèmes MTU pour les réponses de cette zone.

Tâche 3 : Utiliser `delv` pour obtenir une explication de validation (preuve locale)

cr0x@server:~$ delv @192.0.2.53 example.com A

; fully validated
example.com.  300 IN A 93.184.216.34

Sens : « fully validated » signifie que le résolveur a fourni suffisamment de données et que la validation a réussi.

Décision : Si delv indique « resolution failed » ou « bogus », traitez‑le comme DNSSEC jusqu’à preuve du contraire et passez à l’inspection de la chaîne.

Tâche 4 : Faire afficher à `delv` pourquoi c’est bogus

cr0x@server:~$ delv @192.0.2.53 bad.example A +rtrace

...
; validation failure <bad.example/A>: no valid RRSIG
; resolution failed: SERVFAIL

Sens : Cela vous indique la catégorie : signature manquante/incorrecte, mismatch DS, algorithme non supporté, etc.

Décision : « no valid RRSIG » signifie généralement une signature cassée, des signatures expirées, ou que la réponse a été tronquée/abandonnée et que le résolveur n’a pas reçu les signatures.

Tâche 5 : Comparer le comportement avec DNSSEC désactivé à la requête (test de contrôle)

cr0x@server:~$ dig @192.0.2.53 example.com A +nodnssec +multi

; <<>> DiG 9.18.24 <<>> @192.0.2.53 example.com A +nodnssec +multi
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 5881
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

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

Sens : Si +nodnssec fonctionne mais +dnssec échoue, la taille/validation DNSSEC est impliquée. Si les deux échouent, c’est le DNS simple ou le transport.

Décision : Utilisez ceci pour calmer les intervenants : « DNS fonctionne, la validation DNSSEC échoue » est un problème plus restreint que « le DNS est cassé ».

Tâche 6 : Inspecter le DS chez le parent (test « le parent pointe-t-il correctement ? »)

cr0x@server:~$ dig @192.0.2.53 example.com DS +dnssec +multi

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 19981
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; ANSWER SECTION:
example.com.  86400 IN DS 370 13 2 9F3E...C1A7
example.com.  86400 IN RRSIG DS 8 2 86400 20260101000000 20251201000000 12345 com. ...

Sens : Le parent publie un DS. Le digest et le key tag doivent correspondre à un DNSKEY dans la zone enfant. ad ici est un bon signe : la chaîne parentale est OK jusqu’à ce point.

Décision : Si le DS manque, la zone est « insecure » (non signée du point de vue du parent). Si le DS existe mais ne correspond pas au DNSKEY enfant, vous obtenez du bogus.

Tâche 7 : Inspecter le DNSKEY chez l’enfant (test « l’enfant publie‑t‑il la bonne clé ? »)

cr0x@server:~$ dig @192.0.2.53 example.com DNSKEY +dnssec +multi

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 5022
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; ANSWER SECTION:
example.com.  3600 IN DNSKEY 257 3 13 mGx...==
example.com.  3600 IN DNSKEY 256 3 13 tZk...==
example.com.  3600 IN RRSIG DNSKEY 13 2 3600 20260101000000 20251201000000 370 example.com. ...

Sens : Vous verrez typiquement une KSK (flag 257) et une ou plusieurs ZSK (flag 256). Elles doivent être signées, et les signatures doivent valider.

Décision : Si les requêtes DNSKEY timeout ou sont tronquées, vous avez probablement des problèmes MTU/fragmentation. Si DNSKEY existe mais n’aligne pas avec DS, c’est un problème de rollover DS.

Tâche 8 : Forcer TCP pour exclure la fragmentation UDP

cr0x@server:~$ dig @192.0.2.53 example.com DNSKEY +dnssec +tcp

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 61001
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; Query time: 37 msec
;; SERVER: 192.0.2.53#53(192.0.2.53) (TCP)

Sens : Si TCP fonctionne de manière fiable alors que UDP échoue de façon intermittente, votre problème « aléatoire » est probablement la fragmentation de paquets, le comportement d’un pare‑feu, ou un PMTUD cassé.

Décision : Atténuez en réduisant la taille EDNS UDP sur le résolveur, en autorisant correctement DNS sur TCP/853, ou en réparant le chemin réseau qui supprime les fragments/ICMP.

Tâche 9 : Contraindre la taille EDNS pour reproduire les échecs de « grosse réponse »

cr0x@server:~$ dig @192.0.2.53 example.com DNSKEY +dnssec +bufsize=1232

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4555
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232

Sens : 1232 est une taille EDNS courante « sûre » pour éviter la fragmentation sur des chemins typiques. Si réduire le bufsize fait disparaître les échecs, vous avez appris quelque chose d’utile sur votre réseau.

Décision : Configurez côté résolveur une taille EDNS conservatrice si vous opérez sur des réseaux hostiles (VPN, overlays, Wi‑Fi d’hôtel, certains pare‑feux d’entreprise).

Tâche 10 : Vérifier les logs du résolveur pour erreurs explicites de validation (Unbound)

cr0x@server:~$ sudo journalctl -u unbound --since "10 min ago" | tail -n 30
Dec 31 01:59:12 resolver-a unbound[912]: info: validation failure <example.com. DNSKEY IN>: signature expired
Dec 31 01:59:12 resolver-a unbound[912]: info: resolving example.com. DNSKEY IN
Dec 31 01:59:13 resolver-a unbound[912]: info: error: SERVFAIL example.com. A IN

Sens : Ce n’est pas « aléatoire ». C’est « signature expired », ce qui signifie généralement que l’opérateur de zone n’a pas re‑signé à temps, ou que votre horloge est incorrecte.

Décision : Vérifiez d’abord l’heure locale (tâche 12). Si l’heure locale est correcte, escaladez vers le propriétaire de la zone avec des preuves.

Tâche 11 : Vérifier les logs du résolveur pour erreurs de validation (BIND named)

cr0x@server:~$ sudo journalctl -u named --since "10 min ago" | tail -n 40
Dec 31 02:01:22 resolver-b named[1044]: resolver: info: validating example.com/A: no valid signature found
Dec 31 02:01:22 resolver-b named[1044]: resolver: info: DNSKEY example.com is not secure
Dec 31 02:01:22 resolver-b named[1044]: resolver: info: client @0x7f... 198.51.100.27#51622 (example.com): query failed (SERVFAIL) for example.com/IN/A at query.c:...

Sens : « No valid signature found » se corrèle souvent avec un mismatch DS, un RRSIG manquant, ou une réponse tronquée où le résolveur n’a jamais reçu les signatures nécessaires.

Décision : Testez immédiatement avec +tcp et +bufsize=1232 pour voir si c’est lié au transport. Sinon, inspectez l’alignement DS/DNSKEY.

Tâche 12 : Confirmer que les horloges sont saines (décalage horaire du validateur)

cr0x@server:~$ timedatectl
               Local time: Wed 2025-12-31 02:06:41 UTC
           Universal time: Wed 2025-12-31 02:06:41 UTC
                 RTC time: Wed 2025-12-31 02:06:41
                Time zone: UTC (UTC, +0000)
System clock synchronized: yes
              NTP service: active
          RTC in local TZ: no

Sens : La validation DNSSEC dépend d’une heure correcte. Si System clock synchronized est « no », vous êtes en zone dangereuse.

Décision : Réparez la synchronisation NTP/heure avant de toucher aux configs DNS. Si l’heure hôte est fausse, toutes les autres conclusions sont suspectes.

Tâche 13 : Détecter un problème de trust anchor (problème de clé root) avec l’utilitaire anchor d’Unbound

cr0x@server:~$ sudo unbound-anchor -a /var/lib/unbound/root.key
/var/lib/unbound/root.key has content
success: the anchor is ok

Sens : Cela vérifie que le fichier de trust anchor root configuré est présent et raisonnable.

Décision : Si cela échoue seulement sur certains résolveurs, vous avez probablement de la dérive d’image ou un appliance périmé. Mettez à jour les trust anchors de manière contrôlée.

Tâche 14 : Vérifier si vous faites du forwarding (et donc héritiez du comportement DNSSEC d’un tiers)

cr0x@server:~$ sudo unbound-control list_forwards
zone=.
forward-addr=203.0.113.9@53
forward-addr=203.0.113.10@53

Sens : Vous ne faites pas de récursion complète ; vous faites confiance à des forwarders upstream. S’ils valident différemment, filtrent EDNS, ou cassent le fallback TCP, vos résultats varieront.

Décision : Pour le débogage, testez la récursion directe depuis un résolveur (temporairement dans un labo ou une instance isolée) pour voir si le problème est chez vous ou en amont.

Tâche 15 : Vérifier que votre résolveur tente vraiment la validation DNSSEC

cr0x@server:~$ sudo unbound-control get_option val-permissive-mode
val-permissive-mode: no

Sens : Le mode permissif peut transformer des échecs durs en échecs souples. Utile pour l’atténuation d’urgence ; mauvais pour les attentes de sécurité et la clarté du débogage.

Décision : Gardez le mode permissif désactivé en production normale. S’il est activé pendant un incident, documentez‑le, fixez une durée, et planifiez le retour arrière.

Tâche 16 : Mesurer le mix UDP vs TCP des requêtes (signal transport)

cr0x@server:~$ sudo unbound-control stats_noreset | egrep 'num.query.tcp|num.query.udp|num.answer.rcode.SERVFAIL'
num.query.udp=1849921
num.query.tcp=219004
num.answer.rcode.SERVFAIL=3812

Sens : Un pic soudain de requêtes TCP peut indiquer des problèmes de fragmentation UDP ou une troncature délibérée. Un pic de SERVFAIL corrélé à des zones spécifiques pointe vers des problèmes de chaîne DNSSEC.

Décision : Si le ratio TCP augmente pendant la même fenêtre que les échecs, inspectez le réseau/MTU. Si SERVFAIL augmente sans changement TCP, recherchez des erreurs de validation et des trust anchors.

Tâche 17 : Tester le MTU et le comportement de fragmentation (méthode rapide)

cr0x@server:~$ ping -M do -s 1472 198.51.100.53 -c 3
PING 198.51.100.53 (198.51.100.53) 1472(1500) bytes of data.
ping: local error: message too long, mtu=1480
ping: local error: message too long, mtu=1480
ping: local error: message too long, mtu=1480

--- 198.51.100.53 ping statistics ---
3 packets transmitted, 0 received, +3 errors, 100% packet loss, time 2041ms

Sens : Des contraintes MTU existent sur le chemin. Le DNS sur UDP avec de grands payloads EDNS devient suspect. Cela ne prouve pas que les fragments DNS sont supprimés, mais c’est un fort indice.

Décision : Réduisez la taille EDNS UDP sur le résolveur, assurez‑vous que le fallback TCP fonctionne, et réparez la gestion ICMP si possible.

Tâche 18 : Confirmer que les serveurs faisant autorité sont joignables et cohérents

cr0x@server:~$ dig @ns1.example.net example.com DNSKEY +dnssec +norec
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 3101
;; flags: qr aa; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

Sens : aa confirme une réponse faisant autorité. Si un serveur auth renvoie un DNSKEY/RRSIG différent d’un autre, vous pouvez avoir des problèmes de propagation, des signateurs en split‑brain, ou une clé partiellement roulée.

Décision : Interrogez chaque nameserver autoritaire directement. Des données DNSSEC incohérentes entre serveurs auth sont une cause très probable de « échecs aléatoires ».

Blague #2 : Le débogage DNSSEC, c’est apprendre la différence entre « système distribué » et « répartition des responsabilités distribuée ».

Erreurs courantes : symptôme → cause racine → correction

Voici la partie où l’on arrête de pointer du doigt « l’Internet » et où l’on nomme les suspects habituels.

1) Certains clients obtiennent `SERVFAIL`, d’autres réussissent

Symptôme : Échecs intermittents corrélés au bureau/VPN/région ; les retries fonctionnent parfois.
Cause racine : Pertes de fragments UDP, PMTUD cassé, ou pare‑feu qui altère EDNS0. Les réponses DNSSEC sont volumineuses ; le chemin n’est pas indulgent.
Correction : Réduire la taille EDNS UDP sur les résolveurs (souvent 1232), autoriser TCP/53, et réparer la gestion ICMP sur le chemin. Valider avec dig +tcp et dig +bufsize=1232.

2) Tout fonctionnait jusqu’à un rollover de clé, puis ça a « cassé aléatoirement »

Symptôme : Une zone auparavant stable devient intermittente bogus ; certains résolveurs récupèrent plus vite que d’autres.
Cause racine : Le DS chez le parent ne correspond pas à la KSK active chez l’enfant ; ou un serveur autoritaire sert encore l’ancien DNSKEY/RRSIG.
Correction : Vérifiez le DS chez le parent et le DNSKEY chez l’enfant. Assurez‑vous que tous les serveurs autoritaires servent les mêmes données signées. Reprenez correctement les étapes du rollover ; n’enlevez pas DNSSEC à la va‑vite sauf si vous aimez les coups de téléphone clients.

3) Les échecs démarrent après un « durcissement » réseau

Symptôme : Le DNS est OK pour les petits enregistrements ; les requêtes DNSKEY timeout ; TCP/53 bloqué.
Cause racine : Pare‑feu qui bloque les fragments, bloque TCP/53, ou rate‑limite des patterns UDP « inconnus », DoSant accidentellement DNSSEC.
Correction : Autoriser TCP/53 vers les résolveurs, permettre les fragments retour ou baisser la taille EDNS. Confirmer avec des stats : hausse du fallback TCP, troncatures, ou timeouts.

4) Les failures de validation apparaissent seulement sur un sous‑ensemble de résolveurs

Symptôme : Résolveur A valide ; Résolveur B renvoie SERVFAIL pour la même requête.
Cause racine : Trust anchors différents, root.key périmé, décalage horaire, forwarders différents, ou versions/configurations différentes de résolveur.
Correction : Standardiser la configuration des résolveurs et la gestion des trust anchors. Vérifier la synchronisation horaire. Comparer unbound-anchor, versions, et paramètres de forwarding.

5) `NXDOMAIN` devient `SERVFAIL` sous DNSSEC

Symptôme : Un nom inexistant devrait être NXDOMAIN mais revient SERVFAIL sur des résolveurs validants.
Cause racine : Preuves d’absence (NSEC/NSEC3) cassées ou RRSIG manquantes sur NSEC/NSEC3.
Correction : Validez avec delv +rtrace. Corrigez la signature autoritaire pour NSEC/NSEC3, assurez‑vous des bons paramètres, et confirmez que tous les serveurs auth servent des enregistrements d’absence cohérents.

6) « Ça marche avec des résolveurs publics mais pas chez nous »

Symptôme : Les résolveurs publics valident bien ; vos résolveurs internes échouent.
Cause racine : Vos résolveurs relaient vers un upstream qui supprime DNSSEC, altère EDNS, ou bloque le fallback TCP ; ou votre réseau interne fait tomber des fragments.
Correction : Testez la récursion directe (sans forwarding) sur un résolveur. Comparez le buffer EDNS, le comportement TCP, et les logs.

Trois mini-récits d’entreprise issus du terrain

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

La société A avait une architecture propre : deux VIP anycast par région, Unbound derrière, et une politique de forwarding « simple » vers un service DNS tiers pour de meilleurs hits de cache. DNSSEC était activé parce que leur équipe sécurité avait une case trimestrielle à cocher qui demandait les mots « DNSSEC validation ».

Un partenaire a fait pivoter ses clés DNSSEC. Rien d’inhabituel, juste de l’hygiène de routine. En une heure, une poignée de pods applicatifs dans une région ont commencé à échouer des handshake TLS car ils ne pouvaient pas résoudre un nom d’OCSP. Le canal d’incident s’est animé.

L’ingénieur on‑call a supposé : « Si Internet public le résout, nos résolveurs doivent être cassés. » Cette supposition était inversée. Les résolveurs publics ne relayaient pas vers le même upstream, n’étaient pas derrière le même pare‑feu, et n’étaient pas soumis au même traitement EDNS.

Il s’est avéré que leur forwarder upstream faisait aussi de la validation — mais avec une politique différente. Il renvoyait SERVFAIL pour des zones pendant une fenêtre de transition DS que leur configuration interne aurait pu gérer si elle faisait la récursion complète. Les résolveurs internes étaient innocents ; ils relaiaient docilement l’échec upstream.

La correction fut peu glamour : ils ont désactivé temporairement le forwarding pour la zone concernée (forwarding basé sur la politique), ont fait la récursion directe, et les échecs ont cessé. Puis ils ont repensé : soit forwarder et accepter le comportement upstream, soit effectuer la récursion et gérer la validation de bout en bout. Mélanger les deux sans attentes explicites, c’est la recette pour recevoir des pages d’alerte.

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

La société B avait un réseau global avec des WAN optimizers « utiles ». Quelqu’un a trouvé le trafic DNS « bavard » et a décidé de l’optimiser. L’équipe WAN a déployé une politique qui dépriorisait les fragments UDP en période de congestion parce que « la fragmentation est souvent du bruit ».

Rien n’a explosé immédiatement. La plupart des réponses DNS étaient petites. Mais dès que DNSSEC s’est généralisé chez leurs fournisseurs, des DNSKEY et certains TXT signés ont commencé à être fragmentés. Les optimizers ne supprimaient pas tous les fragments — juste assez pour rendre le problème intermittent sous charge. Parfait : un bug qui se reproduit quand vous êtes le plus occupé.

Ce qui a empiré les choses, c’est le comportement de fallback. Certains résolveurs repiquaient en TCP rapidement ; certains clients avaient des timeouts courts ; certains middleboxes traitaient TCP/53 avec méfiance. Les utilisateurs ont signalé des « échecs DNS aléatoires », et la première réaction a été d’ajouter des résolveurs.

Ajouter des résolveurs a modifié le comportement du cache et la distribution des requêtes, ce qui a légèrement modifié les tailles de paquets et le timing. Cela a aussi rendu les graphes d’incident plus difficiles à interpréter. L’optimisation avait échoué deux fois : elle a causé le problème puis l’a masqué.

La résolution finale a été de définir une taille EDNS UDP conservatrice et d’ajuster la politique WAN pour cesser de traiter les fragments comme jetables. Ce n’était pas héroïque. C’était simplement admettre que DNSSEC faisait des « gros UDP » une réalité de premier plan.

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

La société C ne faisait rien d’extraordinaire. Ils faisaient tourner des résolveurs BIND avec une baseline stricte, NTP partout, gestion de configuration avec détection de dérive, et un résolveur canari par région. Ils avaient aussi l’habitude : chaque jour, des jobs automatisés lançaient delv contre un petit ensemble de domaines externes critiques et quelques zones internes signées.

Un mardi, une mise à jour DS côté registrar pour une zone gérée par un client s’est mal passée. La zone était toujours signée, mais le DS chez le parent ne correspondait plus à la KSK dans l’enfant. Cela signifie : les résolveurs validants doivent échouer. Les résolveurs non validants continueront de résoudre joyeusement, d’où l’expérience en split‑brain utilisateur.

Le job canari quotidien l’a détecté en quelques minutes. Pas parce que l’entreprise était psychique — parce qu’elle mesurait l’état de validation comme un signal SLO prioritaire. Leur on‑call avait un playbook, les logs étaient centralisés, et la preuve était déjà dans le ticket.

Ils ont prévenu le registrar, ont rollbacké le DS, et l’incident n’est jamais devenu une panne à grande échelle. La pratique ennuyeuse n’était pas de « l’expertise DNSSEC ». C’était répéter un petit test de validation chaque jour pour que « un mauvais jour » ressemble à un pattern connu, pas à une horreur nouvelle.

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

Étape par étape : isoler si c’est les données de zone, la config du résolveur, ou le réseau

Choisir un nom et un type d’enregistrement en échec. Notez‑les. Ne déboguez pas le « DNS » en général.
Interroger le même résolveur directement depuis un hôte en échec. Utilisez dig @IP et incluez +dnssec.
Répéter depuis un hôte connu bon. Si les résultats diffèrent, vous avez des différences de chemin ou de sélection de résolveur.
Essayer +tcp. Si TCP corrige, vous regardez UDP/EDNS/fragmentation.
Essayer +bufsize=1232. Si cela corrige, votre chemin réseau est hostile aux gros UDP.
Lancer delv +rtrace pour obtenir la raison. C’est plus rapide que de deviner.
Vérifier les logs du résolveur pour raisons « bogus ». Signature expirée, mismatch DS, algorithme non supporté, etc.
Valider la synchronisation horaire sur le résolveur. Si le temps est faux, arrêtez‑tout et réparez‑le.
Interroger DS parent et DNSKEY enfant. Assurez‑vous qu’ils s’alignent et sont cohérents sur tous les serveurs autoritaires.
Décider de la propriété.
- Si mismatch DS/DNSKEY : problème du propriétaire de la zone / registrar.
- Si seulement certains résolveurs échouent : dérive de flotte/heure/trust anchors.
- Si TCP marche et UDP non : chemin réseau / taille EDNS.

Checklist : quoi capturer pour une escalade (pour qu’on répare)

FQDN en échec et type d’enregistrement (A/AAAA/TXT/DNSKEY/DS).
IP(s) des résolveurs testés et indication si du forwarding est impliqué.
Sortie de dig avec +dnssec et avec +tcp.
Sortie de delv +rtrace montrant la raison (sig expirée, mismatch DS, etc.).
Horodatage et fuseau/état d’horloge du résolveur.
Quels serveurs autoritaires ont été interrogés directement, et si les réponses différaient.

FAQ

1) Pourquoi un échec DNSSEC apparaît‑il comme `SERVFAIL` au lieu d’un message plus clair ?

Parce que DNS est un protocole conçu pour la minimalité et la mise en cache. Les validateurs ne divulguent généralement pas de détails de validation aux clients. Le résolveur sait « bogus », le client voit « SERVFAIL ». Utilisez les logs du résolveur et delv pour l’explication.

2) Quel est le moyen le plus rapide de prouver un mismatch DS/DNSKEY ?

Interrogez le DS chez le parent et le DNSKEY chez l’enfant, puis lancez delv +rtrace. Si le digest DS ne correspond à aucun DNSKEY, les validateurs échoueront de manière consistante une fois les caches convergés.

3) Puis‑je simplement désactiver la validation DNSSEC pendant un incident ?

Vous le pouvez, mais faites‑le comme un brûlage contrôlé : limitez dans le temps, documentez, et comprenez ce que vous sacrifiez. Une meilleure mitigation d’urgence est souvent de réduire la taille EDNS UDP ou d’assurer que TCP/53 est autorisé — réparer le transport sans supprimer la validation.

4) Pourquoi les résolveurs publics réussissent‑ils alors que les nôtres échouent ?

Implémentations de résolveurs différentes, états de trust anchors différents, chemins réseau différents, et politiques différentes. Les résolveurs publics peuvent avoir une meilleure reachabilité anycast, un fallback TCP plus robuste, ou simplement ne pas être derrière vos règles de pare‑feu.

5) Que signifie réellement le drapeau `AD` ?

AD (Authenticated Data) est mis par un résolveur validant quand il estime que les données sont validées. Il peut être supprimé ou non selon la configuration. Traitez‑le comme un signal, pas comme l’évangile, et confirmez avec delv quand c’est important.

6) Baisser la taille EDNS UDP est‑ce « mauvais pour les performances » ?

Parfois cela augmente le fallback TCP, ce qui peut ajouter de la latence. Mais une réponse légèrement plus lente vaut mieux qu’une erreur aléatoire. Pour de nombreux chemins d’entreprise, une taille EDNS conservatrice est un choix pratique.

7) Comment la dérive d’heure peut‑elle causer seulement des échecs intermittents ?

Parce que les fenêtres de validité des RRSIG sont basées sur le temps, et différents RRsets ont des timings de signature différents. De plus, les caches et les retries peuvent masquer le problème jusqu’à ce que la signature d’un enregistrement particulier franchisse la frontière de décalage du validateur.

8) Quelle est la différence entre « insecure » et « bogus » ?

Insecure signifie qu’il n’y a pas de chaîne de confiance (pas de DS chez le parent). Le résolveur peut répondre sans validation. Bogus signifie qu’une chaîne est attendue mais qu’elle échoue (mauvaises signatures, mismatch DS/DNSKEY, etc.). Bogus doit échouer fermement.

9) Les flottes de résolveurs mixtes importent‑elles vraiment autant ?

Oui. Les valeurs par défaut diffèrent : comportement de cache, gestion des trust anchors, fallback TCP, et verbosité des logs. Si vous voulez un comportement prévisible, standardisez ou au moins documentez les différences et testez les deux chemins.

Conclusion : prochaines étapes à livrer cette semaine

DNSSEC ne tombe pas en panne de façon aléatoire. Votre système fait une excellente imitation du hasard quand des résolveurs, caches, horloges et réseaux différents ne sont pas d’accord.

Faites ceci :

Implémentez le playbook de diagnostic rapide. Mettez‑le dans votre runbook on‑call et faites de « dig +dnssec, dig +tcp, delv +rtrace » une habitude.
Standardisez les baselines des résolveurs. Même version, même gestion des trust anchors, même politique de taille EDNS, même niveau de logs en incident.
Choisissez une taille EDNS UDP conservatrice si vous opérez sur des réseaux hétérogènes. Ensuite mesurez le ratio TCP pour connaître le coût.
Surveillez les résultats de validation. Suivez les SERVFAIL par zone, pas seulement au total. Lancez des validations canaries quotidiennes de domaines critiques.
Soyez sérieux sur l’heure. Si vous faites tourner des validateurs, vous gérez des horloges. Faites de la dérive NTP une alerte, pas une note de bas de page.