DNSSEC en langage simple

Module 8: Sécurité et résolution de problèmes · Temps de lecture : 11 minutes

Objectif pédagogique : après cette leçon, vous pourrez expliquer en langage simple ce que DNSSEC protège, comment fonctionne la chaîne de confiance et pourquoi cela peut poser problème lors d'un transfert.

Notions clés : DNSSEC, signature (RRSIG), clé (DNSKEY), enregistrement DS, chaîne de confiance, résolveur validant, SERVFAIL

Le problème : comment savoir qu'une réponse est authentique ?

Dans le module 1, vous avez vu qu'un résolveur pose une série de questions : à la racine, au serveur de la TLD, puis au serveur de noms faisant autorité. La réponse qui revient est acceptée telle quelle et placée en cache. Mais le DNS classique ne vérifie pas si cette réponse provient réellement du bon serveur de noms. Un attaquant capable d'envoyer une fausse réponse avant que la vraie n'arrive peut faire croire à un résolveur qu'example.com se trouve à 203.0.113.66 au lieu de 192.0.2.10. C'est ce qu'on appelle le cache poisoning : le cache est « empoisonné » et toute personne utilisant ce résolveur aboutit sur le mauvais serveur.

DNSSEC (DNS Security Extensions) résout ce problème en signant les réponses. Le résolveur peut ainsi vérifier qu'une réponse est authentique et qu'elle n'a pas été modifiée en chemin.

Ce que DNSSEC fait et ne fait pas

Voici l'essentiel à retenir :

Une signature fonctionne comme un sceau sur une enveloppe : tout le monde peut lire la lettre, mais vous voyez immédiatement si quelqu'un l'a ouverte.

Les trois composants

DNSSEC ajoute quelques types d'enregistrements. Vous n'avez pas besoin de les créer vous-même (c'est votre gestionnaire DNS ou votre panneau qui s'en charge), mais vous les rencontrerez :

• DNSKEY : la clé publique de la zone. Elle permet à tout le monde de vérifier les signatures.
• RRSIG : la signature associée à un groupe d'enregistrements. Chaque réponse de type A, MX ou TXT reçoit un RRSIG. Une signature a une date de début et une date de fin : la zone doit donc être signée régulièrement à nouveau.
• DS (Delegation Signer) : une courte « empreinte digitale » de la clé de votre zone. Elle ne se trouve pas dans votre propre zone, mais chez le parent : pour example.com, donc chez le registre de .com (Verisign), pour un domaine .nl, chez SIDN (le registre de .nl aux Pays-Bas).

Voici à quoi ressemble une réponse signée (raccourcie) :

$ dig example.com A +dnssec +noall +answer
example.com.  3600  IN  A      192.0.2.10
example.com.  3600  IN  RRSIG  A 13 2 3600 20261119000000 20261029000000 30794 example.com. s7yJ5o...

Dans le RRSIG, vous voyez entre autres l'algorithme (13 = ECDSA P-256 avec SHA-256), la date de fin (19 novembre 2026), la date de début et le numéro de la clé (30794).

La chaîne de confiance

Pourquoi le DS se trouve-t-il chez le parent ? Parce qu'une clé présente dans votre propre zone ne prouve rien : un attaquant pourrait tout aussi bien fournir sa propre clé. C'est pourquoi la vérification se fait de haut en bas :

1. Le résolveur fait confiance à la clé de la racine. Elle est intégrée dans chaque résolveur validant (le trust anchor).
2. La racine possède un DS pour .com, signé avec la clé de la racine. Le résolveur sait ainsi quelle clé .com est censé avoir.
3. La zone .com possède un DS pour example.com, signé avec la clé de .com.
4. La zone example.com possède une DNSKEY correspondant à ce DS, ce qui permet de vérifier tous les RRSIG.

Chaque maillon prouve la validité du suivant. Si un maillon se rompt, toute la chaîne devient non fiable.

