DNSSEC : l’erreur de rollover qui fait tomber le web et les e-mails en même temps

février 15, 2026 • février 15, 2026 • Lecture : 29 min • Views: 0

Cet article vous a aidé ?

Quand DNSSEC tourne mal, le mode de défaillance est brutal : les résolveurs ne « ratent pas à moitié ». Ils valident, n’aiment pas ce qu’ils voient, et renvoient SERVFAIL. Votre site semble mort. Votre API semble morte. Et vos e-mails — souvent routés via les enregistrements MX et associés du même domaine — cessent d’arriver en silence.

Il s’agit d’une panne qui embrouille tout le monde parce que les serveurs d’origine sont en bon état, les load balancers sont au vert, et l’astreint regarde des tableaux de bord comme s’il avait été personnellement trahi par les maths. DNSSEC, c’est des maths. Ça tient des reçus.

Ce qui casse réellement quand DNSSEC casse

DNSSEC ne casse pas le « DNS » en tant que concept. Il casse la résolution pour les résolveurs qui valident. Ce détail compte parce que vos résolveurs récursifs internes, les FAI de vos clients et les résolveurs publics peuvent se comporter différemment au même instant. Certains valident. D’autres non. Certains sont mal configurés et valident « parfois » selon l’upstream. C’est ainsi que vous obtenez le pire type d’incident : partiel, dépendant de la géographie et du résolveur.

Quand votre domaine devient « bogus » (le terme DNSSEC pour « cryptographiquement invalide »), les résolveurs qui valident cessent de répondre. Ils renvoient SERVFAIL pour les enregistrements dans la zone affectée :

Le web casse parce que les requêtes A/AAAA échouent pour www ou l’apex.
L’API casse parce que la découverte de service cesse de fonctionner.
Le mail casse parce que les requêtes MX échouent, et les TXT pour SPF/DMARC peuvent aussi échouer ; certains MTA considèrent cela comme une erreur fatale ou différeront pendant des heures.
Les flux d’authentification cassent parce que les points de terminaison OIDC/SAML, les domaines de callback et les hôtes d’introspection de jetons partagent souvent la même zone.
L’émission de certificats casse parce que les challenges ACME dépendent du DNS ou de l’accessibilité HTTP qui commencent par la résolution DNS.

Il y a aussi une touche de comédie noire : vous pouvez toujours résoudre votre propre domaine depuis un portable en utilisant un résolveur non-validant et conclure « le DNS fonctionne ». C’est comme ça qu’on obtient le genre de post-mortem dont la cause racine est une capture d’écran.

Faits et contexte historique à utiliser en post-mortem

DNSSEC a de l’histoire, et une partie explique les angles opérationnels piquants d’aujourd’hui. Voici des faits concrets qui aident les équipes à prendre de meilleures décisions :

DNSSEC a été conçu dans les années 1990 après que des attaques de cache poisoning ont montré que le DNS avait besoin d’authenticité, pas seulement de disponibilité.
La zone racine a été signée en 2010, un jalon majeur qui a rendu la validation DNSSEC globale possible sans ancres de confiance personnalisées.
Le premier rollover du KSK racine a eu lieu en 2018, après des années de planification, de retards et de mesures soigneuses de l’état des résolveurs.
DNSSEC ne chiffre pas le DNS ; il le signe. La confidentialité est un autre sujet (maintenant géré par DoT/DoH au niveau transport).
DNSSEC augmente la taille des réponses, ce qui historiquement a augmenté le risque de fragmentation et déclenché des problèmes MTU/firewall — surtout avant que EDNS0 soit correctement géré.
NSEC et NSEC3 existent en partie parce qu’une négation d’existence authentifiée est requise ; il faut une façon signée de dire « ce nom n’existe pas ».
Les workflows registrar/registry pour DS varient, et de nombreux incidents ne sont pas causés par la cryptographie mais par des files de tickets, des bizarreries d’interface et des délais de propagation.
Les règles TTL et de cache dominent la durée d’un incident. Même après correction d’un DS, l’état cassé peut persister jusqu’à l’expiration des caches.
Certains systèmes de mail traitent les échecs DNS différemment : une erreur DNS transitoire peut devenir des heures de mails différés, puis un afflux de réessais, puis des pertes silencieuses si les files débordent.

Chaîne de confiance en termes opérationnels (pas de théâtre crypto)

Oubliez un instant les articles académiques. En production, DNSSEC est une chaîne d’approvisionnement :

La zone parente publie un enregistrement DS pour votre zone.
Votre zone enfant publie des enregistrements DNSKEY. L’un d’eux est la KSK (key-signing key), un ou plusieurs sont des ZSK (zone-signing keys). Dans de nombreuses implémentations ce sont juste des flags et des rôles opérationnels.
Les enregistrements de votre zone sont signés avec des RRSIG. Les validateurs vérifient les signatures avec les DNSKEY, et vérifient que le DNSKEY est autorisé en comparant les empreintes au DS dans la parente.

