In questo articolo vedremo come configurare una coppia di server dns in configurazione master-slave con bind su debian 9
Nell’esempio utilizzeremo come master un server con nome ns1.intranet ed indirizzo ip 10.0.0.1, come slave un server con nome ns2.intranet. ed indirizzo 10.0.0.2, una zona denominata intranet. che risolve i nomi della rete interna 10.0.0.0 ed una denominata 0.0.10.in-addr.arpa che esegue la risoluzione inversa. Utilizzeremo una terza macchina per interrogare i due dns che risponderà al nome host.intranet. con indirizzo 10.0.0.3
I trasferimenti di zona e l’inserimento di resource record nel server master verranno autenticati tramite chiavi tsig
Su entrambi i nodi inseriamo localhost come resolver principale
|
1 2 3 |
cat > /etc/resolv.conf <<! nameserver 127.0.0.1 ! |
Nell’host di test
|
1 2 3 4 |
cat > /etc/resolv.conf <<! nameserver 10.0.0.1 nameserver 10.0.0.2 ! |
Chiavi di autenticazione
Sul nodo master utilizziamo tsig-keygen per creare due diverse chiavi tsig
La prima verrà installata solo nel dns master e ci servirà far autenticare nsupdate con cui amministreremo la zona intranet. inserendo e cancellando i resource record
|
1 |
master:~# tsig-keygen intranet-admin.key > /etc/bind/intranet-admin.key |
La seconda verrà installata su entrambi i server e servirà per autenticare i trasferimenti di zona in modo da impedire che chiunque possa inserire record nei server slave fingendo di essere il master
|
1 |
master:~# tsig-keygen intranet.key > /etc/bind/intranet.key |
Per semplicità copiamo la chiave sul dns slave via ssh, ma ogni altro metodo equivalente va comunque bene
|
1 |
master:~# scp /etc/bind/intranet.key 10.0.0.3:/etc/bind/intranet.key |
Configurazione Master
Per prima cosa creiamo il file zones.intranet che conterrà le dichiarazione della zona intranet. de della zona 0.0.10.in-addr.arpa. Con le due include inseriamo nella configurazione di bind le due chiavi che abbiamo creato prima. Nelle due zone dichiariamo che sono di tipo master e identifichiamo qual’è il loro file di zona contenuto in /dev/cache/bind. Con allow-update dichiariamo qual’è la chiave con cui autorizziamo gli aggiornamenti della zona master ( intranet-admin.key ), con allow-transfer quali sono gli indirizzi ip che possono richiedere il trasferimento di zona ( il o i server slave ) e con quale chiave di autenticazione ( intranet.key ). Infine con also-notify, diciamo a quali server comunicare che c’è stato un aggiornamento nella zona, in modo che i server slave si allineino con il master senza attendere la scadenza del time to live dichiarato nel record SOA
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 |
master:~# cat >> /etc/bind/zones.intranet <<! include "/etc/bind/intranet-admin.key"; include "/etc/bind/intranet.key"; zone "intranet." IN { type master; file "intranet.zone"; allow-update { key "intranet-admin.key"; }; allow-transfer { 10.0.0.2; key "intranet.key"; }; also-notify { 10.0.0.2; }; }; zone "0.0.10.in-addr.arpa." IN { type master; file "intranet.rev.zone"; allow-update { key "intranet-admin.key"; }; allow-transfer { 10.0.0.2; key "intranet.key"; }; also-notify { 10.0.0.2; }; }; ! |
Includiamo il file zones.internet appena creato nel config file di bind named.conf.local ( notare cat >> e non cat > )
|
1 2 3 |
master:~# cat >> /etc/bind/named.conf.local <<! include "/etc/bind/zones.intranet"; ! |
Infine i due file contenuti in /var/cache/bind con i resource record delle zone. Prima la definizione di intranet.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 |
master:/etc/bind# cat >> /var/cache/bind/intranet.zone <<! $ORIGIN . $TTL 3600 intranet IN SOA ns1.intranet. hostmaster.intranet. ( 2019021800 10800 10800 86400 3600 ) NS ns1.intranet. NS ns2.intranet. MX 0 . $ORIGIN intranet. ns1 IN A 10.0.0.1; Master dns ns2 IN A 10.0.0.2; Slave dns ! |
E poi la definizione di 0.0.10.in-addr.arpa
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 |
master:~# cat >> /var/cache/bind/intranet.rev.zone <<! $ORIGIN . $TTL 3600 0.0.10.in-addr.arpa IN SOA ns1.intranet. hostmaster.intranet. ( 2019021800 10800 10800 86400 3600 ) NS ns1.intranet. NS ns2.intranet. $ORIGIN 0.0.10.in-addr.arpa. 1 IN PTR ns1.intranet. 2 IN PTR ns2.intranet. ! |
Configurazione Slave
La dichiarazione delle due zone nel dns slave è molto simile. Abbiamo una include con cui inseriamo in bind la stessa chiave intranet.key presente sul master con cui autorizziamo i trasferimenti di zona. Il type qui sarà slave, dobbiamo dire chi è il dns master, quale indirizzo ip è autorizzato ad inviare i messaggi NOTIFY ( il master )
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 |
slave:~# cat >> /etc/bind/zones.intranet <<! include "/etc/bind/intranet.key"; zone "intranet." IN { type slave; file "/var/cache/bind/intranet.zone"; masters { 10.0.0.1; }; allow-notify { 10.0.0.1; key "intranet.key"; }; allow-transfer { none; }; }; zone "0.0.10.in-addr.arpa." IN { type slave; file "/var/cache/bind/intranet.rev.zone"; masters { 10.0.0.1; }; allow-notify { 10.0.0.1; key "intranet.key"; }; allow-transfer { none; }; }; ! |
Aggiungiamo il file zones.intranet nella configurazione di bind
|
1 2 3 |
slave:~# cat >> /etc/bind/named.conf.local <<! include "/etc/bind/zones.intranet"; ! |
Nel nodo slave non è necessario creare i file in /var/cache/bind perchè sarà bind stesso a crearli chiedendoli al master. I file che verranno creati non saranno nemmeno leggibili con un editor di testo come invece avviene con gli omologhi sul master
Avvio
|
1 2 3 |
master:~# systemctl restart bind9 slave:~# systemctl restart bind9 |
Verifica trasferimento di zona
Dopo il riavvio dei due servizi, possiamo già leggere nei log di sistema che le due zone sono state correttamente trasferite
Nello slave vediamo qualcosa del genere
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
slave:~# journalctl -f /usr/sbin/named zone intranet/IN: Transfer started. transfer of 'intranet/IN' from 10.0.0.1#53: connected using 10.0.0.2#60237 zone intranet/IN: transferred serial 2019021804 transfer of 'intranet/IN' from 10.0.0.1#53: Transfer status: success transfer of 'intranet/IN' from 10.0.0.1#53: Transfer completed: 1 messages, 7 records, 192 bytes, 0.011 secs (17454 bytes/sec) zone intranet/IN: sending notifies (serial 2019021804) zone 0.0.10.in-addr.arpa/IN: Transfer started. transfer of '0.0.10.in-addr.arpa/IN' from 10.0.0.1#53: connected using 10.0.0.2#48551 zone 0.0.10.in-addr.arpa/IN: transferred serial 2019021800 transfer of '0.0.10.in-addr.arpa/IN' from 10.0.0.1#53: Transfer status: success transfer of '0.0.10.in-addr.arpa/IN' from 10.0.0.1#53: Transfer completed: 1 messages, 6 records, 196 bytes, 0.009 secs (21777 bytes/sec) zone 0.0.10.in-addr.arpa/IN: sending notifies (serial 2019021800) |
E sul master
|
1 2 3 4 5 6 |
master:~# journalctl -f /usr/sbin/named client 10.0.0.2#60237 (intranet): transfer of 'intranet/IN': AXFR started (serial 2019021804) client 10.0.0.2#60237 (intranet): transfer of 'intranet/IN': AXFR ended client 10.0.0.2#48551 (0.0.10.in-addr.arpa): transfer of '0.0.10.in-addr.arpa/IN': AXFR started (serial 2019021800) client 10.0.0.2#48551 (0.0.10.in-addr.arpa): transfer of '0.0.10.in-addr.arpa/IN': AXFR ended |
Possiamo quindi interrogare i due dns con dig
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 |
host:~# dig +short @10.0.0.1 ns1.intranet 10.0.0.1 host:~# dig +short @10.0.0.1 -x 10.0.0.1 ns1.intranet. host:~# dig +short @10.0.0.1 ns2.intranet 10.0.0.2 host:~# dig +short @10.0.0.1 -x 10.0.0.2 ns2.intranet. host:~# dig +short @10.0.0.2 ns1.intranet 10.0.0.1 host:~# dig +short @10.0.0.2 -x 10.0.0.1 ns1.intranet. host:~# dig +short @10.0.0.2 ns2.intranet 10.0.0.2 host:~# dig +short @10.0.0.2 -x 10.0.0.2 ns2.intranet. |
Inserimento host tramite nsupdate
Abbiamo già creato la chiave tsig, quindi non dobbiamo fare altro che inserire in un file i comandi da far eseguire a nsupdate. Notare che poichè dobbiamo aggiornare due zone diverse ( intranet. e 0.0.10.in-addr.arpa ) non possiamo inviare i comandi tutti insieme altrimenti bind non farà niente, dobbiamo inviare prima i comandi relativi ad una zona e poi all’altra, questo spiega la presenza delle due send
|
1 2 3 4 5 6 |
master:~# cat > nsupdate.txt <<! update add host.intranet. 3600 A 10.0.0.3 send update add 3.0.0.10.in-addr.arpa. 3600 PTR host.intranet. send ! |
Inviamo le modifiche di zona
|
1 |
master:~# nsupdate -v -k /etc/bind/intranet-admin.key nsupdate.txt |
Come possiamo vedere dai log, il master ha aggiornato la zona, ha inviato la notifica allo slave il quale ha iniziato il trasferimento dal master
|
1 2 3 4 5 6 7 8 9 10 11 12 |
journalctl -f /usr/sbin/named client 10.0.0.1#45301/key intranet-admin.key: signer "intranet-admin.key" approved client 10.0.0.1#45301/key intranet-admin.key: updating zone 'intranet/IN': adding an RR at 'host.intranet' A 10.0.0.3 zone intranet/IN: sending notifies (serial 2019021805) client 10.0.0.1#50275/key intranet-admin.key: signer "intranet-admin.key" approved client 10.0.0.1#50275/key intranet-admin.key: updating zone '0.0.10.in-addr.arpa/IN': adding an RR at '3.0.0.10.in-addr.arpa' PTR host.intranet. client 10.0.0.2#40709 (intranet): transfer of 'intranet/IN': IXFR started (serial 2019021804 -> 2019021805) client 10.0.0.2#40709 (intranet): transfer of 'intranet/IN': IXFR ended zone 0.0.10.in-addr.arpa/IN: sending notifies (serial 2019021801) client 10.0.0.2#54697 (0.0.10.in-addr.arpa): transfer of '0.0.10.in-addr.arpa/IN': IXFR started (serial 2019021800 -> 2019021801) client 10.0.0.2#54697 (0.0.10.in-addr.arpa): transfer of '0.0.10.in-addr.arpa/IN': IXFR ended |
Interroghiamo i due dns
|
1 2 3 4 5 6 7 8 |
host:~# dig +short @10.0.0.1 host.intranet 10.0.0.3 host:~# dig +short @10.0.0.1 -x 10.0.0.3 host.intranet. host:~# dig +short @10.0.0.2 host.intranet 10.0.0.3 host:~# dig +short @10.0.0.2 -x 10.0.0.3 host.intranet. |
Come possiamo verificare, utilizzando solo una volta nsupdate abbiamo inserito host su entrambe le zone sia sul master che sullo slave ( ma gli slave potrebbero essere anche più di uno )