Flaz's Hotline

Cette page est en lecture seule. Vous pouvez afficher le texte source, mais ne pourrez pas le modifier. Contactez votre administrateur si vous pensez qu'il s'agit d'une erreur.
======  Configurer DNSSEC ======

===== Utilité =====

[[https://en.wikipedia.org/wiki/Domain_Name_System_Security_Extensions|DNSSEC]] (Domain Name System Security Extensions) apporte la sécurité du chiffrement aux enregistrements DNS. Typiquement, votre ordi fait appel à des serveurs DNS externes((Celui de votre FAI, de votre organisation…)) 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 :
  * [[https://ensiwiki.ensimag.fr/index.php?title=Introduction_%C3%A0_DNSSEC|Introduction à DNSSEC]](fr) (ensimag)
  * [[https://www.afnic.fr/data/divers/public/afnic-dossier-dnssec-2010-09.pdf|DNSSEC
  * [[https://www.afnic.fr/wp-media/uploads/2021/01/Afnic-dnssec-howto-fr-v3.pdf|Déplyer DNSSEC, comment, quoi, où]] (fr) (afnic)
  * les extensions de sécuritédu DNS]] (fr) (afnic)

===== 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.

[[https://www.iana.org/dnssec/archive|La racine l'est depuis 2010]]. Un rapport mis à jour en temps réel dresse l'[[http://stats.research.icann.org/dns/tld_report/|état des TLDs au regard de DNSSEC]]((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.)).
===== 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 [[https://fr.wikipedia.org/wiki/Domaine_de_premier_niveau|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 ; [[https://www.cloudflare.com/dns/dnssec/how-dnssec-works/|How DNSSEC Works]] (en) (cloudflare.com)
====== Mise en œuvre simplifiée ======
<note warning>Avant toute mise en place de DNSSEC, s'assurer que le domaine est **parfaitement** configuré : 0 erreur, 0 avertissement((Un tour par [[https://www.zonemaster.fr/domain_check|zonemaster]] s'impose.)). Seules les notifications (notamment l'absence de DNSSEC) sont acceptables.</note>
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 section((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…))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 [[https://www.zonemaster.fr/domain_check|zonemaster.fr]])

C'est tout !

<note important>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.</note>
<note tip>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.</note>

===== Vérification =====
Toute action((Surtout de cette ampleur. Il en va de la disponibilité du nom de domaine et de tous les services bâtis sur ce nom.)) demandant vérification, on effectue un diagnostic complet de la configuration DNSSEC de la zone :
  * [[http://dnssec-debugger.verisignlabs.com/|Un outil en ligne]] proposé par Verisign
Pour que tous les feux soient au vert, il faut attendre que les serveur DNS faisant autorité((Pas besoin d'attendre la propagation.)) 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 parente((Que ce soit un tld ou pas ;-) ))) 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înage((Depuis les tld jusqu'à la zone concernée.)) 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 parente((Pour un domaine de niveau 2, l'entité parente n'est autre que le Registre.)). 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é((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.)), 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 DNS((authenticated denial of existence.)): 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 [[https://www.bortzmeyer.org/7583.html|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.