Le point : la parente cautionne l’enfant en publiant DS. Si DS et DNSKEY cessent de correspondre, les validateurs ne hausseront pas les épaules. Ils marquent la zone comme bogus et cessent de répondre.

La conséquence opérationnelle est simple et sévère : un rollover DNSSEC est un changement distribué impliquant au moins deux domaines administratifs (votre zone et la parente/registry), plus la couche de cache de l’internet entier. Voilà pourquoi « faire tourner les clés chaque semaine » n’est pas un signe de maturité ; c’est un signe que vous aimez les émotions évitables.

« L’espoir n’est pas une stratégie. » — Gene Kranz

L’erreur de rollover qui anéantit le web et le mail

Le scénario classique de meltdown est la séquence suivante :

Vous faites tourner la KSK ou changez les DNSKEY dans la zone.
Vous oubliez de mettre à jour le DS chez la parente, ou vous le mettez à jour incorrectement, ou la mise à jour est retardée.
Les résolveurs validants ne peuvent plus construire la chaîne de confiance depuis le DS parent jusqu’à votre DNSKEY.
Ils renvoient SERVFAIL pour les noms de votre zone.

Voilà la version simple. La version réaliste comporte plus de façons de vous faire mal :

Vous publiez un nouveau DNSKEY mais vous n’avez pas encore signé la zone correctement avec celui-ci (ou vous avez arrêté de publier les anciennes signatures trop tôt).
Vous avez mis à jour le DS, mais utilisé le mauvais type de digest ou le mauvais key tag parce que la sortie de votre outil a été mal interprétée.
Vous avez mis à jour le DS dans l’interface du registrar, mais l’UI l’a accepté tout en tronquant, reformatant ou en retardant silencieusement la soumission au registry.
Vous utilisez un fournisseur DNS qui automatise DNSSEC, et vous avez changé de fournisseur sans coordonner la suppression/ajout du DS.
Vous avez changé de serveurs de noms ou migré l’hébergement DNS en supposant que DNSSEC « se déplace avec la zone ». Ce n’est pas le cas sauf si vous reconstruisez la chaîne et coordonnez le DS.

Les rollovers DNSSEC sont aussi le moment où « le web et le mail meurent ensemble » devient littéral. Le web échoue parce que les clients ne peuvent pas résoudre A/AAAA. Le mail échoue parce que les expéditeurs ne peuvent pas résoudre MX et peuvent considérer cela comme une erreur temporaire, ce qui retarde le courrier et accumule des réessais. Pire encore, votre TXT _dmarc et les TXT SPF peuvent devenir introuvables, et selon la politique de l’expéditeur, l’absence peut modifier la délivrabilité de façon imprévisible.

Blague n°1 : DNSSEC est comme un videur qui vérifie les papiers au microscope. Super sécurité, jusqu’à ce que vous écriviez mal votre nom et soyez refusé à votre propre fête.

Pourquoi cette défaillance est si catastrophique : les validateurs échouent en fermé

DNSSEC est conçu pour protéger contre la falsification. Si les validateurs acceptaient des réponses « peut‑être valides », un attaquant pourrait exploiter l’incertitude. La validation est donc en mode fail-closed. Vos enregistrements sont soit signés correctement et chaînés au DS parent, soit considérés comme non fiables.

Ce n’est pas négociable et ce n’est pas « un bug des résolveurs ». C’est le but. Votre travail est de rendre les rollovers ennuyeux.

Les deux rollovers à distinguer : ZSK vs KSK

La plupart des équipes peuvent survivre à une erreur de rollover ZSK avec un rayon d’impact moindre parce que les changements ZSK ne requièrent pas la mise à jour du DS chez la parente (à condition que la KSK reste stable et que le RRset DNSKEY soit correctement signé). Les rollovers KSK, par définition, sont ceux qui nécessitent une coordination parentale.

Règle opérationnelle générale :

Rollover ZSK : votre zone, vos signatures, vos TTL. Majoritairement sous votre contrôle.
Rollover KSK : votre zone et la pipeline DS de la parente, plus le cache. Vous n’êtes plus le seul adulte dans la pièce.

Trois mini-récits d’entreprise depuis le terrain

Mini-récit 1 : L’incident de la mauvaise hypothèse

Une entreprise SaaS de taille moyenne a décidé de migrer son DNS autoritatif d’un fournisseur à un autre. Le plan projet incluait l’abaissement des TTL, la vérification de la parité des enregistrements, et le déplacement progressif des NS chez le registrar. Cela ressemblait à une opération scolaire — jusqu’à ce que la bascule provoque une pluie de tickets support : « site en panne », « impossible de se connecter », « emails rejetés ».

