Déploiement de DNSSEC

1.Introduction 

DNSSEC a pour vocation de protéger la résolution DNS contre un certain nombre d’attaques. Cette technologie reste aujourd’hui la seule solution reconnue et effective contre une attaque de type empoisonnement de cache (cache poisoning). Néanmoins, son déploiement nécessite un certain nombre de précautions, car, comme toute technique de sécurisation, une mauvaise mise en oeuvre risque de provoquer des incidents techniques/opérationnels majeurs. Ce document est destiné aux administrateurs système d’un hébergeur DNS1 souhaitant déployer DNSSEC afin de signer les zones qu’ils gèrent en minimisant le risque de problèmes. Pour cela, l’orientation de ce guide se veut didactique et privilégiant les solutions résistantes aux erreurs d’exploitation plutôt que celles qui résistent aux attaques massives. Certains choix pourront donc être simplifiés afin de permettre une mise en place rapide.

Composantes de la chaine de confiance DNSSEC

Le déroulé de ce guide partira des prérequis qu’il convient de valider avant d’envisager un déploiement de DNSSEC en production, puis exposera deux exemples concrets de gestion de DNSSEC avec les logiciels OpenDNSSEC+NSD ou avec BIND.

2. Les prérequis

DNSSEC change le modèle de fonctionnement du DNS. 

Sans DNSSEC, le DNS est en général dit statique. Il est initialement configuré, testé avec un logiciel comme Zonecheck, puis ne nécessite plus d’interventions particulières en dehors des modifications volontaires. DNSSEC oblige à penser différemment. En raison de l’expiration des signatures DNSSEC , il est important de re-signer périodiquement. En outre, il peut être utile de changer les clés de temps en temps, notamment pour être prêt si un changement est soudainement nécessaire. Si on ne fait jamais de changements, on sera fort dépourvu le jour où un changement s’impose (en cas de perte ou de compromission d’une clé, par exemple). Dans ce cas, il faut aussi gérer le remplacement de ces clés en complément des signatures. Aussi bien pour les signatures que pour les clés, les changements doivent se faire en respectant les délais imposés par les caches DNS. Ces caches DNS peuvent en effet garder l’information en mémoire et empêchent donc tout changement immédiat.

Avec DNSSEC, il faut avoir une perspective temporelle. 

Les signatures doivent être re-générées au moins $TTL avant leur expiration, pour tenir compte des problématiques de cache précitées. Cette opération est difficilement réalisable à la main5 et nécessite donc une automatisation du processus. La suite des prérequis s’adresse aux personnes souhaitant un déploiement en production. Dans le cas d’une simple expérimentation de la technologie DNSSEC, vous pouvez directement passer aux exemples concrets.

Ayez une configuration technique correcte 

Avec le DNS « traditionnel », tout marche même en cas d’erreur, en raison de la robustesse de ce protocole. DNSSEC représente un compromis différent : on diminue un peu la robustesse au profit de meilleures garanties d’intégrité. Il est donc nécessaire de bien comprendre et se former à DNSSEC. Un prérequis fondamental : tester l’exactitude de votre configuration DNS. Il existe une multitude d’outils6 en ligne pour cela. Nous nous concentrerons sur Zonecheck. Attention : Vérifiez bien tous les points indiqués par Zonecheck. Si certains vous semblent obscurs, prenez le temps de les étudier et de les comprendre. Rappelez-vous, DNSSEC nécessite une bonne compréhension de l’ensemble des mécanismes. Notamment, les points suivants doivent être testés : 

• que les serveurs faisant autorité répondent bien tous en EDNS 
• qu’ils peuvent effectivement envoyer des réponses de taille supérieure à 512 octets8 
• qu’ils peuvent effectivement envoyer des réponses de taille supérieure à la MTU du lien 
• qu’ils peuvent répondre en TCP.

