Le problème que DNSSEC résout
Le DNS a été conçu sans moyen de vérifier qu'une réponse est authentique. Un attaquant qui parvient à glisser une fausse réponse dans le cache d'un fournisseur d'accès peut envoyer ses abonnés vers un faux site, alors qu'ils ont tapé la bonne adresse. C'est l'empoisonnement de cache.
Avec DNSSEC, le propriétaire de la zone signe ses enregistrements avec une clé privée et publie la clé publique correspondante. Selon l'ICANN, la signature apporte deux garanties : l'origine des données et leur intégrité. Si la vérification échoue, le serveur considère qu'il y a une attaque, rejette la réponse et renvoie une erreur. Le visiteur ne voit pas le site, mais il ne tombe pas non plus sur un faux.
La RFC 4033, qui définit DNSSEC, précise ce qu'il ne fait pas : il n'assure pas la confidentialité des données et ne protège pas contre une attaque par saturation.
La chaîne de confiance
Une signature ne vaut que si l'on peut faire confiance à la clé qui l'a produite. DNSSEC règle la question par une chaîne :
- La racine du DNS est signée depuis 2010. Sa clé publique est connue des serveurs qui vérifient.
- Le registre de l'extension, par exemple l'Afnic pour le .fr, signe sa zone et publie, pour chaque domaine signé, un enregistrement DS : une empreinte de la clé de ce domaine.
- La zone de votre domaine est signée avec la clé dont l'empreinte figure dans le DS.
Si un maillon manque, la chaîne s'arrête : un domaine signé sans DS publié au registre n'est pas vérifié. À l'inverse, un DS publié pour une zone qui n'est plus signée, ou signée avec une autre clé, rend le domaine injoignable pour tous les serveurs qui vérifient.
L'enregistrement DS
Le DS est la seule pièce qui ne se pose pas dans votre zone. Il se transmet au registre par votre bureau d'enregistrement. Il comporte quatre valeurs : le numéro de la clé (keytag), l'algorithme, le type d'empreinte (digest type) et l'empreinte elle-même (digest). Le gestionnaire qui signe votre zone vous les donne ; vous les recopiez chez le bureau d'enregistrement, tels quels.
Chez Cloudflare, par exemple, l'activation se fait depuis la carte DNSSEC des réglages DNS, qui affiche ensuite les valeurs du DS à reporter chez le bureau d'enregistrement, d'après sa documentation.
Le piège du changement de serveurs DNS
C'est la panne la plus fréquente avec DNSSEC. Si vous changez les serveurs de noms d'un domaine signé sans retirer d'abord le DS, les serveurs qui vérifient comparent la nouvelle zone à l'ancienne empreinte, et refusent toutes les réponses : site et courriels deviennent injoignables. Cloudflare décrit l'ordre à suivre :
- Retirez le DS chez le bureau d'enregistrement.
- Attendez que l'ancien DS ait expiré des caches, ce qui prend couramment 24 à 48 heures selon l'extension.
- Changez les serveurs de noms.
- Activez DNSSEC chez le nouveau gestionnaire et publiez le nouveau DS.
Le changement de serveurs lui-même est décrit dans Changer les serveurs DNS.
Vérifier qu'un domaine est signé
Sous macOS ou Linux, la commande dig montre le DS publié par le registre :
dig DS exemple.fr +short
Une réponse vide signifie qu'aucun DS n'est publié : le domaine n'est pas vérifié par DNSSEC. Pour voir les signatures de la zone elle-même :
dig A exemple.fr +dnssec
La réponse contient alors des enregistrements RRSIG à côté des enregistrements A. Plusieurs outils en ligne dessinent la chaîne complète et signalent le maillon cassé quand il y en a un.
Faut-il activer DNSSEC ?
Pour la plupart des sites, l'activation est un bon réglage, à une condition : savoir qu'il faut retirer le DS avant de changer de gestionnaire de zone. Un domaine dont la zone change souvent de mains, ou que personne ne suit, court davantage de risques de panne avec DNSSEC qu'avec un DNS non signé. Signer la zone n'a de sens que chez le gestionnaire qui la sert réellement.
Chez Hubspace
Nos serveurs d'hébergement ne servent aucune zone DNS publique. Pour un domaine enregistré chez nous, la zone est servie par défaut par les serveurs de notre bureau d'enregistrement partenaire, Netim (ns1.netim.net, ns2.netim.net, ns3.netim.net). La fiche du domaine dans votre espace client propose, selon l'extension, un onglet « Service DNSSec » pour activer ou désactiver la signature de cette zone. Si votre zone est servie ailleurs, chez Cloudflare par exemple, c'est là que la signature s'active, et le DS se publie ensuite chez le bureau d'enregistrement. Pour un domaine enregistré chez nous, écrivez-nous avant de signer la zone ou de changer de serveurs de noms : nous vous dirons ce qui est possible pour votre extension.
Questions fréquentes
DNSSEC rend-il mon site plus rapide ou mieux référencé ?
Non. Il protège l'exactitude des réponses DNS. Les réponses signées sont un peu plus volumineuses, sans effet perceptible pour le visiteur.
DNSSEC remplace-t-il le certificat SSL de mon site ?
Non. Le certificat chiffre la connexion entre le visiteur et le site. DNSSEC garantit que le visiteur arrive à la bonne adresse. Les deux se complètent.
Mon domaine ne répond plus depuis un changement de serveurs. DNSSEC peut-il en être la cause ?
Oui, si un DS est toujours publié. Vérifiez avec dig DS exemple.fr +short : si une valeur revient alors que le nouveau gestionnaire ne signe pas la zone, retirez le DS chez le bureau d'enregistrement.
Articles liés
- Enregistrement DNS : A, AAAA, CNAME, MX et TXTLes enregistrements DNS d'un domaine expliqués : A, AAAA, CNAME, MX, TXT et NS, à quoi chacun sert et comment pointer un domaine vers un site.
- Enregistrement MX : le lire, le modifierL'enregistrement MX désigne les serveurs qui reçoivent le courrier de votre domaine : priorité, valeurs, modification pas à pas et erreurs à éviter.
- Enregistrement CNAME : usage et limitesLe CNAME fait d'un sous-domaine l'alias d'un autre nom : quand l'utiliser, pourquoi le domaine nu ne peut pas en porter, et comment le créer.