L’astreint a commencé par les suspects habituels : load balancers, WAF, certificats TLS. Tout était vert. Puis un client a envoyé une capture : SERVFAIL depuis le résolveur de son FAI. Cela a réduit le champ au DNS. Les résolveurs de bureau de la société fonctionnaient encore, parce que leurs résolveurs récursifs internes étaient configurés sans validation DNSSEC. La salle de crise a passé une heure à débattre pour savoir si DNSSEC « comptait vraiment » parce que « nous n’avons jamais eu de problèmes ».

L’hypothèse incorrecte était simple : l’équipe avait supposé que DNSSEC était « attaché au domaine » chez le registrar et continuerait de fonctionner après le déplacement des serveurs de noms. En réalité, la zone parente publiait encore un DS pointant vers la clé de l’ancien fournisseur. Le nouveau fournisseur servait un ensemble DNSKEY différent. Les validateurs voyaient un DS qui ne correspondait pas au DNSKEY enfant et échouaient en fermé.

La correction était tout aussi simple mais douloureuse sur le plan opérationnel : soit supprimer le DS (désactiver DNSSEC), soit publier le DNSKEY correct et mettre à jour le DS pour qu’il corresponde. La mise à jour de l’UI du registrar a mis du temps à atteindre le registry. Pendant cette fenêtre, les caches ont conservé l’état fautif. Le web était indisponible pour une partie d’internet ; les e-mails ont été mis en file puis livrés en retard, avec un arriéré qui a causé des douleurs secondaires en aval.

La leçon post-mortem essentielle n’était pas « faire attention au DNSSEC ». C’était : traiter les migrations d’hébergement DNS comme un commit en deux phases avec coordination DS. DNSSEC doit être explicitement déplacé, vérifié et surveillé. Ce n’est pas une case à cocher ; c’est une chaîne.

Mini-récit 2 : L’optimisation qui a mal tourné

Une équipe d’entreprise avait pour objectif de réduire la charge opérationnelle en automatisant la rotation des clés cryptographiques. Ils ont fixé un calendrier agressif — faire tourner les clés DNSSEC fréquemment, à l’heure. L’automatisation était impressionnante : pipelines, intégration HSM, alertes si des signatures manquaient. L’équipe en était fière. Elle aurait dû l’être. Puis la réalité est arrivée.

Les premières rotations, uniquement ZSK, se sont bien passées. Puis quelqu’un a « optimisé » en incluant la rotation KSK dans la même automatisation. Le script a généré de nouvelles clés et poussé des DNSKEY mis à jour au service autoritatif. Il a aussi utilisé l’API du registrar pour mettre à jour le DS. Mais l’API avait des bizarreries : elle acceptait un format de payload DS légèrement différent de ce que l’outil produisait. L’API a retourné un succès tout en stockant un DS malformé. La zone est devenue bogus pour les validateurs.

Le pire était le timing. L’automatisation s’exécutait la nuit. La mise à jour DS « a réussi » selon les logs, et le script a supprimé l’ancienne KSK tôt pour réduire le « bruit » des clés. La validation a cassé, et la voie de rollback n’était pas triviale car l’ancien matériel de clé avait déjà été retiré de l’emplacement HSM utilisé par le système. Tout existait encore, mais la restauration nécessitait un opérateur HSM et une fenêtre de changement. Pendant ce temps, l’internet public n’avait aucune sympathie.

L’équipe s’est stabilisée en adoptant un plan moins sexy : séparer la rotation ZSK de la rotation KSK, rendre la rotation KSK rare et manuelle-avec-contrôles, et exiger une validation externe depuis plusieurs résolveurs publics avant et après les changements DS. L’optimisation qui a échoué n’était pas l’automatisation en soi — c’était automatiser un workflow inter-organisationnel et dépendant des caches sans garde-fous pour le lien parent.

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

Un détaillant avec un fort trafic saisonnier avait une habitude dont personne ne se vantait : ils gardaient un runbook avec des captures d’écran de l’UI DS de leur registrar, les commandes exactes pour calculer DS depuis DNSKEY, et un calendrier pour les événements DNSSEC planifiés. Ils avaient aussi une politique permanente : ne pas toucher au DNSSEC pendant les semaines de pointe. Ennuyeux. Correct.

Un matin, leur fournisseur DNS a eu un problème qui a nécessité une migration d’urgence vers des serveurs de noms autoritatifs secondaires hébergés ailleurs. Cela aurait pu devenir un cauchemar DNSSEC. Au lieu de cela, l’équipe avait déjà une configuration DNS secondaire pré-publiée, y compris des zones signées sur les deux fournisseurs avec la même KSK, et ils avaient testé la validation des semaines plus tôt.