DNSSEC est un protocole relativement ancien (la norme actuelle date de 2005) mais certains logiciels n’ont intégré DNSSEC complètement, et sans bogues que depuis deux ou trois ans. Il est donc essentiel de n’utiliser que des logiciels récents. Si, pour une raison d’administration système, vous êtes provisoirement contraint de n’utiliser que des versions anciennes, il est alors plus prudent de requalifier / replanifier vos projets de mise en oeuvre de DNSSEC.

Supervisez... 

Un système DNS fiable nécessite une supervision. Même s’il est parfaitement configuré, les choses peuvent changer par la suite, un serveur peut « crasher », un pare-feu être (mal) reconfiguré, etc. Tous les hébergeurs DNS ont une supervision en place avec des outils comme Nagios par exemple. Cette supervision s’avère encore plus nécessaire avec DNSSEC. 

Un exemple de problème détectable grâce à des outils de supervision est par exemple le filtrage d’accès : si un serveur esclave ne se met plus à jour en raison d’un filtrage accidentel de son accès, avec le DNS traditionnel, la seule conséquence sera la distribution d’informations éventuellement obsolètes. Mais, avec DNSSEC, lorsque les signatures stockées sur ce serveur auront expiré, toute la zone sera invalidée. Il faut donc être informé rapidement afin de pouvoir y remédier. Des tests supplémentaires doivent aussi être prévus tels que :

 • tous les serveurs répondent avec les signatures ;

• que les signatures ne soient pas proches de l’expiration ; 

• etc. 

Synchronisez vos horloges 

DNSSEC dépend d’horloges qui doivent être à l’heure exacte puisque les signatures contiennent une date de début et une date de fin de validité. Si vous signez sur une machine dont l’horloge est en retard, vos signatures pourraient être considérées comme expirées avant même que vous ne les publiiez. Bien sûr, avoir des machines à l’heure fait partie des bonnes pratiques depuis de nombreuses années mais, avant DNSSEC, le non-respect de ces recommandations n’avait pas forcément de conséquences visibles. Les horloges doivent donc être maintenues à l’heure, par exemple via NTP, et ce maintien doit être supervisé par un logiciel de supervision .

Sécurisez votre stockage 

DNSSEC utilise la cryptographie et, à cet égard, reprend les mêmes problématiques que d’autres systèmes de cryptographie, par exemple les certificats X.509. Ainsi, il faut garder les clés privées... privées, afin d’éviter leur copie par un attaquant, tout en ayant des sauvegardes qui permettront de les récupérer si le système de stockage est défaillant. 

Si vous gérez déjà des systèmes cryptographiques, 

DNSSEC ne vous surprendra pas. Si vous débutez la cryptographie avec DNSSEC, prudence. 

Une clé DNSSEC privée stockée en mode « lecture pour tous » sur une machine qui est également un serveur Web public avec plein de scripts programmés sans souci de sécurité est sans doute à éviter.

3. Choix Technique

La gestion des clés 

Deux choix importants seront à faire au sujet de la gestion des clés. 

D’abord, faut-il une clé ou deux pour la zone ? À lire beaucoup de textes sur DNSSEC, on peut avoir l’impression que la séparation en deux clés, la KSK (Key Signing Key) et la ZSK (Zone Signing Key) est obligatoire. Mais ce n’est pas le cas. On peut très bien n’avoir qu’une seule clé. Les conseils que nous donnons sont « si vous gérez vos zones à la main, comme dans l’exemple BIND ci-dessous, n’utilisez qu’une seule clé » et « si vous utilisez un outil de gestion de clés comme OpenDNSSEC, n’hésitez pas à avoir deux clés, l’outil s’occupera de tout ». Il est à noter que le choix du logiciel BIND ou d’OpenDNSSEC est a priori indépendant du choix du nombre de clés, les deux outils permettant d’implanter les deux stratégies de gestion de clés.

 Seconde décision à prendre sur la gestion des clés : où conserve-t-on les clés ? La méthode la moins sûre est lorsque les clés sont simplement stockées sur le serveur qui fait les signatures. La plus sûre est celle d’un HSM (Hardware Security Module), un ordinateur spécialisé et durci qui stocke les clés et réalise les signatures. Entre les deux, on peut avoir des clés qui sont gardées sur un support USB enfermé dans un coffre-fort et sorti les jours où l’on signe (soit parce qu’on a modifié les données, soit parce que l’on doit re-signer avant expiration).

 L’usage des HSM nécessite un investissement pour leur acquisition et leur appropriation technique (formation). La décision de les utiliser ou pas est a priori guidée par un arbitrage sur les coûts associés aux risques à couvrir/accepter. En pratique, dans le cas de zones considérées importantes/critiques par l’opérateur DNS, ce dernier investit dans des HSM. Dans le cas contraire (zones « ordinaires »), d’autres solutions sont privilégiées. 

