Comment fonctionne DNSSEC — KSK, ZSK, DS, DNSKEY, RRSIG, NSEC expliques

DNSSEC authentifie les donnees DNS via une hierarchie de signatures cryptographiques qui s'enchaine d'un enregistrement de votre zone jusqu'a un point d'ancrage de confiance code en dur dans chaque resolveur validant. Ce guide parcourt les pieces mobiles — DNSKEY, DS, RRSIG, NSEC/NSEC3, et les roles KSK/ZSK — a un niveau qui vous permet de raisonner sur des deploiements reels sans etre cryptographe.

Pour les procedures operationnelles de rotation (pre-publish ZSK, double-signature KSK, rotation d'algorithme), continuez avec Gestion des cles DNSSEC. Pour l'introduction de haut niveau sans la mecanique, la page Qu'est-ce que DNSSEC ? est un meilleur point de depart.

Les enregistrements impliques

DNSSEC introduit quatre types d'enregistrements dans une zone signee, plus les enregistrements DS publies a la zone parente :

Cles de signature : KSK, ZSK, CSK

DNSSEC a historiquement utilise une separation a deux cles : une KSK pour des operations a forte valeur et faible frequence, et une ZSK pour des operations a haute frequence et plus faible ceremonie. La motivation est purement operationnelle — cryptographiquement, les deux cles font la meme chose (signer des donnees avec une cle privee, verifier avec une cle publique).

Zone-Signing-Key (ZSK)

La ZSK signe tout dans votre zone sauf le set d'enregistrements DNSKEY. Quand un resolveur demande les enregistrements A de example.com, la reponse revient avec un RRSIG correspondant signe par la ZSK. Chaque set d'enregistrements signe a son propre RRSIG.

Les ZSK sont typiquement :

• Plus petites (RSA 1024 bits etait courant dans les premiers deploiements ; ECDSA P-256 / 256 bits est la norme moderne)
• Tournees relativement souvent (toutes les 1–3 mois historiquement ; certains operateurs sautent maintenant les rotations planifiees avec un stockage de cles fort)
• Plus faciles a tourner parce que l'enregistrement DS de la zone parente n'a pas a changer

Key-Signing-Key (KSK)

La KSK signe uniquement le set d'enregistrements DNSKEY. Ce set contient la partie publique de chaque cle de signature active dans la zone. En signant le set DNSKEY avec la KSK, vous liez chaque autre cle dans la zone (notamment chaque ZSK active) a une cle dont le hash est publie a la zone parente.

Les KSK sont typiquement :

• Plus grandes (RSA 2048 bits, ECDSA P-256, ou Ed25519 sont tous courants)
• Tournees rarement (tous les 1–5 ans, ou seulement en cas de compromission suspecte)
• Plus couteuses a tourner parce que l'enregistrement DS chez le parent doit etre mis a jour, ce qui implique le registrar et la temporalite TLD

Combined Signing Key (CSK)

Une CSK joue les deux roles dans une seule cle. La meme cle signe DNSKEY (role KSK) et les autres sets d'enregistrements (role ZSK). Les deploiements modernes utilisent de plus en plus CSK avec ECDSA P-256 ou Ed25519, parce que :

• Les signatures sont assez petites pour que le cout par requete soit negligeable
• La complexite operationnelle est moindre (une cle a gerer, une rotation a coordonner)
• Le stockage adosse a un HSM reduit l'argument de securite pour separer KSK et ZSK

DNScale utilise par defaut CSK avec ECDSA P-256 pour les nouvelles zones, ce qui est le standard pour la plupart des fournisseurs manages modernes.

DNSKEY : Publier des cles publiques dans la zone

Chaque cle de signature active a sa partie publique publiee comme enregistrement DNSKEY a la racine de la zone :

example.com.   3600   IN   DNSKEY   257 3 13 oJMR...                        ; KSK
example.com.   3600   IN   DNSKEY   256 3 13 mZXp...                        ; ZSK

Decodage des champs :

• Drapeaux (257 ou 256) : le bit 7 (SEP — Secure Entry Point) est positionne sur la KSK, donnant 257. La ZSK a 256. Les deux formats partagent aussi le bit 8 (Zone Key) qui est toujours positionne dans DNSKEY.
• Protocole (3) : toujours 3 dans un DNSSEC valide.
• Algorithme (13 ici) : 13 = ECDSA P-256, 8 = RSA SHA-256, 15 = Ed25519. Voir IANA DNSSEC algorithms pour la liste complete.
• Cle publique (encodee en base64) : le materiel de cle reel.

Un resolveur validant recupere le set DNSKEY lors de la validation d'un enregistrement de votre zone, et utilise la cle appropriee (KSK pour le RRSIG du DNSKEY lui-meme, ZSK pour tout le reste).

RRSIG : Les signatures

Chaque set d'enregistrements signe dans votre zone est accompagne d'un ou plusieurs RRSIG — un par cle de signature active pour ce role. Un RRSIG ressemble a ceci :

example.com.   3600   IN   A      192.0.2.1
example.com.   3600   IN   RRSIG  A 13 2 3600 20260601000000 20260501000000 12345 example.com. 4kQp...

Champs RRSIG :

• Type couvert (A) : le type du set d'enregistrements signe.
• Algorithme (13) : doit correspondre a l'algorithme du DNSKEY.
• Labels (2) : nombre de labels du nom signe initial.
• TTL d'origine (3600) : la TTL que le set avait lors de la signature.
• Expiration de signature (20260601000000) et debut (20260501000000) : timestamps UTC. La signature n'est valide que dans cette fenetre.
• Tag de cle (12345) : identifiant court indiquant quelle DNSKEY de la zone a produit cette signature. Correspond au tag de la DNSKEY associee.
• Nom du signataire (example.com.) : la zone dont la cle a signe.
• Signature (encodee base64) : la signature cryptographique reelle.

Les fenetres d'expiration des signatures sont la raison pour laquelle DNSSEC est non-trivial operationnellement. Si votre serveur autoritaire arrete de re-signer la zone — meme brievement —, les signatures vont commencer a expirer, les resolveurs validants vont commencer a renvoyer SERVFAIL, et votre domaine sera de fait hors ligne. Les fournisseurs DNS manages re-signent automatiquement ; le DNSSEC auto-heberge necessite un pipeline de signature operationnel.

Enregistrements DS : Le lien vers le parent

L'enregistrement DS (Delegation Signer) est la charniere qui relie votre zone a la chaine de confiance globale. Il vit dans la zone parente (.com, .eu, .de, etc.) et contient un hash de votre KSK. Vous ne l'ajoutez pas a votre propre zone — vous le publiez chez votre registrar, qui le transmet au registry TLD.

Un enregistrement DS dans la zone parente ressemble a :

example.com.   86400   IN   DS   12345 13 2 7c89...

Champs :

• Tag de cle (12345) : identifiant indiquant quelle KSK ce DS hashe (correspond au tag DNSKEY).
• Algorithme (13) : doit correspondre a l'algorithme du DNSKEY.
• Type de digest (2) : SHA-256 (2) ou SHA-384 (4) — SHA-1 (1) est obsolete.
• Digest (encode en hex) : le hash reel.

Quand un resolveur validant veut authentifier votre zone, il recupere l'enregistrement DS au parent (par ex. depuis les serveurs .com), recupere votre set DNSKEY, calcule le hash de la KSK correspondante, et verifie qu'il egale le digest du DS. S'ils correspondent, le resolveur fait confiance au set DNSKEY de votre zone, et par extension aux RRSIG signes avec ces cles.

C'est le seul lien automatise depuis l'exterieur de votre zone vers le materiel de cle de votre zone. Un DS errone et la validation DNSSEC echoue — ou pire, votre domaine devient irresolu pour les clients validants.

NSEC et NSEC3 : Negation authentifiee

Un probleme subtil mais important : DNSSEC ne peut pas seulement signer les enregistrements qui existent. Il faut aussi prouver, quand un resolveur demande nonexistent.example.com, que le nom n'existe vraiment pas plutot que la reponse soit silencieusement perdue ou forgee.

Le mecanisme est NSEC (RFC 4034) ou NSEC3 (RFC 5155).

NSEC

Les enregistrements NSEC sont tries alphabetiquement et chainent les noms qui existent dans la zone. Par exemple :

alpha.example.com.    NSEC  gamma.example.com.   A NSEC RRSIG
gamma.example.com.    NSEC  zulu.example.com.    A NSEC RRSIG
zulu.example.com.     NSEC  alpha.example.com.   A NSEC RRSIG     ; reboucle au debut

Un resolveur demandant beta.example.com recoit le NSEC signe pour alpha.example.com, qui prouve qu'il n'y a rien entre alpha et gamma — donc beta n'existe pas. La signature sur le NSEC authentifie la reponse negative.

L'inconvenient : les NSEC enumerent publiquement chaque nom dans la zone. Quiconque parcourt la chaine NSEC peut construire une liste complete des noms d'enregistrements. C'est le "zone walking" et c'est parfois considere comme une fuite de confidentialite.

NSEC3

NSEC3 enregistre la meme chaine mais utilise des noms hashes au lieu des noms en clair, plus un nombre d'iterations et un sel :

< hash de alpha >.example.com.    NSEC3 1 0 10 abcd123...    < hash de gamma > A RRSIG NSEC3

Les resolveurs peuvent verifier la negation comme avant (calculer le hash du nom interroge, trouver le NSEC3 qui le couvre), mais un attaquant ne peut pas trivialement parcourir la zone — il devrait casser chaque hash. NSEC3 prend aussi en charge l'opt-out, qui permet aux registries de ne pas signer les delegations non signees pour eviter de devoir NSEC3-signer toute sous-zone inexistante.

Recommandation moderne : NSEC3 avec iterations=0 et un sel fixe (ou pas de sel). Les nombres eleves d'iterations ajoutent du cout CPU sans benefice de confidentialite significatif parce que les attaquants avec GPU peuvent casser n'importe quel compte non-zero. L'approche "white lies" (RFC 4470) est une autre facon de reduire le risque de zone walking tout en gardant la simplicite de NSEC.

Le flux de validation — Pas a pas

Que se passe-t-il reellement lorsqu'un resolveur validant recoit une reponse signee DNSSEC ? En parcourant dig +dnssec example.com @1.1.1.1 :

1. Le resolveur recoit l'enregistrement A + RRSIG de votre serveur autoritaire.
2. Le resolveur recupere le set DNSKEY de votre zone + RRSIG. Il a maintenant a la fois les donnees et les cles (sous forme publique) necessaires pour tout verifier.
3. Le resolveur verifie le RRSIG des donnees contre la ZSK dans le set DNSKEY. Si la signature est invalide, la validation echoue immediatement.
4. Le resolveur verifie le RRSIG du DNSKEY contre la KSK dans le set DNSKEY. La KSK a signe le set DNSKEY, y compris la ZSK. Cette etape verrouille la ZSK a la KSK.
5. Le resolveur recupere l'enregistrement DS de la zone parente (par ex. depuis les serveurs .com). Le DS contient un hash de la KSK.
6. Le resolveur calcule le hash de la KSK et le compare au DS. S'ils correspondent, le parent a confirme quelle KSK fait autorite pour votre zone.
7. Le resolveur repete la chaine au parent. L'enregistrement DS lui-meme est signe par la ZSK de la zone parente ; le set DNSKEY de la parente est signe par la KSK de la parente ; la KSK de la parente est hashee dans le DS de la grand-parente, et ainsi de suite, jusqu'a la racine.
8. A la racine, le resolveur compare le hash de la KSK racine au point d'ancrage de confiance code en dur (ou auto-mis a jour via RFC 5011). La KSK racine actuelle est publiee a https://data.iana.org/root-anchors/.

Si chaque signature verifie et que la racine remonte au point d'ancrage de confiance, le resolveur renvoie la reponse avec le drapeau AD (Authenticated Data) positionne. Toute defaillance en cours de route et le resolveur renvoie SERVFAIL — mieux casser que de servir une reponse potentiellement alteree.

Ce qui peut mal tourner

Les deux premiers — DS perime et signatures expirees — causent la grande majorite des pannes DNSSEC reelles. Les fournisseurs manages gerent automatiquement la re-signature ; l'enregistrement DS chez le registrar est le point de defaillance manipulable par l'humain.

Pour synthese — Un modele mental

L'apparente complexite de DNSSEC est principalement de la comptabilite. La vraie question cryptographique est simple : cette reponse vient-elle de quelqu'un qui controle la cle privee de la zone ? La chaine de confiance est une serie de liaisons cle publique, chacune un simple "cle A signe cle B" ou "cle A signe donnees D" :

• La KSK racine signe le set DNSKEY racine (qui inclut la ZSK racine).
• La ZSK racine signe les enregistrements DS des TLD.
• La KSK d'un TLD signe le set DNSKEY du TLD (qui inclut la ZSK du TLD).
• La ZSK du TLD signe les enregistrements DS des zones enregistrees.
• La KSK de votre zone signe votre set DNSKEY (qui inclut votre ZSK).
• Votre ZSK signe chaque set d'enregistrements de votre zone — y compris les NSEC/NSEC3 qui gerent la negation.

Chaque maillon n'est qu'une signature ; la magie est que le resolveur n'a besoin que de la cle racine pour tout verifier.

References

• RFC 4033 — Introduction et exigences DNS Security
• RFC 4034 — Resource Records pour les DNS Security Extensions (DNSKEY, DS, NSEC, RRSIG)
• RFC 4035 — Modifications de protocole pour les DNS Security Extensions
• RFC 5155 — DNSSEC Hashed Authenticated Denial of Existence (NSEC3)
• RFC 6781 — DNSSEC Operational Practices, Version 2
• RFC 7344 / 8078 — Automating DNSSEC Delegation Trust Maintenance (CDS / CDNSKEY)
• RFC 8624 — Algorithm Implementation Requirements and Usage Guidance for DNSSEC
• RFC 8901 — Modeles DNSSEC multi-signataires
• Numeros d'algorithmes DNSSEC IANA
• Points d'ancrage de confiance racine IANA

Lectures complementaires

• Qu'est-ce que DNSSEC ? — introduction haut de l'entonnoir
• Gestion des cles DNSSEC — procedures operationnelles de rotation
• Guide d'installation DNSSEC pour DNScale — pas-a-pas produit
• DNSSEC vs DNS over HTTPS — integrite vs confidentialite
• Empoisonnement de cache DNS — l'attaque que DNSSEC contre
• NIS2 et conformite DNS — DNSSEC comme controle reglementaire