DNSSEC : qu'est-ce que c'est et comment l'activer sans risque

Le DNS classique n'a aucun moyen de prouver qu'une réponse est authentique. Un résolveur envoie une question en UDP et croit la première réponse plausible. Quiconque peut injecter ou modifier cette réponse (empoisonnement de cache, réseau compromis, résolveur malveillant) peut envoyer les utilisateurs vers un autre serveur. DNSSEC, les extensions de sécurité du DNS, comble cette lacune en ajoutant des signatures numériques aux données DNS, pour qu'un résolveur puisse vérifier qu'une réponse vient bien du gestionnaire de la zone et n'a pas été modifiée en chemin.

Il mérite d'être activé sur la plupart des domaines, et c'est aussi l'une des rares fonctions DNS capables de mettre un domaine entièrement hors ligne quand on la manipule sans précaution. Les deux aspects sont traités ci-dessous.

Ce que DNSSEC fait, et ce qu'il ne fait pas

Il apporte :

L'authentification de l'origine et l'intégrité : les enregistrements ont été publiés par le détenteur des clés de la zone, et n'ont pas été modifiés.
Le déni d'existence authentifié : une preuve signée qu'un nom ou un type d'enregistrement n'existe pas, pour qu'un « ce domaine n'existe pas » ne puisse pas non plus être forgé.

Il n'apporte pas :

Le chiffrement. Questions et réponses restent lisibles par quiconque se trouve sur le chemin. La confidentialité relève de DNS over TLS ou DNS over HTTPS, qui protègent le trajet entre le client et le résolveur et complètent DNSSEC sans le remplacer.
Une protection contre un compte DNS compromis. Si un attaquant peut modifier votre zone, le fournisseur signera ses enregistrements sans sourciller.
La protection de la session web. C'est le rôle de TLS. DNSSEC garantit que vous atteignez la bonne adresse ; le certificat prouve que le serveur est bien celui qu'il prétend être.
Quoi que ce soit pour les utilisateurs dont le résolveur ne valide pas. Beaucoup de grands résolveurs publics et de FAI valident ; pas tous.

Comment ça marche

DNSSEC ajoute une poignée de types d'enregistrements :

Enregistrement	Où	Rôle
`RRSIG`	à côté de chaque ensemble d'enregistrements	la signature de cet ensemble (par exemple de tous les enregistrements `A` de `www`)
`DNSKEY`	apex de la zone	les clés publiques de la zone
`DS`	dans la zone parente	une empreinte de la clé de l'enfant ; le maillon de la chaîne
`NSEC` / `NSEC3`	dans toute la zone	prouve quels noms et types n'existent pas
`CDS` / `CDNSKEY`	apex de la zone	permet à l'enfant de signaler automatiquement au parent un changement de DS

La plupart des zones utilisent deux clés. La clé de signature de zone (ZSK) signe les enregistrements. La clé de signature de clés (KSK) ne signe que l'ensemble DNSKEY, et c'est l'empreinte de la KSK qui est publiée comme enregistrement DS dans le parent. Cette séparation permet de renouveler souvent la ZSK sans impliquer le parent. Certains fournisseurs utilisent à la place une clé unique combinée (CSK) ; le principe est le même.

La chaîne de confiance

Un résolveur validant ne fait confiance, d'emblée, qu'à une seule chose : la clé publique de la zone racine, signée depuis 2010. Tout le reste en découle :

root DNSKEY  (trust anchor, built into the resolver)
   └─ signs  DS for "com"          → matches com's DNSKEY
         └─ signs  DS for "example.com"   → matches example.com's DNSKEY
               └─ signs  www.example.com A 192.0.2.10

À chaque niveau, le parent se porte garant de la clé de l'enfant en publiant et en signant un enregistrement DS. Si chaque maillon se vérifie, la réponse est sécurisée (secure) et le résolveur positionne le drapeau ad (authenticated data). Si une zone n'a pas de DS chez son parent, elle est simplement non sécurisée (insecure) : traitée comme du DNS ordinaire non signé, sans dommage. Mais si un DS existe et que les signatures ne se vérifient pas (mauvaise clé, signature expirée, RRSIG manquant), le résultat est bogus, et le résolveur renvoie SERVFAIL. Pour les utilisateurs derrière un résolveur validant, le domaine cesse d'exister.

Ce dernier cas constitue tout le risque opérationnel de DNSSEC, et il explique les règles qui suivent.

Un détail à connaître : les signatures expirent. Chaque RRSIG a une date de début et une date de fin de validité. Le signataire doit re-signer régulièrement. Les fournisseurs de DNS managé le font automatiquement ; un signataire auto-hébergé qui s'arrête de tourner provoque une panne une ou deux semaines plus tard.

Vérifier DNSSEC avec dig

Y a-t-il un enregistrement DS chez le parent (autrement dit, le domaine est-il censé être signé) ?

$ dig +short example.com DS
31589 13 2 3490A6806D47F17A34C29E2CE80E8A999FFBE4BE...

Les champs sont l'identifiant de clé (key tag), l'algorithme (13 = ECDSA P-256 avec SHA-256, le choix moderne habituel), le type d'empreinte (2 = SHA-256) et l'empreinte.

La zone publie-t-elle des clés et des signatures ?

$ dig +dnssec +multi example.com DNSKEY
$ dig +dnssec www.example.com A
www.example.com.  3600 IN A      192.0.2.10
www.example.com.  3600 IN RRSIG  A 13 3 3600 20261004000000 20260920000000 31589 example.com. oJB1W6WNGv+ldvQ3WDG0MQkg5IEhjRip8WTr...