La solution du coffre-fort est tentante, mais manque de souplesse, elle interdit d’utiliser les outils de re-signature automatiques, comme ceux présentés dans la prochaine section. Cette solution augmente certes le niveau de protection de la clé de signature contre le vol/compromission, mais elle induit un sur-coût en tâches d'administration : mise en ligne manuelle et périodique de la clé pour les signatures et installation d'un système de rappel/surveillance des signatures pour éviter l’oubli de re-signer. 

Une solution, la plus pratique dans le cas de zones ordinaires, est de garder les clés sur le serveur de signature. Certes, c’est la moins sûre parmi toutes celles mentionnées dans ce document, mais, actuellement, cette solution a l’avantage de la simplicité ainsi que celui d’éviter de garder le statu quo (pas de signature et donc pas de sécurité du tout). Bien sûr, la clé doit être protégée par les mécanismes habituels de sécurité du serveur (ne pas la mettre dans un répertoire partagé, veiller à ses protections) et le serveur lui-même doit être administré selon les bonnes pratiques de sécurité (ne donner le mot de passe de root qu’aux seules personnes autorisées, appliquer les correctifs de sécurité...).

Les logiciels 

Il existe évidemment un grand choix de systèmes et de logiciels pour héberger les fonctions DNSSEC. Nous nous focaliserons sur la plate-forme la plus utilisée pour l’hébergement, Unix. Les exemples donnés ici sont pour une machine utilisant le système d’exploitation Debian et devront être légèrement adaptés pour d’autres systèmes. Pour les logiciels, la priorité a été donnée aux logiciels libres, avec un accent particulier sur deux solutions que nous connaissons et utilisons :

• OpenDNSSEC et NSD, 
• BIND avec auto-dnssec.

Aspects cryptographiques pratiques 

Ce document n’est pas un cours de cryptographie et passera donc rapidement sur cette section. Notez bien que, pour faire du DNSSEC, vous n’avez besoin que des aspects opérationnels de la cryptographie, ses facettes mathématiques ne sont pas nécessaires.

Pour les non-cryptographes, le seul choix pratique est « NSEC3 ou pas ». NSEC3, normalisé dans le RFC 5155, permet de limiter les risques d’énumération du contenu de la zone, via le zone walking. Si vos zones sont déjà publiques (transfert de zone autorisé) ou si le contenu de vos zones est trivial à énumérer (par exemple, il n’y a que l’apex et www), alors NSEC3 est inutile. Mais le cas inverse est bien plus fréquent et nous recommandons donc d’utiliser NSEC3. Au final, nous recommandons le choix de l’algorithme RSA + SHA256 (numéro 8 dans le registre IANA des algorithmes14). C’est celui qui est utilisé dans les exemples suivants.

Un exemple avec BIND 

BIND dispose, depuis la version 9.9, de la capacité de gérer les signatures et resignatures. Il reste à faire la gestion des clés mais on a vu plus haut qu’un remplacement systématique et automatique des clés n’est nullement obligatoire. Le principe avec BIND est donc le suivant : 1. créer la ou les clés ; 2. indiquer à BIND de gérer seul les signatures et re-signatures de la zone. On installe le seul logiciel nécessaire dans cet exemple, BIND, par exemple (sur Debian) avec : aptitude install bind9. Puis la première étape consiste à appeler dnssec-keygen. Ici, pour le cas d’une seule clé : 

