Coucou !
Alors en fait les deux tutoriels listés plus haut sont vraiment beaucoup trop compliqué par rapport à ce que c’est et il y a moyen de faire BEAUCOUP plus simple pour activer DNSSEC sur une zone avec Bind, comme l’explique très bien le tutoriel de la doc officielle de Bind (décidément).
Concrètement ça se résume à ajouter dnssec-policy default; à la zone sur laquelle on veut activer DNSSEC, puis transmettre le contenu de la clé générée au serveur parent, via le registraire.
Ajouter cette ligne de configuration fait tout pour nous : ça génère une clé pour la zone et ça signe automatiquement les zones lorsqu’elles ont changé.
Mais il y a quand même un hic : juste après avoir ajouté cette ligne, je me retrouve avec des erreurs de ce style :
/etc/bind/db.club1.fr.signed.jnl: create: permission denied
Effectivement, comme c’était indiqué tout au début du tutoriel :
In this chapter, we assume all configuration files, key files, and zone files are stored in /etc/bind, and most examples show commands run as the root user. This may not be ideal, but the point is not to distract from what is important here: learning how to sign a zone. There are many best practices for deploying a more secure BIND installation, with techniques such as jailed process and restricted user privileges, but those are not covered in this document. We trust you, a responsible DNS administrator, to take the necessary precautions to secure your system.
Et les mainteneurs Debian sont justement des « responsible DNS administrator ». Ils ont donc modifié la configuration par défaut de Bind pour la segmenter dans différents dossier avec des droits différents. Et pour couronner le tout, ils ont également ajouté une configuration AppArmor pour verrouiller les droits du serveur Bind de manière encore plus restrictive :
/etc/bind/** r,
/var/lib/bind/** rw,
/var/lib/bind/ rw,
/var/cache/bind/** lrw,
/var/cache/bind/ rw,
La méthode la plus simple et celle qui est recommandé par le tutoriel, est d’ajouter la dnssec-policy default;, qui utilise la configuration inline-signing yes;. Cette technique consiste à générer un fichier de zone signé à côté de celui d’origine, en lui ajoutant le suffixe .signed. Cependant nos fichiers de zones de se trouvent dans /etc/bind (ce qui est tout à fait normal) et les mainteneurs Debian on fait en sorte, à juste titre, d’interdire à Bind d’écrire dans ce dossier. C’est une bonne pratique de sécurité, mais elle nous embête un peu dans notre cas !
Qu’à cela ne tienne j’ai simplement donné les permissions à Bind de modifier /etc/bind… mais non, je rigole !
J’ai profité du dossier /var/lib/bind, prévu pour être accessible en écriture pour y stocker les zones signées. Malheureusement il n’existe pas de configuration pour indiquer à Bind où stocker ces fameuses zones signées, il le fait toujours à côté des zones source. Donc pour résoudre ce problème, j’ai créé un lien symbolique de /var/lib/bind/db.club1.fr vers /etc/bind/db.club1.fr et j’ai indiqué à Bind d’utiliser le fichier de /var/lib/bind comme source pour la zone club1.fr :
@@ -15,7 +15,8 @@ include "/etc/bind/club1.fr-he.net.key";
zone "club1.fr" {
type master;
- file "/etc/bind/db.club1.fr";
+ file "/var/lib/bind/db.club1.fr";
+ dnssec-policy default;
allow-transfer {
key "club1.fr-he.net";
};
De cette manière, Bind arrive bien à créer les zones signées :
$ ls -al /var/lib/bind/
total 64
drwxrwxr-x 2 root bind 4096 sept. 23 15:23 .
lrwxrwxrwx 1 root root 21 sept. 23 15:18 db.club1.fr -> /etc/bind/db.club1.fr
-rw-r--r-- 1 bind bind 512 sept. 23 15:23 db.club1.fr.jbk
-rw-r--r-- 1 bind bind 5707 sept. 23 15:23 db.club1.fr.signed
-rw-r--r-- 1 bind bind 34773 sept. 23 15:23 db.club1.fr.signed.jnl
Un dernier point que j’ai décidé d’améliorer est le choix du dossier où sont sauvegardée les clés DNSSEC. Par défaut, la configuration Bind de Debian stocke tous les fichiers générés dans /var/cache/bind, c’est cohérent dans la plupart des cas, c’est par exemple là que seront stockées les zones secondaires. Cependant, dans le cas des clés DNSSEC c’est beaucoup plus problématiques, car celles-ci ne doivent pas changer, et donc ne doivent pas être perdues. Or, l’ensemble du dossier /var/cache est exclus des sauvegardes CLUB1, c’est très pratique car ça permet d’éviter de sauvegarder des données qui peuvent être par la suite régénérées, mais ce n’est pas vraiment le cas des clés DNSSEC. J’ai donc ajouté la configuration suivante :
@@ -22,6 +22,10 @@ options {
// you will need to update your keys. See https://www.isc.org/bind-keys
//
+ // Store DNSSEC keys in /var/lib instead of /var/cache as the former is
+ // backed up while the latter is not.
+ key-directory "/var/lib/bind/keys";
+
//dnssec-enable yes;
dnssec-validation auto;
Et on obtient donc l’arborescence suivante :
$ tree /var/lib/bind/
/var/lib/bind/
├── db.club1.fr -> /etc/bind/db.club1.fr
├── db.club1.fr.jbk
├── db.club1.fr.signed
├── db.club1.fr.signed.jnl
└── keys
├── Kclub1.fr.+013+08897.key
├── Kclub1.fr.+013+08897.private
└── Kclub1.fr.+013+08897.state
Finalement comme l’explique le tutoriel, il ne reste qu’à publier la clé dans les serveurs parents, c’est spécifique à chaque registraire, pas grand chose à ajouter là dessus.
Nous voila donc avec DNSSEC correctement configuré sur club1.fr et plutôt proprement ! Quelques liens pour analyser le résultat :
Le serveur CLUB1 étant encore sur une assez ancienne version d’Ubuntu (tant que la Migration de Ubuntu vers Debian #9 n’est pas finie), notre version de Bind est encore configuré par défaut avec inline-signing yes;, mais il faudra faire attention lors de futures mise-à-jour car Bind risque fort de planter au démarrage pour nous forcer à ajouter cette configuration explicitement.
Malheureusement il n’est pas non-plus possible d’ajouter cette configuration dès maintenant car notre version actuelle de Bind plante lorsqu’elle est présente :
inline-signing: cannot be configured if dnssec-policy is also set