Mettre en place une zone DNS interne

Ecrit le , 4 minutes de bouquinage

En mettant en place un mirroir APT pour éviter d'aller chercher x fois le même paquet dans les intertubes, je me suis également dit qu'il faudrait que je me fasse une petite zone DNS interne à mon réseau local. Jusque là, rien d'extraordinaire. Je voulais aussi remettre en place, pendant que j'y étais, un résolveur récursif.

Ce petit billet pourrait me servir de documentation pour moi-même et pour les autres qui voudraient tenter l'aventure. Le mirroir APT peut faire l'objet d'un billet séparé. Peut-être.

Ce que j'ai choisi

La liste est... simple.

  • Unbound pour le résolveur récursif
  • Bind pour la zone DNS.

On peut ne prendre que l'un ou l'autre, ces deux serveurs sont tout à fait capables de, respectivement, servir des enregistrements d'une zone définie dans les configurations et de résoudre récursivement des noms. J'aime la "simplicité" de la configuration d'Unbound et la facilité d'écriture de zone de Bind.

Je pars du principe que le domaine interne sera internal.example.com, mais cela peut être n'importe quoi. Inventer un TLD (Top Level Domain) "local" peut être une mauvaise idée, encore plus si l'ICANN décide de déléguer le TLD car vous allez arriver à des conflits. De plus, les domaines, de ces jours, ne sont pas chers et sont assez faciles à acquérir.

Unbound, le résolveur DNS

On va commencer par le résolveur. J'ai principalement suivi la configuration d'exemple bien garnie et bien documentée. Il faut faire attention à mettre l'option do-not-query-localhost à no. Ça fait une double négation et ça fait un peu étrange de dire "Tu ne vas pas ne pas requêter localhost". Sans cette option, Unbound ne fera pas de requête vers votre serveur faisant autorité puisqu'il sera sur le même hôte.

Évidemment, je ne veux pas tout résoudre récursivement si je veux faire une zone interne. Dans son fichier de configuration, Unbound propose de diriger les requêtes vers un serveur de noms faisant autorité:

stub-zone:
  name: "internal.example.com"
  stub-addr: 127.0.0.1@5353

Si le serveur faisant autorité se trouve sur le même hôte que le résolveur, il faudra le faire écouter sur une autre adresse pour des raisons évidentes: on ne peut pas faire écouter deux services sur un même port. Donc je fais écouter Bind sur le port 5353.

Avec cette option de configuration, Unbound fera suivre les requêtes vers notre serveur faisant autorité.

Bind, le serveur DNS faisant autorité

Maintenant que le résolveur sait où aller chercher lorsqu'on lui demande la zone interne, il faut bien songer à la mettre en place.

Le serveur de mon choix est Bind. La syntaxe de zone est assez facile à retenir et il fera l'affaire comme serveur faisant autorité. La configuration est à légèrement modifier, notamment pour y glisser un autre port d'écoute.

// Dans /etc/bind/named.conf.options

// Le port à changer
listen-on port 5353 { 127.0.0.1; };

// Désactiver la récursion, dans le cas improbable que les choses soient mal routées
recursion no;

// Dans /etc/bind/named.conf.local
zone "in.l4p1n.ch" IN {
  type master;
  file "/var/lib/bind/internal.zone";
};

La zone est une zone "classique" avec un $ORIGIN qui définit le domaine de base et un $TTL qui définit la TTL (time-to-live) par défaut. Suivi d'un enregistrement SOA et de la pléthore d'enregistrements qu'il faut insérer.

Ensuite, rechargez le tout et admirez le tout qui fonctionne avec un drill <serveur de nom>.internal.example.com @192.0.2.1:

;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 41813
;; flags: qr rd ra ; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1 
;; QUESTION SECTION:
;; ns1.internal.example.com.	IN	A

;; ANSWER SECTION:
ns1.internal.example.com.	1800	IN	A	192.0.2.1

;; AUTHORITY SECTION:
internal.example.com.	1701	IN	NS	ns1.internal.example.com.

;; ADDITIONAL SECTION:


;; Query time: 0 msec
;; SERVER: 192.0.2.1
;; WHEN: Sat Feb 15 13:31:50 2020
;; MSG SIZE  rcvd: 91

Évidemment, la zone n'est pas signée avec DNSSEC et l'installation reste assez simple. J'estime pas nécessaire de mettre en place ce mécanisme de vérification sur un setup qui sera utilisé sur mon réseau et pas à l'extérieur. Mes deux centimes.

Petit effet de bord

Pendant que j'utilisais mon petit système, j'ai remarqué un petit effet de bord avec HSTS (HTTP Strict Transport Security). En effet, en voulant accéder au miroir APT via l'adresse qui va bien, la redirection interne du navigateur est effectuée et... ça tombe sur une erreur de certificat puisque le nom de domaine ne correspond pas au certificat. Je me demande encore comment je vais pouvoir solutionner le problème:

  • certificat auto-signé ?
  • CA ACME ?

L'heure de la conclusion

Ça fonctionne bien, les containers et VMs sont branchés sur le résolveur DNS nouvellement mis en place. Comme dit précédemment, il subsiste un petit effet de bord dû à HSTS qui affecte aussi les sous-domaines.