dnssec-keygen -a RSASHA256 -3 -f KSK -b 2048 dnssec.fr 

Generating key pair.........+++ ...............................................+++ 

Kdnssec.tn.+008+49734 

Remarque : On peut ajouter l’option -n ZONE mais c’est la valeur par défaut, de toute façon. Si l’opération prend longtemps et que vous constatez avec un programme comme top que la machine ne fait pas grand-chose, c’est normal : la génération d’une clé nécessite de l’entropie pour fabriquer des nombres vraiment aléatoires et votre machine ne produit peut-être pas assez d’entropie. Paradoxalement, il faut faire travailler votre machine pour que cela aille plus vite (compiler un très gros programme, par exemple19), les entrées/sorties sur le disque étant la principale source d’entropie. Lorsque dnssec-keygen se termine, il crée deux fichiers :

 ls -lt Kdnssec.tn*

-rw-r--r-- 1 bortzmeyer bortzmeyer 598 Jul 19 10:53 

Kdnssec.fr.+008+49734.key 

-rw------- 1 bortzmeyer bortzmeyer 1776 Jul 19 10:53 

Kdnssec.tn.+008+49734.private

La clé privée est précieuse : elle doit être mise en sécurité, sur une machine fiable, tout en ayant des sauvegardes au cas où cette machine aurait une défaillance. Cette gestion des clés est une partie nouvelle et importante de DNSSEC. La clé publique doit être mise dans un répertoire où BIND la trouvera (key-directory voir plus loin).

Ensuite, il faut configurer BIND :

options { 

 directory "/etc/bind"; 

 key-directory "/var/bind/keys"; 

 recursion no;

 dnssec-enable yes;

 }; 

zone "dnssec.tn" in {

 inline-signing yes;

 auto-dnssec maintain; 

 update-policy local; # Necessary, says the ARM (otherwise, you cannot freeze/thaw) 

type master; 

 file "dnssec.fr"; ... } 

Et cela suffit. BIND trouvera les clés dans key-directory et signera tout seul. Et BIND re-signera lorsque cela sera nécessaire. Vous noterez que la zone a été signée avec NSEC. Pour NSEC3, il va falloir l’expliquer à BIND, et lui fournir un sel, un nombre aléatoire qui servira à rendre les attaques par dictionnaire plus difficiles : 

 dd if=/dev/random bs=1 count=10 | md5sum | cut -c1-8 

10+0 records in 

10+0 records out 

68f499ee 

10 bytes (10 B) copied, 0.00046732 s, 21.4 kB/s 

[On utilise ce sel]

rndc signing -nsec3param 1 0 10 68f499ee dnssec.tn

Et on peut voir que la zone est désormais signée avec NSEC3. Si on veut utiliser deux clés, une KSK et une ZSK, on doit d’abord les créer (notez la différence, -f KSK, ainsi que la taille plus petite de la ZSK) : 

dnssec-keygen -a RSASHA256 -3 -f KSK -b 2048 dnssec.tn 

Generating key pair....+++ ..................+++ 

Kdnssec.tn.+008+09634 % dnssec-keygen -a RSASHA256 -3 -b 1024 dnssec.tn

Generating key pair...............++++++ ...............++++++ 

Kdnssec.tn.+008+29433

On copie alors les deux clés dans le répertoire. BIND signera l’enregistrement DNSKEY avec les deux clés et tout le reste avec la ZSK. Une fois votre zone testée en détail, et après que tous les caches auront possédé les nouvelles informations, vous pourrez compléter la chaîne de confiance de DNSSEC en soumettant un enregistrement DS à la zone parente pour publication. Le DS de la zone se calcule avec dnssec-dsfromkey : 

 dnssec-dsfromkey Kdnssec.tn.+008+49734.key 

