Bind9 dans une jail 1/2

une jail pour Bind9

 Publié le 23.09.2018  |  jacques_foucry

Nous continuons notre mise en jails des services de notre machine FreeBSD. Aujourd’hui c’est au DNS et en particulier à bind9 que nous allons nous intéresser.

 Ce post n’est pas destiné à l’apprentissage de bind9 ou du dns. Pour cela, veuiller vous reporter sur ce post. Comme toujours, nous partons d’une jail fonctionnelle avec accès au réseau.

Configuration de pkg

C’est l’outil pkg qui nous permet de gérer l’installtion ou la désinstallation des paquets logiciels tout prêt. Par défaut celui va les chercher sur les serveurs de FreeBSD. Or, nous avons à notre disposition une poudriere. C’est-à-dire un dépôt local des logiciel dont nous avons besoin, spécialement compilés par nous et pour nous. Nous devons indiquer à pkg comment l’utiliser.  nous supposons ici que votre poudriere fonctionne et qu’elle est servie en https depuis l’hôte, ou depuis une autre jail. Il nous allons créer le répetoire /usr/local/etc/pkg/repos : 

$ mkdir -p /usr/local/etc/pkg/repos
$ cd /usr/local/etc/pkg/repos
Dans ce répertoire nous allons créer deux fichiers. Le premier indiquera comment accéder à la poudriere, nous le nommons poudriere.conf : 
1
2
3
4
5
6

poudriere: {
    url: "pkg+https://example.poudriere.com/packages/11Ramd64-default",
    mirror_type : "srv",
    enabled: yes,
    priority: 100
}
le second sert à désactiver l’accès aux dépots FreeBSD : 
FreeBSD {enable: no}
Et nous allons demander à pkg de prendre en compte sa nouvelle configuration : 
$ pkg update

 En cas de problème de communication entre la jail et la poudrière pour des raisons liées à SSL : 

Certificate verification failed for /C=US/O=Let's Encrypt/CN=Let's
Encrypt Authority X3
34405332376:error:14090086:SSL
routines:ssl3_get_server_certificate:certificate verify
failed:/usr/src/crypto/openssl/ssl/s3_clnt.c:1264:
Certificate verification failed for /C=US/O=Let's Encrypt/CN=Let's
Encrypt Authority X3
Il est nécessaire d’installer ca_root_nss avec la commande : 
cd /usr/ports/security/ca_root_nss ; make install

Installation des pré-requis

Nous avons besoin du logiciel bind9, des outils bind9 et nous auront besoin des outils opendnssec2 quand viendra le temps de configurer DNSSEC1

1

# pkg install named912 opendsnsec2 softhsm

Génération de la clef rndc

Ainsi que nous l’indique l’installation de bind, nous devons générer une clef pour rndc. Cela se fait simplement avec la commande : 

# rndc keygen

Et on trouve un fichier /usr/local/etc/namedb/rndc.key qui contient cette fameuse clef.

Copie des fichiers depuis l’hôte

Les fichiers de zone que nous avons déjà sur l’hôte vont être copié sur la jail. Nous allons faire de même avec les fichiers de configuration.

 Les manipulations qui suivent sont à faire sur l’hôte.

Copie des fichiers de configuration

Ces fichiers sont faciles à identifier (normalement), ils répondent tous au motif named.conf* :

# scp -r -P <dnsjail_sshport> /usr/local/etc/namedb/named.conf* <dnsjail_ip>:/usr/local/etc/namedb/.

Copie des fichiers de zones

Tout comme les fichiers de configuration, les fichiers de zones sont faciles à copier, ils sont, normalement, dans le répertoire /usr/local/etc/namedb/working. En copiant ce répertoire nous devrions tout à d’un seul coup : 

# scp -r -P <dnsjail_sshport> /usr/local/etc/namedb/working <dnsjail_ip>:/usr/local/etc/namedb/.

Verification des copies

les manipulations qui suivent sont à faire sur la jail

Nous allons vérifier que nos copies se sont bien passées en utilisant les commandes appropriées.

Vérification de la configuration

La commande namedcheck-conf va vérifier les fichiers de configuration : 

# namedcheck-conf -z /usr/local/bin/namedb/named.conf
…

Vérifiez que vous n’avez pas d’erreur, et si vous en trouvez, corrigez-les avant de passer à la suite.

Verification des zones

Pour chacune des zones que vous avez copiés, vous devez faire la vérification que tout est bon : 

