Outils pour utilisateurs

Outils du site


configurer_dnssec

Configurer DNSSEC

Utilité

DNSSEC (Domain Name System Security Extensions) apporte la sécurité du chiffrement aux enregistrements DNS. Typiquement, votre ordi fait appel à des serveurs DNS externes1) pour résoudre les noms de domaines. Qu'est-ce qui vous garantit que ces serveurs n'ont pas été hackés ? Même si vous utilisez votre propre serveur DNS, comment savoir que les serveurs faisant autorité sur un nom de domaine n'ont pas eux-mêmes été hackés ? Or un DNS hacké peut vous envoyer sur n'importe quel serveur et vous faire croire que ce dernier est bien celui qui héberge le site de votre banque…

DNSSEC apporte une sécurité nouvelle au DNS grâce au chiffrement et à la signature des information contenues dans le DNS. La clé de voûte du système est le chiffrement des données des registres eux-mêmes, sécurisant la chaîne de dérivation des noms de domaines. Ainsi, .net va garantir que ses données sont sécurisées et que les données de sécurisation des serveurs DNS faisant autorité sur mondomaine.net sont fiables. À sont tour, le DNS de mondomaine.net publiera des informations sécurisées.

En savoir plus :

Racine et TLDs

Pour que le système soit fiable, il faut que la chaîne de confiance soit établie. Cela suppose que la racine (“.”) du DNS soit elle-même signée et que le TLD dans lequel s'inscrit le nom de domaine auquel on souhaite appliquer DNSSEC le soit aussi.

La racine l'est depuis 2010. Un rapport mis à jour en temps réel dresse l'état des TLDs au regard de DNSSEC2).

Principe

Le principe simplifié est le suivant :

  • on crée une paire de clés publique/privée
  • on transmet la clé publique au gestionnaire de la zone de niveau supérieur (le registre dans le cas d'un tld)
  • sur le serveur DNS gérant la zone concernée, on génère des enregistrements signés qui viennent surcharger les enregistrements classiques.

En savoir plus ; How DNSSEC Works (en) (cloudflare.com)

Mise en œuvre simplifiée

Avant toute mise en place de DNSSEC, s'assurer que le domaine est parfaitement configuré : 0 erreur, 0 avertissement3). Seules les notifications (notamment l'absence de DNSSEC) sont acceptables.

Je décris ici une mise en œuvre simplifiée sur un serveur DNS Debian-Bind muni de l'outil d'administration Webmin-Virtualmin.

  • Pointer le navigateur sur : Webmin > Servers > BIND DNS server > domainName > Setup DNSSECKEY
    • Key alogorithm : RSASHA256
    • Create
    • vérifier le fichier de zone
    • appliquer la zone
  • Pour la suite, on revient sur Virtualmin
  • <domainName> > Server Configuration > DNS Options > DNSSEC zone keys
    • copier la DNSSEC public key
  • ouvrir une fenêtre de navigateur sur votre registrar
    • choisir le nom de domaine
    • aller à la gestion du DNNSEC (dans la section4)concernant le serveurs de noms)
    • coller et ajouter la clé publique copiée précédemment copiée
    • votre registrar transmet votre clé au registre
  • laisser le temps à l'information de se propager
  • vérifier l'état de la zone (typiquement à l'aide de zonemaster.fr)

C'est tout !

N'oubliez pas que votre DNS est sécurisé mais beaucoup moins tolérant aux imperfections : les horloges des serveurs DNS doivent être parfaitement réglées, les rafraîchissements doivent être impeccables, etc.
Il est vivement recommandé de commencer sur un domaine de test et de voir comment votre système DNS se comporte dans le temps avant de basculer sur des domaines utilisés en production.

Vérification

Toute action5) demandant vérification, on effectue un diagnostic complet de la configuration DNSSEC de la zone :

Pour que tous les feux soient au vert, il faut attendre que les serveur DNS faisant autorité6) sur le nom de domaine (et la zone parente !) aient publié les données mises à jour. Ça peut prendre un peu de temps si la zone parente est un tld puisque vous passez par l'intermédiaire de votre registrar et dépendez de la réactivité du registre.

Mise à jour de la clé de signature de zone

La clé de signature de zone a une durée de vie limitée. Elle doit donc être régulièrement régénérée et les enregistrements doivent être signés avec cette nouvelle clé.

