Délégation et gestion des sous-domaines avec Bind9
Il est possible de déléguer la gestion d'un sous domaine à des serveurs DNS auto hébergés.
Sur l'interface Amen par exemple, il faudra créer au minimum 3 enregistrements.
- On assigne le sous-domaine lui-même à un enregistrement de type A
- On attribue à ce sous-domaine deux enregistrements NS (name server).
Les deux enregistrements NS pointent vers des serveurs Bind que nous gérons nous-mêmes.
"NOM" "TTL" "TYPE" "VALEUR" "ns1.example.net." 900 "A" "41.42.43.81" "ns2.example.net." 900 "A" "51.52.53.81" "bobo.example.net." 900 "A" "31.32.33.81" "bobo.example.net." 900 "NS" "ns1.example.net." "bobo.example.net." 900 "NS" "ns2.example.net."
Les serveurs DNS fonctionnent en maître-esclave, c'est le minimum requis pour qu'une délégation soit possible.
Sur le serveur maître
- /etc/bind/named.conf.options
options { directory "/var/cache/bind"; querylog yes; dnssec-validation auto; auth-nxdomain no; # conform to RFC1035 listen-on { 127.0.0.1; 41.42.43.81; # l'adresse publique du serveur courant (maître) }; allow-transfer { 51.52.53.81; # l'adresse publique du serveur esclave }; };
- /etc/bind/named.conf.local
// Enregistrement de résolution DIRECTE (hostname --> IP) zone "bobo.example.net" IN { type master; file "/etc/bind/zones/bobo.example.net"; notify yes; check-names warn; allow-transfer { 51.52.53.81; }; // Adresse du serveur esclave }; // Enregistrements de résolution INVERSES (PTR) zone "43.42.41.in-addr.arpa" { type master; file "/etc/bind/zones/ns1.example.net.rev"; notify yes; allow-transfer { 51.52.53.81; }; // Adresse du serveur esclave }; zone "53.52.51.in-addr.arpa" { type master; file "/etc/bind/zones/ns2.example.net.rev"; notify yes; allow-transfer { 51.52.53.81; }; // Adresse du serveur esclave };
- /etc/bind/zones/bobo.example.net
$ORIGIN . $TTL 3600 ; 1 hour bobo.example.net IN SOA ns1.example.net. admin.ns1.example.net. ( 201 ; serial 600 ; refresh (10 minutes) 3600 ; retry (1 hour) 604800 ; expire (1 week) 3600 ; minimum (1 hour) ) IN NS ns1.example.net. IN NS ns2.example.net. IN A 31.32.33.81 $ORIGIN bobo.example.net. ns1 A 41.42.43.81 ns2 A 51.52.53.81 * CNAME bobo.example.net.
- /etc/bind/zones/ns1.example.net.rev
$TTL 3600 43.42.41.in-addr.arpa. IN SOA ns1.example.net. admin.ns1.example.net. ( 106 ; Serial 1h ; Refresh [1h] 10m ; Retry [10m] 1d ; Expire [1d] 10m) ; Negative Cache TTL [10m] ; Name Server 43.42.41.in-addr.arpa. IN NS ns1.example.net. ; PTR Records 81.43.42.41.in-addr.arpa. IN PTR ns1.example.net.
- /etc/bind/zones/ns2.example.net.rev
$TTL 3600 53.52.51.in-addr.arpa. IN SOA ns2.example.net. admin.ns2.example.net. ( 106 ; Serial 1h ; Refresh [1h] 10m ; Retry [10m] 1d ; Expire [1d] 10m) ; Negative Cache TTL [10m] ; Name Server 53.52.51.in-addr.arpa. IN NS ns2.example.net. ; PTR Records 81.53.52.51.in-addr.arpa. IN PTR ns2.example.net.
Si nous optons pour faire tourner Bind dans docker, voici le docker-compose.yml nécessaire :
- docker-compose.yml
version: '3.4' services: bind: network_mode: host restart: always image: sameersbn/bind:latest container_name: bind environment: - WEBMIN_ENABLED=false volumes: - ./bind:/data
Il faut veiller à utiliser network_mode: host
L'image docker internetsystemsconsortium/bind9:9.18 est également à considérer car produite par l'Internet Systems Consortium responsable du développement de Bind9.
Sur le serveur esclave
La configuration sur le serveur esclave est un miroir de la configuration du serveur maître avec quelques différences importantes.
D'abord nous allons tester que le serveur maître répond aux requêtes de transfert de zone. C'est le mécanisme par lequel le serveur esclave duplique automatiquement les configurations du maître.
Sur un terminal 1) exécuter la commande suivante (remplacer l'ip du serveur maître)
dig @41.42.43.81 bobo.example.net. axfr
- /etc/bind/named.conf.options
options { directory "/var/cache/bind"; dnssec-validation auto; auth-nxdomain no; /* # conform to RFC1035 */ allow-query { 127.0.0.1; 41.42.43.81; 51.52.53.81; }; listen-on { 127.0.0.1; 51.52.53.81; // Adresse publique du serveur courant (esclave) }; allow-transfer { 41.42.43.81; // Adress publique du serveur maître }; };
- /etc/bind/named.conf.local
zone "bobo.example.net" IN { type slave; file "/var/lib/bind/zones/bobo.example.net"; masters { 41.42.43.81; }; // Adresse du serveur maître }; zone "43.42.41.in-addr.arpa" { type slave; file "/var/lib/bind/zones/ns1.example.net.rev"; masters { 41.42.43.81; }; // Adresse du serveur maître }; zone "53.52.51.in-addr.arpa" { type slave; file "/var/lib/bind/zones/ns2.example.net.rev"; masters { 41.42.43.81; }; // Adresse du serveur maître };
La différence entre les fichiers named.conf.local sur les serveurs maître et esclave, c'est l'emplacement des fichiers de zones.
Si sur le maître, les fichiers peuvent se trouver dans le dossier /etc/bind comme
zone "bobo.example.net" IN { type master; file "/etc/bind/zones/bobo.example.net"; ////////////// <--------- ICI notify yes; check-names warn; allow-transfer { 51.52.53.81; }; // Adresse du serveur esclave };
Ça ne peut être le cas sur le serveur esclave. Les fichiers doivent se trouver à un emplacements inscriptible par l'utilisateur bind. C'est pour cela que les fichier sont conservés dans le dossier /var/lib/bind comme ceci :
zone "bobo.example.net" IN { type slave; file "/var/lib/bind/zones/bobo.example.net"; masters { 41.42.43.81; }; // Adresse du serveur maître };
Autrement, le transfert automatique de zone entre le maître et l'esclave va échouer en raison des autorisations d'écriture.
Les fichiers de zones sur le serveur esclave sont créés automatiquement par le transfert de zone. Il n'y a pas lieu de les créer manuellement.
allow-transfer du fichier named.conf.options sur le serveur maître)