# named-check-zone <zone> /usr/local/etc/namedb/working/<fichier de zone>
zone <zone>/IN: loaded serial 2016012902
OK

Si tout est bon, vous pouvez alors vous préparer à lancer votre nouveau DNS.

Lancement et test du nouveau DNS

Nous allons demander le lancement au démarrage de la jail de bind9 en ajoutant dans le fichier /etc/rc.conf cette demande. Cela peut se faire avec un éditeur de texte ou bien avec la commande sysrc : 

# sysrc named_enable="YES"
named_enable: NO -> YES

Et nous pouvons lancer notre nouveau service : 

# service named start

Test de notre serveur DNS

Il faut maintenant vérifier que notre serveur fonctionne et est capable de faire une résolution de nom : 

# dig freebsd.org

; <<>> DiG 9.12.2-P1 <<>> freebsd.org
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 3690
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: 024e54d17fbb6d8d28493d485b9a645c5075d32953532df7 (good)
;; QUESTION SECTION:
;freebsd.org.     IN  A

;; ANSWER SECTION:
freebsd.org.    3600  IN  A 96.47.72.84

;; Query time: 110 msec
;; SERVER: 192.168.12.6#53(192.168.12.6)
;; WHEN: Thu Sep 13 15:21:32 CEST 2018
;; MSG SIZE  rcvd: 84

On dirait que cela fonctionne.

Accessibilité de l’extérieur

Il est nécessaire de revoir la configuration de pf sur l’hôte pour que les paquets qui arrivent sur les ports du DNS soient bien envoyés vers la jail.

les manipulations qui suivent sont à faire sur l’hôte.

Modification de /etc/pf.conf

Commençons par faire une sauvegarde datée de ce fichier (même si je fais confiance à mes snapshot zfs). 

# cp /etc/pf.conf /etc/pf.conf-$(date +"%F-%T")

 cette méthode pour mettre la date et l’heure dans le nom d’un fichier de sauvegarde est fort pratique. Et nous allons éditer le fichier en question. Voici les éléments que j’ai ajouté au mien, à vous de l’adapter pour le vôtre2. 

1
2
3
4
5
6
7

# DNS / DoT / rndc redirection
rdr on $ext_if proto tcp from any to $ext_if port domain -> $dnsjail_ip port domain
rdr on $ext_if proto udp from any to $ext_if port domain -> $dnsjail_ip port domain
rdr on $ext_if proto tcp from any to $ext_if port 853 -> $dnsjail_ip port 853
rdr on $ext_if proto udp from any to $ext_if port 853 -> $dnsjail_ip port 853
rdr on $ext_if proto tcp from any to $ext_if port rndc -> $dnsjail_ip port rndc
rdr on $ext_if proto udp from any to $ext_if port rndc -> $dnsjail_ip port rnd

Avant la mise en production de notre nouveau fichier, il faut penser à vérifier qu’il est correct3 : 

# pfctl -vnf /etc/pf.conf

Si vous ne rencontrez pas d’erreur, vous pouvez indiquer à pf d’utiliser votre nouveeau fichier. Si vous avez pleinement confiance en vous, vous pouvez également suprimer le fichier de sauvegarde : 

# pfctl -f /etc/pf.conf

Un resolveur pour les gouverner tous

Nous venons d’installer un serveur DNS faisant autorité pour nos zones, comme nous l’avions fait précédement. Jusqu’à présent, le sereur ‘DNS’ de notre infrasture n’était pas dans une jail et nous avions, sur l’hôte, un fichier /etc/resolv.conf qui contenait les adresses des serveurs de DNS de notre fournisseur, ou ceux de openDNS, ou encore FreeDNS. Et cela convenait très bien. Maintenant que le DNS a migré dans une jail, les choses sont un peu différentes. Nous ne pouvons plus, sur les jails, faire appel à un quelquonque, serveur sur l’hôte. Nous allons donc installer un résolveur, poout toutes nos machines, que ce soit l’hôte ou les jails. Il est sans doute exagéré de faire une jail pour cela. Nous allons plutôt utiliser une jail qui existe déjà. Par exemple notre jail PostgreSQL.

Installation de unbound

Nous allons nous connecter sur la jail PostgreSQL et y installer le résolveur unbound4.

# pkg install unbound

Configuration de unbound