Pendant l’incident, ils ont changé les enregistrements NS chez la parente en minimisant l’impact des TTL. Parce que les clés DNSSEC et les signatures sont restées cohérentes et que le DS est resté valide, les validateurs n’ont jamais vu une chaîne cassée. Les clients n’ont pas rencontré de SERVFAIL généralisé. Le mail a continué de circuler. La seule vraie douleur a été le processus de changement lui-même, pas l’impact client.

La leçon : la discipline opérationnelle ennuyeuse bat la créativité. Si votre plan DNSSEC repose sur « on va juste réparer vite », vous avez déjà perdu.

Mode d’emploi pour un diagnostic rapide

Quand le web et le mail semblent morts tous les deux, vous n’avez pas le temps pour la philosophie. Vous avez besoin d’une boucle serrée qui vous dit si vous êtes face à une validation DNSSEC, une indisponibilité autoritative ou autre chose.

Première étape : identifier s’il s’agit d’une validation DNSSEC (pas juste du DNS)

Interrogez avec DNSSEC et cherchez SERVFAIL depuis un résolveur validant.
Comparez avec un chemin non-validant (ou désactivez explicitement la vérification dans la requête) pour confirmer que les enregistrements existent mais que la validation échoue.
Vérifiez le point de rupture de la chaîne : est-ce les signatures enfant, le DNSKEY ou le DS parent ?

Deuxième étape : confirmer si le DS parent correspond au DNSKEY enfant

Récupérez le DS depuis la vue parentale.
Récupérez le DNSKEY depuis les serveurs autoritatifs enfants.
Calculez le DS depuis le DNSKEY et comparez.

Troisième étape : décider de votre posture d’urgence

Si vous pouvez rapidement restaurer une chaîne valide : faites-le. Republiez l’ancien DNSKEY/signatures ou mettez à jour le DS correctement.
Si la mise à jour parentale prendra trop de temps : envisagez de désactiver temporairement DNSSEC en supprimant le DS chez la parente, mais traitez cela comme une décision de niveau incident avec approbation explicite et plan de réactivation.
Communiquez tôt : « les résolveurs validants sont impactés ; les non-validants peuvent fonctionner ; retards d’e-mails attendus. » Ce message réduit le bruit.

Blague n°2 : Le DNS, c’est l’annuaire; DNSSEC, c’est le notaire. Si le notaire fait grève, personne ne peut plus appeler personne.

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

Voici les tâches que je veux réellement que l’astreint exécute. Chacune contient : une commande, une sortie d’exemple, ce que cela signifie, et ce que vous décidez ensuite. Utilisez votre propre domaine et les noms des serveurs. L’idée, c’est le workflow.

Task 1: Check if a validating resolver returns SERVFAIL

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

; <<>> DiG 9.18.24 <<>> +dnssec www.example.com A @1.1.1.1
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 1203
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; Query time: 42 msec
;; SERVER: 1.1.1.1#53(1.1.1.1) (UDP)
;; WHEN: Tue Feb 04 10:12:01 UTC 2026
;; MSG SIZE  rcvd: 56

Ce que cela signifie : Un résolveur public validant ne peut pas fournir de réponse. SERVFAIL est cohérent avec une zone DNSSEC bogus, mais cela peut aussi venir d’autres échecs en amont.

Décision : Testez immédiatement depuis un second résolveur validant puis comparez avec un chemin non-validant.

Task 2: Compare against another validating resolver to rule out a single resolver issue

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

; <<>> DiG 9.18.24 <<>> +dnssec www.example.com A @8.8.8.8
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 5550
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; Query time: 31 msec
;; SERVER: 8.8.8.8#53(8.8.8.8) (UDP)

Ce que cela signifie : Plusieurs résolveurs validants échouent. Cela suggère fortement un problème de validation DNSSEC ou une indisponibilité autoritative généralisée.

Décision : Interrogez directement les serveurs autoritatifs pour vérifier si les enregistrements existent et si DNSKEY/RRSIG sont présents.

Task 3: Query authoritative nameserver directly for the record

cr0x@server:~$ dig www.example.com A @ns1.dns-provider.net +norecurse

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

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

Ce que cela signifie : Le serveur autoritatif a l’enregistrement et répond NOERROR. Donc « le DNS existe ». Le problème est probablement la validation (chaîne/signatures), pas des enregistrements manquants.

Décision : Récupérez ensuite le DNSKEY et les signatures depuis le serveur autoritatif.

Task 4: Fetch DNSKEY from authoritative and verify it’s being served

cr0x@server:~$ dig example.com DNSKEY @ns1.dns-provider.net +dnssec +norecurse

; <<>> DiG 9.18.24 <<>> example.com DNSKEY @ns1.dns-provider.net +dnssec +norecurse
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 3919
;; flags: qr aa; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1