Est-ce que cela valide ? Interrogez un résolveur validant et regardez les drapeaux :

$ dig www.example.com A @1.1.1.1 | grep flags
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 1, ...

ad signifie que le résolveur a validé la réponse. Pour distinguer un échec DNSSEC des autres échecs, répétez une requête en échec avec la vérification désactivée :

$ dig www.example.com A @1.1.1.1          # status: SERVFAIL
$ dig www.example.com A @1.1.1.1 +cd      # status: NOERROR, answer present

SERVFAIL en temps normal, mais une réponse avec +cd : c'est la signature d'une configuration DNSSEC cassée. delv www.example.com (fourni avec BIND) effectue la validation en local et explique où la chaîne se rompt.

Comment activer DNSSEC

Trois parties doivent le prendre en charge : le TLD (presque tous le font), le fournisseur DNS (qui signe la zone) et le bureau d'enregistrement (qui transmet le DS au registre).

Activez la signature chez le fournisseur DNS. Il génère des clés et commence à publier des enregistrements DNSKEY et RRSIG. À ce stade, rien ne peut casser, car sans DS la zone reste « non sécurisée ».
Vérifiez la zone signée : dig +dnssec vers les serveurs de noms du fournisseur doit montrer des RRSIG pour vos enregistrements. Attendez au moins un TTL pour que les caches détiennent les données signées.
Publiez l'enregistrement DS.
- Si le bureau d'enregistrement et le fournisseur DNS sont la même société, c'est en général un clic, ou automatique.
- Sinon, copiez les valeurs du DS (identifiant de clé, algorithme, type d'empreinte, empreinte) depuis le fournisseur DNS dans le formulaire DNSSEC du bureau d'enregistrement. Certains bureaux d'enregistrement demandent la DNSKEY à la place et calculent le DS eux-mêmes. Copiez avec soin ; un seul caractère erroné rend le domaine bogus.
- Certains registres et bureaux d'enregistrement scrutent les enregistrements CDS/CDNSKEY et créent ou mettent à jour le DS d'eux-mêmes. Si c'est le cas du vôtre, privilégiez cette voie.
Vérifiez la chaîne avec les commandes ci-dessus et un validateur externe, depuis plus d'un résolveur.
Surveillez. L'expiration des signatures et les DS non concordants ne s'annoncent pas avant de tomber en panne.

Les moments dangereux

Changer de fournisseur DNS ou de serveurs de noms. Le DS chez le parent pointe vers la clé de l'ancien fournisseur. Changez de serveurs de noms sans vous en occuper, et le domaine devient bogus. Soit vous retirez le DS, attendez l'expiration de son TTL (souvent une journée), migrez, puis réactivez ; soit vous réalisez une migration multi-signataires coordonnée. La séquence complète est dans changer de serveurs de noms sans interruption.
Désactiver DNSSEC. L'ordre est l'inverse de l'activation : retirez d'abord le DS, attendez la fin de son TTL, et seulement ensuite arrêtez la signature. Désactiver la signature alors que le DS est encore publié est la panne auto-infligée classique.
Transférer le domaine vers un autre bureau d'enregistrement quand l'ancien héberge aussi le DNS. Voir comment transférer un nom de domaine.
Les renouvellements de clés sur des signataires auto-hébergés. Un renouvellement de KSK implique le parent et doit suivre le schéma publier, attendre, basculer, attendre, retirer. Avec un fournisseur managé, c'est son travail.

Rappelez-vous qu'abaisser vos propres TTL n'aide en rien face à une chaîne cassée : le TTL de l'enregistrement DS est fixé par la zone parente.

Erreurs fréquentes

Coller le DS avec un mauvais numéro d'algorithme ou de type d'empreinte.
Laisser un ancien DS en place après un changement de fournisseur DNS.
Désactiver la signature avant d'avoir retiré le DS.
Un signataire auto-hébergé dont la tâche cron est morte ; tout fonctionne jusqu'à l'expiration des signatures.
Choisir NSEC sans se rendre compte qu'il permet d'énumérer les noms de la zone (« zone walking »). NSEC3, ou les techniques de réponse minimale qu'utilisent les grands fournisseurs, rendent cela plus difficile.
Utiliser des algorithmes dépassés (RSA/SHA-1) alors qu'ECDSA P-256 donne des réponses plus petites et est universellement pris en charge par les validateurs actuels.
Supposer que, puisque le site fonctionne chez vous, DNSSEC est en ordre. Votre résolveur ne valide peut-être pas.

Est-ce que cela en vaut la peine ?

Pour la plupart des domaines chez un fournisseur de DNS managé : oui. C'est gratuit, cela tient en un ou deux clics, et cela supprime une catégorie d'attaques qui vous serait autrement invisible. Le coût, c'est de la discipline opérationnelle aux quelques moments listés ci-dessus. Si votre équipe change de fournisseur DNS à la légère et que personne n'est responsable du compte chez le bureau d'enregistrement, corrigez cela d'abord.

Vérifiez avec OrbitProbe

La recherche DNS d'OrbitProbe montre les enregistrements que les résolveurs publics renvoient pour votre domaine, avec leurs TTL. Un domaine signé qui, tout à coup, ne renvoie plus aucun enregistrement depuis les résolveurs validants alors que le panneau de votre fournisseur paraît normal : voilà le schéma à reconnaître. Passez directement au test +cd ci-dessus. La vue qu'a le registre de la délégation, y compris si elle est marquée comme signée, apparaît dans les données d'enregistrement, comme décrit dans WHOIS ou RDAP.