DNSSEC : chaîne de confiance de la racine à ce domaine

Le DNS a été conçu en 1983 sans aucune authentification. Un résolveur demande « où est lepro.dev ? » et fait confiance à la première réponse reçue. C’est un problème : quiconque se trouvant sur le chemin réseau — ou capable d’empoisonner le cache d’un résolveur — peut forger une réponse et rediriger le trafic vers un serveur malveillant. DNSSEC corrige cela en ajoutant des signatures cryptographiques aux enregistrements DNS, mais le mécanisme est plus subtil que « signez tout ».

Le défi fondamental est l’amorçage de la confiance. Si un serveur de noms signe ses enregistrements, comment le résolveur sait-il qu’il utilise la bonne clé publique ? DNSSEC résout cela avec une chaîne de confiance qui part de la racine DNS et délègue vers le bas : la racine valide les TLD, les TLD valident les domaines, et les domaines signent leurs propres enregistrements. Chaque maillon est un enregistrement DS (Delegation Signer) publié dans la zone parente — une poignée de main cryptographique qui dit « la clé de cette zone enfant est légitime ».

Le diagramme ci-dessous montre les trois niveaux pour lepro.dev : racine, TLD .dev et la zone elle-même — avec les types d’enregistrements spécifiques à chaque niveau et le flux de confiance descendant.

Comment fonctionne la validation

Lorsqu’un résolveur validant DNSSEC (comme 1.1.1.1 ou 8.8.8.8) interroge lepro.dev, il ne se contente pas d’accepter l’enregistrement A. Il demande le RRSIG (signature) accompagnant l’enregistrement et remonte la chaîne. Le résolveur possède déjà la KSK (Key Signing Key) racine codée en dur — c’est l’ancre de confiance. Il utilise la DNSKEY racine pour vérifier le DS de .dev, puis la DNSKEY de .dev pour vérifier le DS de lepro.dev, et enfin la DNSKEY de lepro.dev pour vérifier le RRSIG sur l’enregistrement A/AAAA.

Si un maillon se brise — signature expirée, enregistrement DS incohérent, DNSKEY manquante — le résolveur retourne SERVFAIL. C’est voulu : une chaîne brisée est traitée comme une attaque potentielle, pas comme un service dégradé. C’est pourquoi une mauvaise configuration DNSSEC est plus dangereuse que l’absence de DNSSEC. Une zone sans DNSSEC n’a simplement pas de signatures à vérifier ; une zone DNSSEC cassée échoue activement à la validation.

Activer DNSSEC avec Pulumi

Cloudflare sépare DNSSEC en deux parties : la signature de zone (gérée automatiquement par Cloudflare en périphérie) et la propagation de l’enregistrement DS (qui relie la zone signée au TLD parent). Une seule ressource Pulumi active la signature de zone :

const dnssec = 
new cloudflare.ZoneDnssec(
“lepro-dnssec”, {

 zoneId: zoneId,

});

export const dnssecDs = dnssec.ds;

export const dnssecDigest = dnssec.digest;
export const dnssecKeyTag = dnssec.keyTag;

Cela crée la paire DNSKEY (algorithme 13, ECDSA P-256), commence à signer tous les enregistrements avec des RRSIG, et publie les enregistrements CDS/CDNSKEY. Les outputs exportés contiennent l’enregistrement DS qui doit atteindre la zone parente :

$ pulumi stack output dnssecDs
lepro.dev. 3600 IN DS 2371 13 2 4B6EFA5C9B894…55B1AE35F

Pour les domaines enregistrés via Cloudflare Registrar (comme lepro.dev), la propagation du DS vers le TLD parent est automatique — Cloudflare scanne les enregistrements CDS publiés et pousse le DS vers le registre. Ce processus prend 24 à 48 heures. Pour les domaines enregistrés ailleurs, copiez l’enregistrement DS depuis les outputs Pulumi et ajoutez-le manuellement chez le registrar.

Parcourir la chaîne avec dig

Une fois DNSSEC entièrement propagé, vous pouvez parcourir la chaîne avec dig pour vérifier chaque niveau. Chaque étape interroge un type d’enregistrement spécifique à un niveau précis de la hiérarchie DNS, traçant la confiance de la racine jusqu’à lepro.dev.

Étape 1 — DNSKEY racine (ancre de confiance). La zone racine publie sa KSK (flag 257) et sa ZSK (flag 256). La KSK est codée en dur dans chaque résolveur validant — c’est le point de départ de toute confiance DNSSEC :

$ dig . DNSKEY +short | head -1

257 3 8 
AwEAAaz/tAm8yTn4Mfeh5eyI96WSVexTBAvkMgJzkKTO…