;; ANSWER SECTION:
example.com. 300 IN DNSKEY 257 3 13 ( ...KSK_PUBLIC_KEY... ) ; key id = 20345
example.com. 300 IN DNSKEY 256 3 13 ( ...ZSK_PUBLIC_KEY... ) ; key id = 48711
example.com. 300 IN RRSIG DNSKEY 13 2 300 20260212000000 20260201000000 20345 example.com. ( ... )

Ce que cela signifie : Le RRset DNSKEY est présent et signé (RRSIG sur DNSKEY existe). Les valeurs key id / key tag sont importantes pour la comparaison DS.

Décision : Comparez le DS parent avec la digest de la KSK (flag 257). Si le DS ne correspond pas, vous avez trouvé la source du bazar.

Task 5: Fetch DS from the parent view

cr0x@server:~$ dig example.com DS @a.gtld-servers.net +norecurse

; <<>> DiG 9.18.24 <<>> example.com DS @a.gtld-servers.net +norecurse
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6421
;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; ANSWER SECTION:
example.com. 86400 IN DS 14567 13 2 8A1C5F2D1B3E1B4C4F...C0FFEE

Ce que cela signifie : La parente (TLD) publie le DS key tag 14567. Si votre KSK actuel porte le key tag 20345, ce désaccord est suspect (pas automatiquement faux, mais souvent problématique).

Décision : Calculez le DS à partir de la KSK que vous servez et comparez le digest / key tag.

Task 6: Compute DS from DNSKEY and compare with parent DS

cr0x@server:~$ dig example.com DNSKEY @ns1.dns-provider.net +dnssec +short > /tmp/example.com.dnskey
cr0x@server:~$ dnssec-dsfromkey -2 /tmp/example.com.dnskey
example.com. IN DS 20345 13 2 3B7F2E0B7C7C0C2B7A...BADA55

Ce que cela signifie : Le DS que vous avez calculé depuis la KSK actuellement servie (20345) ne correspond pas au DS parent (14567 … C0FFEE). C’est une chaîne de confiance rompue.

Décision : Soit restaurez l’ancienne KSK/DNSKEY qui correspond au DS publié, soit mettez à jour le DS chez la parente avec la nouvelle valeur. Choisissez selon ce qui est le plus rapide et le plus sûr.

Task 7: Prove the zone is “bogus” using a validator tool (Unbound)

cr0x@server:~$ unbound-host -D example.com

example.com has address 203.0.113.10 (secure)
example.com has no AAAA record (secure)

Ce que cela signifie : Si vous voyez (secure), la validation a réussi. Si vous voyez (bogus) ou des erreurs à propos de DS/DNSKEY, vous avez une défaillance DNSSEC.

Décision : Si c’est bogus : concentrez-vous sur DS/DNSKEY/signatures. Si c’est secure mais que vous avez encore des problèmes : vous faites face à un autre problème DNS ou applicatif.

Task 8: Check for missing or expired signatures on key records

cr0x@server:~$ dig example.com DNSKEY @ns1.dns-provider.net +dnssec +norecurse | sed -n '/RRSIG DNSKEY/,$p'

example.com. 300 IN RRSIG DNSKEY 13 2 300 20260212000000 20260201000000 20345 example.com. ( ... )

Ce que cela signifie : RRSIG a une date d’expiration et une date d’inception. Si l’expiration est passée (ou l’inception est dans le futur à cause d’un décalage d’horloge lors de la signature), les validateurs refusent.

Décision : Si les signatures sont expirées/non encore valables : lancez une re-signature avec le bon horaire et assurez la synchronisation des horloges du signateur.

Task 9: Check SOA serial and propagation across authoritative nameservers

cr0x@server:~$ for ns in ns1.dns-provider.net ns2.dns-provider.net; do dig example.com SOA @$ns +norecurse +short; done
ns1.dns-provider.net. hostmaster.example.com. 2026020401 3600 600 1209600 300
ns1.dns-provider.net. hostmaster.example.com. 2026020309 3600 600 1209600 300

Ce que cela signifie : Des SOA avec des numéros de série différents indiquent des versions de zone incohérentes entre serveurs autoritatifs. Avec DNSSEC, l’incohérence peut être fatale si les signatures/cles diffèrent.

Décision : Arrêtez les rollouts, corrigez votre distribution de zone/AXFR/pipeline CI, et assurez-vous que tous les serveurs autoritatifs servent des DNSKEY et des RRsets signés identiques avant de toucher au DS.

Task 10: Check if resolvers are getting truncated responses (TCP fallback issues)

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

;; Truncated, retrying in TCP mode.
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 53026
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1

Ce que cela signifie : Les réponses DNSKEY peuvent être volumineuses. La troncature est normale ; le fallback TCP doit fonctionner. Si des firewalls bloquent TCP/53, les validateurs peuvent échouer.

Décision : Si vous suspectez que TCP/53 est bloqué entre des résolveurs et vos serveurs autoritatifs, vérifiez la politique réseau et autorisez TCP/53.

