Gérer votre zone DNS avec Unbound ? NSD en renfort
Unbound est diablement efficace en tant que résolveur, cache, et le support du DNSSEC. Je ne suis pas encore à l’aise sur ce dernier point, mais j’avais besoin d’une autre fonctionnalité. Quand vous devez gérer votre zone DNS, comme je voudrais le faire avec seboss666.ovh, là, il est fort dépourvu. Voyons donc comment appeler NSD à la rescousse.
Unbound, vite fait, bien fait
Je me suis simplement rebasé sur l’article de tom23 sur homeserver-diy.net. Là pour le coup c’est pas original, je cherche à avoir mon propre résolveur local. J’ai du faire une ou deux petites modifications pour qu’il réponde à toutes les demandes, et pour des besoins que j’expliciterai plus tard, qu’il réponde aussi quand l’adresse IP est locale.
Mais je voulais également pouvoir gérer le contenu de la zone DNS seboss666.ovh. Et là, je me suis heurté à un mur, manifestement il est vraiment, vraiment pas conçu pour ça. Alors après m’être cassé la tête là-dessus, j’ai fini par abandonner, et j’ai confié la tâche à NSD.
NSD, l’autorité, rien que l’autorité
NSD ne fait qu’une chose, et la fait bien : être l’autorité d’une zone DNS. Ça tombe bien, c’est pile-poil la fonction qui me manque dans Unbound.
Pourquoi pas BIND ? Il est vrai que les ressources sont nombreuses, qu’il est capable de tout faire, bref, il parait que c’est le candidat idéal. C’est aussi un vieux monsieur, souvent sujet aux failles de sécurité, et comme je le pratique déjà un peu au boulot, c’était mieux de manipuler autre chose à la maison pour ne pas mettre tous ses œufs dans le même panier.
Configuration du couple
Côté Unbound, après avoir supprimé la ligne private address du fichier original, j’ai ajouté les deux lignes suivantes :
1 2 3 |
stub-zone: name: "seboss666.ovh" stub-addr: 127.0.0.1@8053 |
C’est plutôt explicite : tu renvoies la demande à machin si ça concerne le domaine bidule. Bidule étant ici le surnom d’NSD, mais vous pourriez utiliser n’importe quel autre outil.
D’ailleurs NSD sa configuration est des plus simples :
1 2 3 4 5 6 7 8 9 10 |
server: hide-version: yes ip-address: 0.0.0.0@8053 zonesdir: "//etc/nsd/zones" remote-control: control-enable: yes zone: name: "seboss666.ovh" zonefile: "seboss666.ovh" |
Ensuite j’ai collé une copie du contenu de la zone dans un fichier, NSD utilise le même format que BIND ce qui est diablement pratique.
On redémarre ensuite le bousin et on teste depuis une autre machine :
1 2 |
seboss666@gogs:/etc/nginx/sites-enabled$ dig ltpsrv.seboss666.ovh @192.168.1.200 +short 192.168.1.200 |
Tada!
Pourquoi faire ça ?
Ce setup, inutilement lourd peut-être, et un poil imparfait d’un point de vue sécurité, va me permettre de vous présenter un autre outil que je compte mettre en place dans un futur proche pour mes VMs : un rebond SSH. Et je pense coupler ce morceau avec un reverse-proxy Nginx pour tout ce qui aura besoin d’être contacté en mode Web. Encore des trucs à apprendre en perspective.
Oui, chacun son rôle (c’est l’idée générale).
Mais dans ce cas pourquoi ne pas mettre directement NSD en ip publique, plutôt que de mettre Unbound en intermediaire ?