Étape 2 — La racine signe .dev. La racine publie un enregistrement DS pour le TLD .dev. Ce DS contient un hash SHA-256 (type de digest 2) de la KSK de .dev — le relais cryptographique de la racine au TLD :

$ dig dev. DS +short 
@a.root-servers.net.
60074 8 2 
B942E2CE5AEBF62FCA59D05707E6DBB795211D54…33424785

Étape 3 — DNSKEY de .dev. Le TLD .dev publie sa propre paire de clés (algorithme 8, RSA/SHA-256). Un résolveur vérifie que le hash de la KSK correspond au DS de l’étape 2 :

$ dig dev. DNSKEY +short

257 3 8 
AwEAAYtM84o4wEWfgE0ywuvg89cB3uHoH705EtMkp4Xp…

256 3 8 
AwEAAcbVHY7e2c1yEiSbarJwEUdUID0E1yKLix2VTTD+…

Étape 4 — .dev signe lepro.dev. Le TLD .dev publie un enregistrement DS pour lepro.dev, contenant un hash de la KSK de lepro.dev. C’est l’enregistrement que Cloudflare Registrar propage vers Google Registry :

$ dig lepro.dev DS +short 
@ns-tld1.charlestonroadregistry.com.
2371 13 2 
4B6EFA5C9B8940B56891AF2618DB5C5FB2EDFEF4…55B1AE35F

Étape 5 — DNSKEY de lepro.dev. Cloudflare génère et publie une KSK et une ZSK pour la zone en ECDSA P-256 (algorithme 13) — des clés plus courtes que RSA mais tout aussi robustes :

$ dig lepro.dev DNSKEY +short

257 3 13 
mdsswUyr3DPW132mOi8V9xESWE8jTo0dxCjjnopKl+Gq…

256 3 13 
oJMRESz5E4gYzS/q6XDrvU1qMPYIjCWzJaOau8XNEZeq…

Étape 6 — Enregistrement A signé. Cloudflare signe chaque réponse DNS avec la ZSK. Le RRSIG accompagne les enregistrements A :

$ dig lepro.dev A +dnssec +short 
@8.8.8.8
172.67.143.204
104.21.39.83
A 13 2 300 20260226113258 20260224093258 34505 lepro.dev. 
vUzo0mtx…

Lorsque la chaîne complète est en place, les réponses des résolveurs publics incluent le flag ad (Authenticated Data) — preuve que chaque maillon de la racine au domaine a été vérifié cryptographiquement :

$ dig lepro.dev A +dnssec @8.8.8.8 | grep flags
;; flags: qr rd ra ad;    ← authentifié

Gestion des clés

Chaque zone DNSSEC maintient deux paires de clés. La Key Signing Key (KSK) ne signe que le jeu d’enregistrements DNSKEY — c’est la clé dont le hash est publié comme enregistrement DS dans la zone parente. La Zone Signing Key (ZSK) signe tout le reste : enregistrements A, AAAA, MX, TXT. Cette séparation permet de renouveler la ZSK fréquemment (toutes les quelques semaines) sans coordonner avec la zone parente, tandis que la KSK (qui nécessite la mise à jour du DS parent) est renouvelée moins souvent.

Cloudflare automatise la signature de zone en périphérie et gère la rotation des clés de manière transparente. La ressource Pulumi cloudflare.ZoneDnssec exporte l’enregistrement DS courant, le digest, le key tag et l’algorithme — utile pour l’audit ou pour ajouter manuellement le DS chez un registrar non-Cloudflare. Pour lepro.dev sur Cloudflare Registrar, la propagation du DS vers Google Registry (l’opérateur du TLD .dev) est automatique.

Ce que DNSSEC ne fait pas

DNSSEC authentifie les données DNS — il prouve que la réponse provient de la source autoritaire et n’a pas été altérée. Il ne chiffre pas les requêtes DNS (c’est le rôle de DoH/DoT), ne prévient pas les attaques DDoS sur l’infrastructure DNS, et ne remplace pas TLS pour sécuriser la connexion elle-même. Considérez DNSSEC comme la garantie d’obtenir la bonne adresse IP ; TLS garantit que vous communiquez avec le bon serveur à cette adresse IP.

La combinaison des deux est importante : DNSSEC sans TLS signifie que vous atteignez la bonne IP mais communiquez en clair. TLS sans DNSSEC signifie que vous pourriez parler au mauvais serveur (si le DNS a été empoisonné), bien que la validation des certificats rattrape la plupart de ces cas. Les deux ensemble offrent une défense en profondeur — intégrité DNS plus chiffrement du transport.