Bonjour à toi Lecteur, ça faisait un moment.

Aujourd'hui on va parler de quelque chose dont on a beaucoup entendu parler, qui inspire la crainte et l'espoir, l'orgueil et la peur. DNSSEC, ce système, permet de bloquer les serveurs DNS menteurs. Les serveurs DNS menteurs sont les 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, OpensDNS 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.

Comme tu le constates, cher Lecteur, il y a plein d'endroits où trouver des réponses à des requêtes DNS, mais il n'y a rien qui dit que la réponse est la bonne !

C'est pour résoudre ce problème simple qu'a été inventé DNSSEC. 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-domaines. Je ne critique pas le fait qu'il n'y ait presque aucune documentation (vraiment aucune) sur le DNSSEC pour ses sous-domaines. 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 applicable la technique à ses sous-domaines. 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.

C'est pourquoi le script ne peut pas fonctionner si l'on ne lui indique pas le domaine principal. Si on lui indique que 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-domaines à 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. 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, un schéma vaut mieux qu'un long discours :

Capture d’écran du 2019-09-28 23-04-09.png

Une idée d'amélioration : pouvoir intégrer DNSSEC sur une zone DNS d'un sous-sous-domaine.

Capture d’écran du 2019-09-28 23-04-54.png