dnssec.tn. IN DS 49734 8 1 3C5BA1C95F17214536AA8E82E9406321A96FBD22 

dnssec.tn. IN DS 49734 8 2

 A3B4267E78CF26B4442007E14B55B8F7C83A4EB81015122410B9E47E FEA2DBFD

Si vous êtes Bureau d’Enregistrement, vous envoyez ces enregistrements DS vousmême, a priori en utilisant le protocole EPP. Sinon, vous devrez passer par le mécanisme fourni par votre BE, probablement une interface Web. En cas de changement du contenu, de la zone, vous devez signaler à BIND de resigner et de se recharger :

rndc freeze dnssec.tn 

[Éditer le fichier de zone] 

rndc thaw dnssec.tn

 A zone reload and thaw was started. 

Check the logs to see the result. 

On l’a vu, il n’est pas nécessaire de remplacer systématiquement les clés. Toutefois, on peut se retrouver dans l’obligation de le faire, par exemple parce qu’on découvre que la clé a été compromise, ou, tout simplement, pour tester les procédures pour le cas d’une telle compromission. Le principe avec BIND, pour le cas d’une clé unique, est le suivant : on crée la nouvelle clé, on la met dans le répertoire des clés, on modifie l’ancienne pour indiquer qu’elle n’est plus utilisée et BIND fera le remplacement : 

[Création de la nouvelle clé] 

dnssec-keygen -a RSASHA256 -f KSK -b 2048 dnssec.tn 

Generating key pair.....+++ .......................................+++ 

Kdnssec.tn.+008+00847 

[Copie dans le répertoire, si nécessaire] 

cp Kdnssec.tn.+008+00847* /where/are/the/keys

 [Modification de l’ancienne clé, la 49734] 

[Révocation immédiate] 

dnssec-settime -R +0 Kdnssec.tn.+008+49734.key 

[Retrait dans deux jours (le temps que la nouvelle clé soit dans tous les caches] 

dnssec-settime -I +2d Kdnssec.tn.+008+49734.key 

[Suppression dans six jours (le temps que les signatures avec l’ancienne clé aient disparu des caches) 

dnssec-settime -D +6d Kdnssec.tn.+008+49734.key

Attention, les délais doivent être calculés en tenant compte des TTL des enregistrements de la zone. Faites bien attention (ou bien utilisez OpenDNSSEC, qui gère tout cela automatiquement). Un changement de clé (key rollover) n’est pas une opération facile. N’oubliez pas non plus de changer l’enregistrement DS qui se trouve dans la zone parente et de synchroniser ce changement avec les changements faits dans votre zone. Là encore, cela peut s’avérer délicat et il vaut ne pas le réaliser l’opération sans une minutieuse préparation. 

Et pour ajouter une nouvelle zone à celles servies ?

 Les étapes sont les suivantes : 

1. générer des clés pour la nouvelle zone, 
2. ajouter la zone à la configuration (fichier named.conf), et le fichier de zone dans le répertoire de BIND,
3.  recharger le serveur (par exemple avec rndc reload).

Débogage

Pour les problèmes spécifiquement DNSSEC, l’outil le plus souvent utilisé est DNSviz. 

C’est un outil Web qui effectue un certain nombre de tests sur une zone signée et présente les résultats graphiquement, de manière très compréhensible. 

4.Conclusion 

Des nouvelles techniques permettant d’« améliorer » les attaques DNS par empoisonnement sont publiées régulièrement34. Travailler au déploiement de DNSSEC est donc une nécessité et permet de contribuer à la robustesse de cette ressource partagée qu’est le DNS. Mais DNSSEC est reste une technique nécessitant qualification, méthodologie et précision. Il est donc nécessaire de bien veiller au bon déroulement de son déploiement. Outre les lectures déjà mentionnées, nous attirons votre attention sur le guide nist.dnssec-deployment .