Task 11: Validate MX resolution from a validating resolver

cr0x@server:~$ dig +dnssec example.com MX @9.9.9.9

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

Ce que cela signifie : Le routage des e-mails est impacté. Même si votre fournisseur de mail est sain, les expéditeurs ne peuvent pas découvrir où envoyer le courrier.

Décision : Lancez les comms clients : attendez-vous à des mails entrants différés. Si vous opérez des MTA, surveillez les files et le volume de mails différés.

Task 12: Check SPF and DMARC TXT resolution (deliverability side-effects)

cr0x@server:~$ dig +dnssec example.com TXT @1.1.1.1 +short
cr0x@server:~$ dig +dnssec _dmarc.example.com TXT @1.1.1.1 +short

Ce que cela signifie : Une sortie vide avec SERVFAIL (visible dans la sortie complète) signifie que les enregistrements de politique ne peuvent pas être récupérés. Certains expéditeurs considèrent cela comme une erreur temporaire ; d’autres réduisent l’application des politiques ; certains différeront.

Décision : Si DNSSEC est cassé, la correction de la validation passe avant tout. Ne « tunez pas DMARC » pendant une panne cryptographique.

Task 13: Confirm DS state via WHOIS-like tool output is not enough—use DNS

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

; <<>> DiG 9.18.24 <<>> example.com DS +trace
.			518400	IN	NS	a.root-servers.net.
...
com.			172800	IN	NS	a.gtld-servers.net.
...
example.com.		86400	IN	DS	14567 13 2 8A1C5F2D1B3E1B4C4F...C0FFEE

Ce que cela signifie : +trace montre le chemin de délégation et le DS réellement publié dans le DNS, pas ce qu’une interface de contrôle prétend.

Décision : Traitez le DNS comme la vérité. Si le panneau contredit, escaladez auprès du registrar/registry en incluant la sortie trace. Ne continuez pas à faire tourner les clés en attendant.

Task 14: For BIND operators—check signing status and key publication locally

cr0x@server:~$ rndc signing -list example.com
Done signing with key 20345/RSASHA256
Done signing with key 48711/RSASHA256

Ce que cela signifie : BIND pense que la zone est signée avec des clés spécifiques. Si cela diffère de ce que les serveurs autoritatifs publient, votre déploiement est incohérent.

Décision : En cas de désaccord : arrêtez et réconciliez. Assurez-vous que le matériel de clés et les fichiers de zone signés sont déployés de manière identique sur tous les nœuds autoritatifs.

Erreurs courantes : symptômes → cause racine → correction

Cette section doit prévenir votre prochaine panne. Ce ne sont pas des théories ; ce sont les motifs qui se répètent.

1) Symptom: SERVFAIL on validating resolvers; authoritative answers directly

Cause racine : Le DS ne correspond pas à la KSK DNSKEY enfant (ou le RRset DNSKEY n’est pas correctement signé).

Correction : Calculez le DS depuis la KSK active et mettez à jour la parente. Ou restaurez la KSK/DNSKEY antérieure qui correspond au DS publié. Ne devinez pas — comparez les digests.

2) Symptom: Works for some users, fails for others, flips over hours

Cause racine : Différences de cache et de TTL ; serveurs autoritatifs incohérents ; certains résolveurs ont épinglé un ancien DS/DNSKEY en cache.

Correction : Assurez-vous que tous les serveurs autoritatifs servent des données signées et des clés identiques. Attendez l’expiration des TTL. En urgence : réparez rapidement la chaîne ; puis laissez les caches converger.

3) Symptom: DNSKEY queries are slow or time out; lots of TCP retries

Cause racine : Fragmentation UDP ou TCP/53 bloqué ; réponses DNSSEC surdimensionnées ; middleboxes mal gérant EDNS.

Correction : Autorisez TCP/53 vers les serveurs autoritatifs. Ajustez la taille des réponses via EDNS. Évitez des politiques réseau qui traitent TCP/53 comme suspect.

4) Symptom: Suddenly bogus after a “routine” resign

Cause racine : Décalage d’horloge du signateur ou fenêtres de validité des signatures incorrectes provoquant des RRSIG non valides.

Correction : Corrigez le NTP. Re-signez. Vérifiez les temps RRSIG depuis l’autoritatif avec dig.

5) Symptom: Email bounces or defers while web seems “mostly fine”

Cause racine : Les recherches MX et TXT échouent pour les résolveurs validants ; les clients web peuvent utiliser du DNS mis en cache ou des résolveurs non-validants ; les MTA sont plus stricts sur les échecs répétés.

Correction : Validez MX/TXT spécifiquement depuis les principaux résolveurs validants. Communiquez les attentes de délai. Réparez la chaîne DNSSEC.

6) Symptom: Outage immediately after DNS provider migration