La configuration de unbound peut être très compliquée nous allons nous contenter des plus simples. La première partie à configurer est la partie server. Nous allons simplement ici indiquer qui a le droit d’utiliser notre résolveur.

  interface: 0.0.0.0
  interface: ::0
  access-control: 192.168.12.0/24 allow
  access-control: ::1 allow
  verbosity: 1

Avec ces lignes, nous autorisons toutes les jails existantes et les futures (jusqu’à 254 jails) à utiliser ce service. Plus loin dans ce même fichier se trouve l’autre partie que nous devons configurer, les ForwardZone (au environ de la ligne 820 de mon fichier). C’est dans cette section que nous allons indiquer à unbound quels serveurs interroger. Nous pourrions mettre notre propre serveur. Mais pour éviter les « pannes » en casades si nous modifions notre serveur ‘DNS’ nous allons indiquer d’autres serveurs, fiables et respectueux de la vie privée.5 En l’occurrence nous allons indiquer les serveurs de ‘OpenDNS’ et de ‘FreeDNS’. 

1
2
3
4
5
6

forward-zone:
  name: "."
  forward-addr: 208.67.222.220  # OpenDNS
  forward-addr: 208.67.222.222  # OpenDNS# Authority zones
  forward-addr: 37.25.1.174   # FreeDNS
  forward-addr: 37.25.1.177   # FreeDNS

Nous indiquons que pour la zone . (la racine du système de nommage de nom ‘DNS’) nous utilisons les serveurs indiqués.

Bonus

Lorsque je lance le VPN qui me permet de me connecter aux serveurs mon employeur, il est préférable d’utiliser les serveurs DNS de l’entreprise. Celle-ci dispose de son FQDN, non diffuser aux serveurs racines. En revanche, pour résoudre un serveur de la zone . je vais continuer à utiliser les serveurs précédemment configurés. Je vais ajouter une nouvelle FowardZone, qui correspond à celle de l’entreprise6 : 

1
2
3
4

forward-zone:
  name: "example.com"
  forward-addr: 203.0.113.23
  forward-addr: 203.0.113.48

Lancement de unbound

Nous allons tout d’abord indiquer que nous voulons sur unbound soit lancer au démarrage de la jail : 

# sysrc unbound_enable="YES"

Il est temps de le démarrer : 

# service unbound start

Et de le tester en changeant le fichier /etc/resolv.conf de la jail (elle va être cliente d’elle-même pour ce service) 

nameserver 192.168.12.4

Et en faisant une requête : 

# host freebsd.org
freebsd.org has address 96.47.72.84
freebsd.org has IPv6 address 2610:1c1:1:606c::50:15
freebsd.org mail is handled by 30 mx66.freebsd.org.
freebsd.org mail is handled by 10 mx1.freebsd.org.

Fin de la première étape

Normalement nous avons maintenant un serveur DNS faisant autorité pour les zones que vous lui avez confié. Nous avons également un résolveur, indépendant de notre serveur de zone. Désormais toutes nos jails, mais également l’hôte, pourront bénéficier de ce résolveur. Dans la seconde partie nous verrons comment signer les zones dont notre serveur ‘DNS’ a la responsabilité avec DNSSEC

 Merci à mon camarade Shaft pour sa relecture et ces conseils

  1. Pour comprendre et apprendre DNSSEC je vous conseille de vous rapporter au billet de Stéphane Bortzmeyer sur le sujet. ↩︎

  2. étrangement si domain (port 53) et rndc (port 953) sont connus de /etc/services, DoT (port 853 DNS over TLS) ne s’y trouve pas. Il est possible de l’ajouter ceci dit, en ce basant sur le registre de l’IANA. ↩︎

  3. il est vrai que pfctl réalise une vérification du fichier, mais je préfère toujours m’assurer que tout fonctionne correctement. ↩︎

  4. attention, vous aurez sans doute besoin de modifier le fichier /etc/resolv.conf pour y mettre les adresses des serveurs DNS de votre choix (ceux de votre fournisseur d’accèss, ceux d’openDNS ou de FreeDNS) afin de permettre à pkg d’aller chercher le paquet nécessaire. ↩︎

  5. il est aussi possible de laiser unbound faire le travail tout seul sans faire de configuration spécifique. ↩︎

  6. ceci est valable si vous faites tourner unbound sur votre machine locale. Cela peut être une bonne idée sur une machine nomade, pour pallier à la déficience des accès internet des hotels et centre de congrès. ↩︎

powered by FreeBSD