Aujourd’hui on va parler de quelque chose qui fait beaucoup parler de lui. DNSSEC, ce système, permet de bloquer les serveurs DNS menteurs. Tous les serveurs DNS ne sont pas des menteurs, mais ceux qui mentent, on les retrouve sous la forme de résolveurs utilisés par les utilisateurs d’Internet. Ce sont ceux des FAI pour le grand public, ce sont ceux des entreprises dans les grandes entreprises, et ceux d’OpenDNS ou Google pour les geeks.

Ces résolveurs ne sont pas trop à craindre, il y a peu d’abus. Sauf, sur les résolveurs des FAI qui suivent les censures d’État, OpenDNS qui applique une politique non-neutre, Google qui doit bien défendre ses intérêts, etc…

Et puis, en dehors des résolveurs, il y a d’autres mécanismes pour résoudre les noms en adresse IP directement implantés dans le système de chaque machine (/etc/hosts), et il y a le cache du navigateur en plus.

En résumé, il y a plein d’endroits où trouver des réponses à des requêtes DNS, mais il n’y a aucun moyen de vérifier que la réponse est la bonne !

Pour résoudre le problème, DNSSEC a été inventé. Il est très compliqué à mettre en place et demande beaucoup d’actions manuelles. Et le pire, c’est qu’il faut renouveler toutes ces actions tous les mois pour compenser la petite taille des clés cryptographiqes, afin de maintenir un bon niveau de sécurité sur la zone DNS.

Autant dire qu’il parait impensable de le mettre en place dans ces conditions. Ceci était mon premier constat.

Il y a plein d’articles sur Internet qui expliquent comment installer DNSSEC, je mets de coté le fait qu’ils ont l’air compliqués, ce n’est pas le problème. Il y a deux problèmes en réalité.

Le premier est que tous ces articles expliquent comment mettre en place DNSSEC avec un bureau d’enregistrement (Registrar), sans expliquer le principe de base. Pour moi, c’est trop obscure, et je pense que ça a dû rebutter beaucoup de personnes.

Le second problème est que, si l’on ne peux pas comprendre le principe de base, comment peut-on appliquer le principe à ses sous-zones ? Je ne critique pas le fait qu’il n’y ait presque aucune documentation (vraiment aucune) sur le DNSSEC pour les sous-zones. Je ne suis pas un consommateur et je n’aime pas quand c’est tout cuit.

J’ai donc écumé le web, et j’ai trouvé cet article, qui explique à la perfection le principe de base, et qui rend la technique applicable à ses sous-zones. On chauffe…

Et là, cher Lecteur, tu te dis :

Aoutch, il faut multiplier le travail par le nombre de zone DNS pour les sous-domaines ! /o\

Oui mais non. Grâce à cet article, j’ai pu suffisament bien comprendre la technique pour faire un script qui automatise tout.

Absolument « tout » ?

C’est obligatoire, le DNSSEC est une chaine, on ne peut pas reprendre la chaine à mi-chemin, en cours de route. Ça ne fonctionne pas comme ça.

Du coup, le script ne peut pas fonctionner si l’on ne lui indique pas le domaine principal. Si on lui indique uniquement le domaine principal, il va faire le job. Mais l’idée de ce script, c’est de lui indiquer autant de zones DNS de sous-domaine que l’on veut : il va faire le travail pour intégrer les sous-zones à la zone du domaine principal. Le gain de temps est monstrueux.

On peut le relancer tous les mois ou toutes les semaines pour changer le salage. On peut le lancer tous les 3 mois pour changer toutes les clés cryptographiques à la volée. Il affiche dans la console toutes les informations utiles pour mettre à jours les enregistrements chez son Registrar.

Alors certes, ce billet n’est pas une énième doc sur le DNSSEC, mais je tenais à partager mon script. Je le fais tourner intensément depuis 2 petites semaines, et les résultats sont bons…

Voici les dessins produits par un validateur en ligne pour 2 de mes sous-zones DNS.

Un schéma vaut mieux qu’un long discours :

Une idée d’amélioration du script : pouvoir intégrer DNSSEC sur une zone DNS d’une sous-sous-zone.