Cause racine : Le DS pointe encore vers la clé de l’ancien fournisseur ; le nouveau fournisseur sert des DNSKEY différents.

Correction : Planifiez les migrations avec DNSSEC : soit conservez la KSK stable entre fournisseurs (si pris en charge), soit coordonnez la mise à jour du DS comme étape de cutover avec des validations.

7) Symptom: Zone is secure, but only a specific record type fails (e.g., TXT)

Cause racine : Signature sélective manquante ou chaîne NSEC/NSEC3 cassée pour la négation d’existence ; ou signature incohérente de cet RRset entre nœuds.

Correction : Vérifiez que l’RRset a une RRSIG et que les preuves de non-existence sont cohérentes. Re-signez la zone entière ; assurez un déploiement cohérent.

8) Symptom: Panel shows DS updated, but trace still shows old DS

Cause racine : Le registrar a accepté l’entrée mais ne l’a pas soumise au registry, ou la fenêtre de mise à jour du registry est retardée, ou la délégation mise à jour est incorrecte (comptes/registrars multiples).

Correction : Utilisez dig +trace comme vérité. Escaladez auprès du registrar en incluant la sortie trace. N’appelez pas encore la rotation des clés pendant l’attente.

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

Plan de rollback d’urgence (quand vous êtes déjà en feu)

Confirmez la défaillance de validation DNSSEC avec deux résolveurs validants en utilisant dig +dnssec.
Interrogez directement l’autoritatif pour confirmer que les enregistrements existent et isoler la validation.
Comparez DS et DNSKEY en utilisant dnssec-dsfromkey et une requête DS depuis la parente.
Choisissez la voie de réparation la plus rapide et la plus sûre :
- Si vous avez toujours l’ancienne KSK et pouvez la servir : republiez-la et ses signatures afin qu’elle corresponde au DS parent.
- Si le DS parent peut être mis à jour rapidement et de façon fiable : mettez à jour le DS vers le nouveau digest KSK et vérifiez via dig +trace.
- Si ni l’un ni l’autre n’est rapide : retirez le DS pour désactiver temporairement DNSSEC, documentez la décision et planifiez la réactivation.
Validez après le changement en utilisant unbound-host -D ou équivalent, et plusieurs résolveurs publics.
Surveillez les files de mails et les réessais. Attendez‑vous à une vidange progressive même après la correction à cause du comportement de retry des expéditeurs.

Rollover KSK planifié : le runbook ennuyeux mais correct

Inventoriez vos dépendances : méthode de mise à jour DS du registrar, délais du registry, capacités du fournisseur DNS, usage de CDS/CDNSKEY, et qui a accès.
Abaissez les TTL à l’avance pour DNSKEY et les RRsets concernés si votre plateforme le permet en toute sécurité. Faites-le des jours à l’avance, pas des minutes.
Pré-publiez la nouvelle KSK (publiez le nouveau DNSKEY parallèlement à l’ancien). Ne supprimez pas l’ancien tout de suite.
Signez correctement le RRset DNSKEY pour que les validateurs puissent faire confiance à la nouvelle clé quand le DS changera.
Calculez le DS pour la nouvelle KSK et faites vérifier par une seconde personne le key tag, l’algorithme, le type de digest et le hex digest.
Mettre à jour le DS chez la parente et suivre la publication réelle dans le DNS via dig +trace.
Patientez les fenêtres de TTL et de propagation. Ce n’est pas de la bureaucratie ; c’est de la physique de cache.
Ne retirez l’ancienne KSK qu’ensuite après vous être assuré que le nouveau DS est publié universellement et que la validation est stable chez les résolveurs.
Vérification post-roll : validez A/AAAA, MX, TXT, DNSKEY, et un nom inexistant (pour tester le comportement NSEC/NSEC3) depuis plusieurs résolveurs validants.

Rollover ZSK planifié : gardez‑le routinier

Pré-publiez la nouvelle ZSK dans le RRset DNSKEY.
Commencez à signer avec les deux ZSK (double-sign) pendant la transition si pris en charge.
Après que les caches aient évacué les anciennes signatures, cessez de signer avec l’ancienne ZSK.
Retirez l’ancienne ZSK après un délai de sécurité.

FAQ

1) Pourquoi un échec DNSSEC apparaît‑il comme SERVFAIL au lieu de NXDOMAIN ?

SERVFAIL signifie que le résolveur n’a pas pu produire une réponse valide. Avec DNSSEC, « j’ai reçu des données mais elles n’ont pas validé » est traité comme une défaillance, pas comme « le nom n’existe pas ». NXDOMAIN est une affirmation signée sur la non-existence ; SERVFAIL signifie « je ne peux rien garantir ici ».

2) Si je désactive DNSSEC en retirant le DS, tout reviendra‑t‑il instantanément ?