Sur un hébergement administré via Webmin, cette mise à jour doit s'effectuer automatiquement. Si ce n'est pas le cas, Webmin > BIND DNS Server > <domain> > Setup DNS Key > Re-sign Zone.

Il n'est pas nécessaire de re-déclarer la KSK publique (à la zone parente7)) puisqu'elle n'a pas changé.

Quelques explications

Le but n'est pas de faire un exposé sur le DNSSEC mais d'avoir une compréhension minimale de ce qui figure dans une zone sécurisé.

Types de clés

Afin d'assurer le chaînage8) de la sécurité, deux types de clés sont utilisées. Les deux types utilisent le principe de clés publique/privée. On dispose donc de 4 clés, deux publiques et deux privées.

Une première clé sert au déchiffrement des enregistrements présents dans la zone. Cette clé (publique) est inscrite dans la zone qu'elle permet de chiffrer. On parle alors de ZSK : Zone Signing Key (clé de signature de zone).

Cette seule signature de zone ne sert pas à grand chose. En effet, si une intruse a trouvé le moyen de modifier une zone non protégée par DNSSEC, elle peut aussi bien générer sa propre ZSK, et trafiquer la zone en chiffrant les enregistrements avec cette clé. Il faut donc s'assurer que le ZSK elle-même n'a pas été trafiquée.

Pour ce faire, on signe la ZSK avec une autre clé.On parle alors de KSK : Key Signing Key (clé de signature de clé). Une fois cette KSK publiée dans la zone concernée, on la transmet à l'entité gestionnaire de la zone parente9). Cette entité s'assure de la présence de la même clé dans la zone fille et publie un enregistrement contenant la signature de la clé (DS record). Cette technique assure le chaînage de la sécurité10), depuis le tld jusqu'à la zone concernée.

Enregistrements

La zone contient de nouveaux type d'enregistrements :

  • NSEC, permet la déclaration explicite des types d'enregistrements protégés par DNSSEC pour un domaine décrit dans la zone,
  • RRSIG, les signatures des enregistrements de la zone,
  • DNSKEY, les clés publiques,
  • DS, les signatures des clés; ces enregistrement figurent dans la zone parente.

Quelques mot sur NSEC

Quelle sécurité supplémentaire apporte les enregistrement NSEC ? NSEC permet d'avoir un information sécurisée sur l'absence d'un enregistrement dans le DNS11): si un enregistrement est absent, c'est délibéré. Autrement dit, il n'a pas été effacé de manière malveillante.

Renouvellement des clés

Il est hasardeux de laisser “en roue libre” un dispositif que l'on souhaite sécurisé. Cela signifie qu'il faut renouveler les clés ou, pour le moins et impérativement, se mettre en ordre de marche pour les changer, au cas où cela serait nécessaire.

L'opération est particulièrement délicate. Les tenants et aboutissants sont exposés avec clarté dans RFC 7583: DNSSEC Key Rollover Timing Considerations (fr) (bortzmeyer.org).

Dans l'exemple de mise en œuvre présenté précédemment, Webmin s'appuie sur OpenDNSSEC qui gère automatiquement le renouvellement des clés.

1)
Celui de votre FAI, de votre organisation…
2)
Au moment de la rédaction de cette section (19/10/2021) 1378 TLDs étaient signés sur un total de 1495 figurant dans la zone racine.
3)
Un tour par zonemaster s'impose.
4)
Les services proposés par les registrars varient : gestion automatisée de DNSSEC si vous utilisez leurs DNS, déclaration et transfert au registre si vous utilisez vos propres DNS…
5)
Surtout de cette ampleur. Il en va de la disponibilité du nom de domaine et de tous les services bâtis sur ce nom.
6)
Pas besoin d'attendre la propagation.
7)
Que ce soit un tld ou pas ;-)
8)
Depuis les tld jusqu'à la zone concernée.
9)
Pour un domaine de niveau 2, l'entité parente n'est autre que le Registre.
10)
N'importe qui (typiquement, un resolver) peut vérifier s'il obtient la même signature que celle publiée par la zone parente, à partir des clés publiques publiées dans la zone concernée.
11)
authenticated denial of existence.
configurer_dnssec.txt · Dernière modification : 2024/02/14 18:15 de Flaz