Un résolveur validant (la plupart des grands résolveurs publics, et de plus en plus de fournisseurs d'accès) parcourt cette chaîne. Si elle est correcte, vous obtenez la réponse. Si elle ne l'est pas, le résolveur ne donne aucune réponse, mais renvoie le code d'erreur SERVFAIL. Pour le visiteur, le site semble alors tout simplement « ne pas exister », alors que vos enregistrements sont peut-être parfaitement corrects.

Vous pouvez le constater vous-même avec un domaine volontairement cassé :

$ dig dnssec-failed.org A @1.1.1.1
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL
; EDE: 9 (DNSKEY Missing): (no SEP matching the DS found for dnssec-failed.org.)

Avec +cd (« checking disabled »), vous demandez au résolveur de sauter la vérification. Si vous obtenez alors une réponse, vous savez avec certitude que le problème vient de DNSSEC :

$ dig +cd dnssec-failed.org A @1.1.1.1 +short
96.99.227.255

Un domaine sans DNSSEC (aucun DS chez le parent) ne renvoie pas de SERVFAIL : il est simplement non signé et est laissé passer comme « non sécurisé ».

Là où cela se complique : transfert et changement de clés

DNSSEC lui-même tombe presque jamais en panne. Le problème survient quand le DS chez le registre ne correspond plus à la clé de la zone. Cela arrive surtout :

• Lors d'un transfert de serveurs de noms ou de fournisseur DNS. Le nouveau fournisseur signe avec sa propre clé, mais le registre conserve encore le DS de l'ancien fournisseur. Résultat : SERVFAIL pour tous ceux qui utilisent un résolveur validant. C'est l'erreur classique après un transfert.
• Lors d'un changement de clé où le nouveau DS n'a pas été (ou pas à temps) envoyé au registre.
• Quand les signatures expirent, parce que la zone n'est plus signée à nouveau.

L'ordre sûr à suivre lors d'un transfert est donc le suivant :

1. Supprimez le DS chez le registre (ou demandez au nouveau fournisseur de vous fournir un DS que vous ajoutez).
2. Attendez que la TTL de l'ancien DS soit écoulée.
3. Changez les serveurs de noms.
4. Activez DNSSEC chez le nouveau fournisseur et faites placer le nouveau DS chez le registre.

De nombreux bureaux d'enregistrement et panneaux gèrent aujourd'hui cela automatiquement tant que le domaine et le DNS sont chez le même fournisseur. S'ils sont chez des fournisseurs différents, vous devez transférer le DS vous-même.

Vérifier vous-même : DNSViz, Zonemaster et internet.nl

Vous n'avez pas besoin de parcourir la chaîne avec dig. Il existe des outils gratuits qui le font pour vous et affichent le résultat.

DNSViz (https://dnsviz.net/) dessine toute la chaîne sous forme de schéma. Voici comment l'utiliser :

1. Sur la page d'accueil, saisissez le nom de domaine dans le champ de recherche (uniquement le nom, sans https:// ni www) et cliquez sur Go.
2. DNSViz affiche la dernière analyse. Si elle est ancienne, ou si vous venez de modifier quelque chose, cliquez sur Update now. Après quelques secondes, le schéma apparaît.
3. Lisez le schéma de haut en bas : en haut la racine (.), en dessous la TLD (par exemple nl), en bas votre domaine. Chaque zone est un cadre.

Ce que vous voyez dans le schéma :

Voici comment suivre la chaîne : le DS (chez le parent) pointe vers la DNSKEY (dans votre zone), et cette DNSKEY appose sa signature (RRSIG) sur les enregistrements. C'est exactement la chaîne décrite dans cette leçon, mais sous forme de schéma.

Les couleurs indiquent si tout est correct :

• Bleu : sécurisé (secure). La chaîne est ininterrompue depuis la racine jusqu'à cet élément.
• Noir : non signé (insecure). Il n'y a pas de DS, donc rien à vérifier. Ce n'est pas une erreur, le domaine n'utilise simplement pas DNSSEC.
• Rouge : cassé (bogus). Un DS ne correspond pas à une clé, ou une signature est incorrecte. Un résolveur validant renvoie alors SERVFAIL.
• Violet (pour une signature) : la signature a expiré ou n'est pas encore valable. La zone n'est plus signée à nouveau.
• Jaune : un avertissement, par exemple un serveur de noms qui ne répond pas correctement, ou un algorithme que l'outil ne reconnaît pas.
• Gris et en pointillés : une référence est faite à une clé qui n'existe pas. Si vous voyez une DNSKEY en pointillés sous un DS, c'est que le registre conserve encore un DS d'une ancienne clé : l'erreur classique après un transfert.

À côté d'un élément peut figurer un petit triangle (avertissement) ou un symbole d'erreur rond. Placez votre souris dessus, ou consultez la liste sous le schéma : elle indique en toutes lettres ce qui ne va pas.

Essayez avec sidn.nl (tout en bleu) et avec dnssec-failed.org (en rouge, avec une clé en pointillés sous le DS).

D'autres outils examinent la même chose sous un angle différent :

• Zonemaster (https://zonemaster.net/) : contrôle toute votre zone comme le ferait un registre, y compris DNSSEC. Le résultat est une liste avec du vert (correct), de l'orange (avertissement) et du rouge (erreur).
• internet.nl (https://internet.nl/) : le test de site web et de messagerie montre entre autres si DNSSEC est en ordre pour votre domaine et vos serveurs de messagerie, avec des coches vertes ou des croix rouges.
• Verisign DNSSEC Debugger (https://dnssec-debugger.verisignlabs.com/) : parcourt la chaîne étape par étape et place à chaque étape une coche verte ou une croix rouge. Pratique si vous cherchez une erreur précise.

Utilisez-les après chaque modification de DNSSEC, et certainement avant et après un transfert. Laissez l'outil relancer l'analyse tranquillement : ces outils fonctionnent eux aussi avec des caches et des TTL.

En pratique : à quoi cela ressemble dans un panneau

Dans Mon WebOké, vous activez DNSSEC pour un domaine sous DNSSEC/DANE ; le panneau génère les clés et envoie le DS au registre. Dans DirectAdmin et chez des fournisseurs externes comme Cloudflare, cela s'appelle généralement « activer DNSSEC » ; Cloudflare vous affiche alors un enregistrement DS que vous devez saisir vous-même chez votre bureau d'enregistrement. D'autres panneaux fonctionnent de manière similaire : il y a toujours une étape « créer les clés » (chez le fournisseur DNS) et une étape « DS chez le registre » (chez le bureau d'enregistrement).

Résumé

• DNSSEC signe les réponses DNS afin qu'un résolveur puisse vérifier leur authenticité. Il ne chiffre rien.
• DNSKEY est la clé, RRSIG la signature, DS l'empreinte digitale chez le parent.
• La vérification se déroule comme une chaîne depuis la racine jusqu'à votre domaine. Si un maillon se rompt, un résolveur validant renvoie SERVFAIL.
• Presque tous les problèmes surviennent parce que le DS chez le registre ne correspond plus, souvent après un transfert.
• Avec dig +cd, vous voyez si un problème provient de DNSSEC.
• DNSViz dessine la chaîne : bleu signifie sécurisé, noir signifie non signé, rouge signifie cassé. Zonemaster, internet.nl et le Verisign DNSSEC Debugger sont de bons avis complémentaires.

Quiz

Exercice

Exercice Z8.1 : observer DNSSEC. Déterminez lequel de ces deux domaines a correctement configuré DNSSEC et lequel a été volontairement cassé : sidn.nl et dnssec-failed.org. Interrogez pour les deux l'enregistrement DS et l'enregistrement A via un résolveur validant (par exemple 1.1.1.1 ou 9.9.9.9), avec dig ou un outil en ligne. Indiquez : le numéro de clé (key tag, le premier nombre) du DS de sidn.nl, et le statut que vous obtenez pour dnssec-failed.org.

Exercice Z8.1b : lire DNSViz. Analysez nlnetlabs.nl dans DNSViz (https://dnsviz.net/, saisissez le nom et cliquez sur Go ; cliquez sur Update now si l'analyse est ancienne). Lisez le schéma et indiquez : (1) le statut de nlnetlabs.nl (sécurisé, non signé ou cassé), (2) le numéro d'algorithme des enregistrements DNSKEY (indiqué dans chaque ovale sous la forme alg=), (3) combien d'ovales DNSKEY figurent dans la zone de nlnetlabs.nl, (4) le numéro de clé (id=) de la DNSKEY grise pleine vers laquelle pointe le DS, et (5) le statut que DNSViz donne pour dnssec-failed.org. La vérification interroge les mêmes données en direct.

Exercice O8.1 : évaluer trois zones de démonstration DNSSEC. Nous avons mis en place trois zones de démonstration : signed-demo.dnspractice.com (chaîne correcte), broken-demo.dnspractice.com (volontairement cassée) et unsigned-demo.dnspractice.com (non signée). Déterminez pour chaque zone si elle est sécurisée, cassée ou non signée, par exemple avec DNSViz ou avec dig +dnssec (surveillez l'indicateur AD, et essayez aussi +cd en cas de SERVFAIL). Choisissez ci-dessous votre réponse pour chaque zone.

Pour aller plus loin

Ces articles décrivent les étapes dans les panneaux de WebOké ; chez d'autres fournisseurs, les boutons portent des noms différents.

• Guide WebOké 5.8: DNSSEC et DANE
• Qu'est-ce que le DNSSEC ?
• Activer DNSSEC
• Le site web ou l'e-mail ne fonctionne pas après un déménagement ou une modification DNS : vérifiez votre domaine