Non. Certains résolveurs gardent en cache des états d’échec et des réponses négatives. Vous verrez en général une amélioration rapide, mais la récupération complète dépend des TTL et du comportement des résolveurs. Préparez‑vous à une queue résiduelle.

3) Pourquoi le web et le mail échouent‑ils ensemble ?

Ils partagent la même zone DNS. Le web a besoin de A/AAAA. Le mail a besoin de MX et généralement de TXT pour SPF/DMARC. Si les résolveurs validants ne peuvent résoudre aucune de ces entrées à cause d’un DNSSEC bogus, les deux canaux se dégradent simultanément.

4) Est‑ce seulement un problème de rollover KSK ?

Les rollovers KSK sont le scénario le plus susceptible de « tout péter » parce que le DS doit correspondre à la KSK. Mais les rollovers ZSK peuvent aussi casser la validation si les signatures sont incohérentes, expirées ou mal déployées sur l’ensemble des serveurs autoritatifs.

5) Puis‑je me fier à la fonctionnalité « DNSSEC automatique » de mon fournisseur DNS ?

Vous pouvez, mais seulement si vous faites aussi confiance et comprenez comment le DS est géré chez la parente. Une automatisation qui s’arrête à la frontière de la zone n’est pas de l’automatisation ; c’est un pont à moitié construit. Exigez de la visibilité : key tags, types de digest, et contrôles de validation.

6) Qu’en est‑il de CDS/CDNSKEY — cela peut‑il prévenir les erreurs DS ?

Ça peut réduire les erreurs humaines si votre registrar/registry le supporte correctement et si vous comprenez le timing de publication. Cela peut aussi amplifier les erreurs si votre signateur publie un mauvais CDS/CDNSKEY et que la parente l’accepte. Traitez‑le comme toute autre automatisation : vérifiez.

7) Comment tester comme un client, pas comme un ingénieur avec des résolveurs spéciaux ?

Utilisez plusieurs résolveurs publics validants, et testez depuis des réseaux que vous ne contrôlez pas (ou au moins des piles récursives différentes). Testez aussi les enregistrements web et mail : A/AAAA, MX, TXT et DNSKEY.

8) Pourquoi le mail a continué d’échouer après que le DNS ait été réparé ?

Parce que le mail est store-and-forward. Les expéditeurs réessayeront en cas d’échecs temporaires, souvent avec backoff. Une fois le DNS rétabli, les files se vident sur des heures. Si la panne a duré longtemps, certains expéditeurs peuvent avoir abandonné ou atteint des limites de file.

9) Quelle est la manœuvre « break glass » la plus sûre ?

La mesure la plus rapide et la plus sûre consiste généralement à restaurer le dernier jeu de DNSKEY/signatures connu bon qui correspond au DS publié. Retirer le DS désactive DNSSEC et peut être efficace, mais c’est une régression de sécurité et doit être limitée dans le temps et suivie précisément.

10) Comment éviter le syndrome « ça marche pour moi » pendant les incidents DNSSEC ?

Assurez‑vous que vos résolveurs récursifs internes valident DNSSEC (ou au moins qu’un chemin de vérification existe). Si votre propre environnement ne valide pas, vous êtes aveugle à toute une classe de pannes clients.

Prochaines étapes à faire cette semaine

DNSSEC n’est pas difficile parce que la cryptographie est compliquée. C’est difficile parce que vous coordonnez de l’état entre organisations et caches. Faites donc les choses ennuyeuses qui rendent la coordination survivable :

Rendez la validation visible en interne : faites tourner au moins un résolveur validant de confiance, et intégrez un check one-liner dans vos outils d’incident pour dig +dnssec contre celui-ci.
Rédigez votre runbook DNSSEC : incluez la méthode de mise à jour DS, comment calculer le DS depuis DNSKEY, les noms des serveurs autoritatifs et les options de rollback.
Entraînez‑vous sur une zone non production : faites une répétition complète d’un rollover KSK où vous mettez réellement à jour le DS chez la parente et validez depuis des résolveurs publics.
Ajoutez de la supervision qui vérifie le statut « secure » : pas seulement « est-ce que A résout », mais « est‑ce que ça résout comme secure depuis des résolveurs validants ».
Séparez les processus ZSK et KSK : faites tourner la ZSK de façon routinière si nécessaire, et traitez les rollovers KSK comme des maintenances planifiées avec des gates explicites.
Arrêtez de migrer le DNS sans plan DNSSEC : si un plan de projet ne mentionne pas le DS, il est incomplet.

Si vous ne retirez qu’une leçon : les rollovers DNSSEC sont de la gestion du changement, pas de la crypto. Vos clés peuvent être parfaites et vous pouvez quand même faire tomber votre activité avec un DS non assorti. Faites de la chaîne de confiance une dépendance de production de premier ordre, parce que l’internet l’est déjà.