DNSSEC (DNS Security Extensions) ajoute des signatures numériques aux enregistrements DNS afin que les résolveurs puissent vérifier qu'une réponse provient bien du propriétaire du domaine et n'a pas été modifiée en route. Il ne chiffre rien ; il prouve l'authenticité grâce à une chaîne de confiance qui part de la racine du DNS.
Le DNS ordinaire n'a aucun moyen de distinguer une réponse authentique d'une réponse falsifiée. DNSSEC, normalisé dans les RFC 4033, 4034 et 4035, comble cette lacune. Ce guide explique les types d'enregistrements concernés, le fonctionnement de la validation et les erreurs qui mettent le plus souvent hors ligne des domaines signés.
Le problème que résout DNSSEC
Un résolveur récursif accepte la première réponse qui correspond à sa question. Un attaquant capable d'injecter une réponse falsifiée, en se plaçant sur le chemin réseau ou en gagnant une course contre le vrai serveur lors d'une attaque par empoisonnement de cache, peut rediriger les utilisateurs de ce résolveur vers l'adresse IP de son choix. Tous ceux qui partagent ce résolveur reçoivent alors la fausse réponse jusqu'à l'expiration de l'entrée en cache.
DNSSEC rend la falsification détectable. Chaque jeu d'enregistrements est signé avec la clé privée de la zone, et la clé publique correspondante est publiée dans le DNS. Un résolveur validant vérifie la signature et rejette tout ce qui ne se vérifie pas. Si vous voulez d'abord revoir les notions de résolveur et de serveur faisant autorité, lisez ce qu'est le DNS et comment il fonctionne.
Les types d'enregistrements DNSSEC
| Enregistrement | Situé dans | Rôle |
|---|---|---|
DNSKEY | La zone signée | Clés publiques servant à vérifier les signatures de la zone |
RRSIG | La zone signée | Signature d'un jeu d'enregistrements (par exemple tous les enregistrements A d'un nom), avec des dates de début et de fin de validité |
DS | La zone parente | Delegation Signer : empreinte de la clé de signature de clés (KSK) de la zone enfant, qui relie le parent à l'enfant |
NSEC | La zone signée | Prouve qu'un nom ou un type d'enregistrement n'existe pas en désignant le nom existant suivant dans l'ordre trié |
NSEC3 | La zone signée | Comme NSEC, mais avec des noms hachés (RFC 5155), ce qui rend plus difficile le listage de tous les noms de la zone |
CDS / CDNSKEY | La zone signée | Indiquent au parent quel enregistrement DS il doit publier, ce qui permet des mises à jour automatiques (RFC 7344) |
Notre guide sur les types d'enregistrements DNS présente les enregistrements ordinaires, comme A, MX et TXT, que ces signatures protègent.
Pourquoi il faut prouver la non-existence
Sans NSEC ou NSEC3, un attaquant pourrait falsifier une réponse NXDOMAIN (« ce nom n'existe pas »), qui ne peut pas porter sa propre signature puisqu'il n'y a aucun enregistrement à signer. Les enregistrements NSEC donnent au résolveur une déclaration signée selon laquelle rien n'existe entre deux noms, de sorte qu'une réponse négative peut elle aussi être vérifiée.
Clés de signature de clés et clés de signature de zone
La plupart des zones utilisent deux types de clés, toutes deux publiées sous forme d'enregistrements DNSKEY :
- Clé de signature de zone (ZSK), flags DNSKEY
256: elle signe les jeux d'enregistrements ordinaires de la zone. On peut la renouveler souvent sans impliquer personne d'autre. - Clé de signature de clés (KSK), flags DNSKEY
257: elle signe uniquement le jeu d'enregistrements DNSKEY. Son empreinte est ce qui figure dans l'enregistrement DS chez le parent : la changer exige donc de mettre à jour le bureau d'enregistrement.
Cette séparation des rôles fait que les changements de clés courants restent chez votre hébergeur DNS, tandis que le changement de KSK, plus rare, est le seul à toucher la zone parente. Certaines configurations utilisent à la place une seule clé de signature combinée, plus simple et courante avec les algorithmes modernes à courbes elliptiques comme l'algorithme 13 (ECDSA P-256 avec SHA-256).
La chaîne de confiance
Une signature n'est utile que si le résolveur fait confiance à la clé qui l'a produite. DNSSEC construit cette confiance pas à pas à partir de la racine, signée en 2010. Les résolveurs validants embarquent la KSK de la zone racine comme ancre de confiance intégrée. Pour valider www.example.com, un résolveur :
- Utilise l'ancre de confiance de la racine pour vérifier le jeu DNSKEY de la racine.
- Vérifie l'enregistrement DS signé de
comdans la zone racine, puis contrôle qu'il correspond à la KSK du jeu DNSKEY decom. - Vérifie l'enregistrement DS signé de
example.comdans la zonecom, puis contrôle qu'il correspond à la KSK publiée parexample.com. - Utilise le jeu DNSKEY de
example.compour vérifier la RRSIG des enregistrements A dewww.example.com.
Si chaque maillon se vérifie, la réponse est sécurisée (secure). Si le parent n'a aucun enregistrement DS pour une zone, la zone est non sécurisée (insecure, non signée) et la réponse est renvoyée normalement. Si un DS existe mais que les signatures ne se vérifient pas, la réponse est invalide (bogus).
À quoi ressemble la validation : AD et SERVFAIL
Lorsqu'un résolveur validant vérifie une réponse avec succès, il active le drapeau AD (Authenticated Data) dans la réponse. Vous pouvez le voir avec dig :
$ dig +dnssec www.example.com A @1.1.1.1
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
;; ANSWER SECTION:
www.example.com. 300 IN A 192.0.2.10
www.example.com. 300 IN RRSIG A 13 3 300 20261101000000 20261011000000 12345 example.com. (signature data)Quand la validation échoue, le résolveur ne renvoie pas les données potentiellement falsifiées. Il renvoie SERVFAIL, ce qui, pour les utilisateurs, ressemble à un site inexistant ou à une panne de DNS. Pour confirmer que DNSSEC est en cause, répétez la requête avec la vérification désactivée :
dig www.example.com A # status: SERVFAIL
dig +cd www.example.com A # status: NOERROR, answer returnedSi la requête avec +cd (checking disabled) réussit alors que la requête normale échoue, le DNSSEC de la zone est défaillant. Notre Vérificateur DNSSEC effectue ces contrôles pour vous et affiche l'état du DS, des DNSKEY et des signatures.
Les causes courantes de panne DNSSEC
Changer d'hébergeur DNS sans supprimer l'enregistrement DS
C'est la panne classique. L'enregistrement DS chez le registre pointe toujours vers la KSK de l'ancien hébergeur. Après le changement de serveurs de noms, le nouvel hébergeur sert la zone sans signature ou la signe avec d'autres clés. Les résolveurs validants trouvent un DS sans clé correspondante, marquent la zone comme invalide, et chaque recherche renvoie SERVFAIL.
Une migration sans risque se déroule ainsi :
- Chez le bureau d'enregistrement, supprimez l'enregistrement DS.
- Attendez que l'ancien DS ait expiré des caches : au moins le TTL de l'enregistrement DS dans la zone parente, que vous pouvez voir avec
dig example.com DS. Attendre un jour ou deux est une marge de sécurité courante. - Changez les serveurs de noms pour ceux du nouvel hébergeur et attendez que les anciens enregistrements NS expirent.
- Activez DNSSEC chez le nouvel hébergeur et publiez son nouvel enregistrement DS chez le bureau d'enregistrement.
Certains hébergeurs prennent en charge une configuration multi-signataire qui évite la période sans signature, mais elle exige une coopération entre les deux hébergeurs.
Signatures expirées
Chaque RRSIG a une date d'expiration. Si le processus de signature s'arrête, par exemple sur un serveur auto-hébergé dont la tâche de re-signature a échoué, les signatures finissent par expirer et la zone devient invalide.
Renouvellements de clés effectués trop vite
Supprimer une ancienne clé avant que les caches aient pris en compte la nouvelle provoque des échecs pour les résolveurs qui détiennent encore l'ancien jeu DNSKEY ou l'ancien enregistrement DS. Les renouvellements doivent respecter les TTL concernés.
Comment activer DNSSEC pour votre domaine
- Vérifiez que votre TLD prend en charge DNSSEC ; la plupart des TLD génériques et de nombreux TLD nationaux le font.
- Activez la signature DNSSEC chez votre hébergeur DNS. Il générera les clés et signera la zone.
- Copiez les informations de l'enregistrement DS (key tag, algorithme, type de condensat et condensat) dans les paramètres DNSSEC de votre bureau d'enregistrement. Si votre hébergeur et votre bureau d'enregistrement sont la même entreprise, c'est souvent automatique, et certains registres prennent en compte automatiquement les enregistrements CDS.
- Vérifiez le résultat avec notre Vérificateur DNSSEC et contrôlez que les recherches ordinaires fonctionnent toujours avec l'outil Recherche DNS.
Questions fréquentes
DNSSEC chiffre-t-il mes requêtes DNS ?
Non. DNSSEC garantit l'authenticité et l'intégrité, pas la confidentialité. Les requêtes et les réponses restent visibles sur le réseau. Le chiffrement vient de DNS over TLS ou de DNS over HTTPS, qui complètent DNSSEC.
Ai-je besoin de DNSSEC si mon site utilise HTTPS ?
Les certificats HTTPS empêchent déjà une fausse réponse DNS d'usurper discrètement votre site, mais DNSSEC protège aussi le routage du courrier, les enregistrements TXT utilisés pour la vérification et d'autres enregistrements. Il est aussi requis pour DANE, qui publie dans le DNS les informations sur les certificats TLS.
Pourquoi mon domaine fonctionne-t-il sur certains réseaux mais pas sur d'autres ?
Si DNSSEC est défaillant, seuls les résolveurs validants renvoient SERVFAIL ; les autres répondent quand même. La panne semble alors dépendre du réseau.
Comment désactiver DNSSEC sans risque ?
Supprimez d'abord l'enregistrement DS chez le bureau d'enregistrement, attendez qu'il expire des caches, puis seulement arrêtez de signer la zone. Dans l'ordre inverse, vous provoquez une panne.