{{tag> dns bind subdomains}}
===== 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 [[https://www.amen.fr/|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 ====
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
};
};
// 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
};
$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.
$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.
$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 :
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'[[https://www.isc.org/|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 ((
veiller à exécuter cette commande sur le serveur esclave, seul autorisé à émettre une requête de transfert de zones (voir l'instruction ''allow-transfer'' du fichier ''named.conf.options'' sur le serveur maître)
)) exécuter la commande suivante (remplacer l'ip du serveur maître)
dig @41.42.43.81 bobo.example.net. axfr
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
};
};
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.