Tempo fa abbiamo visto come creare un DNS Primario. Vediamo ora come integrare la scorsa guida con questa in maniera tale da avere la classica coppia di DNS Master e Slave.
Aggiorniamo la tabella
Server Indirizzo IP Servizio FQDN
Server A 172.16.1.1 Mail mail.esempio.tst
Server B 172.16.1.2 Web, FTP www.esempio.tst ftp.esempio.tst
Server C 172.16.1.3 DNS Primario ns1.esempio.tst
Server D 172.16.1.4 DNS Secondario ns2.esempio.tst
Per quanto riguarda la configurazione iniziale del nostro sistema, possiamo seguire l’altra guida.
Il file di configurazione named.conf diventerà
options {
## path al file di zona ##
directory “/var/named”;
## elimina la possibilità di fare query ricorsive ##
recursion no;
};
## dichiarazione della zona per esempio.tst ##
zone “esempio.tst” IN {
type slave;
file “esempio-fz”;
masters { 172.16.1.3; };
allow-notify { 172.16.1.3; };
};
## dichiarazione della zona di reverse per la rete 172.16.1.0 ##
zone “1.16.172.in-addr.arpa” IN {
type slave;
file “rz-172-16-1”;
masters { 172.16.1.3; };
allow-notify { 172.16.1.3; };
};
In questa maniera abbiamo dichiarato le due zone impostandole come “SLAVE” e annunciando l’ip del relativo dns master che si occuperà di inviare le eventuali modifiche allo slave.
Ora però dobbiamo andare ad effettuare una piccola modifica sul “MASTER” per comunicargli l’indirizzo dello slave, al momento per lui ancora ignoto.
Andiamo quindi in ssh sul dns primario, e modifichiamo le due zone del master
zone “esempio.tst” IN {
type master;
file “esempio-fz”;
allow-update { none; };
notify yes;
also-notify { 172.16.1.4; };
};
zone “1.16.172.in-addr.arpa” IN {
type master;
file “rz-172-16-1”;
allow-update { none; };
notify yes;
also-notify { 172.16.1.4; };
};
Per potere fare in modo che il master invii il file di zona in maniera automatica allo slave, dobbiamo abiliare un’opzione direttamente nel processo named.
Andiamo ad editare il file /etc/sysconfig/named dello slave ed aggiungiamo la riga
ENABLE_ZONE_WRITE=yes
Ora avviamo il servizio sullo slave e rimaniamo in tail sui log di sistema
# /etc/init.d/named start
Starting named: [ OK ]
# tail -f /var/log/messages
Riavviamo named sul dns master
# /etc/init.d/named restart
Stopping named: . [ OK ]
Starting named: [ OK ]
All’interno della directory /var/named/ (o /var/named/chroot/ a seconda del tipo di installazione di BIND effettuata) dovremmo avere i file di zona correttamente importati.
Verificato ciò, proviamo ad effettuare una modifica sui file. Dobbiamo infatti comunicare al dns l’ip dello slave ed assegnargli un altro record NS.
Editiamo il file esempio-fz e facciamolo diventare
$TTL 1D
@ IN SOA ns1.esempio.tst. lantuin.esempio.tst. (
0 ; serial
1D ; refresh
1H ; retry
1W ; expire
3H ) ; minimum
IN NS ns1.esempio.tst.
IN NS ns2.esempio.tst.
IN A 172.16.1.3
mail IN A 172.16.1.1
IN MX 10 mail.esempio.tst.
www IN A 172.16.1.2
ns1 IN A 172.16.1.3
ns2 IN A 172.16.1.4
ftp IN CNAME www.esempio.tst.
Prima di salvare dobbiamo aggiornare il seriale. E’ buona norma utilizzare una convenzione del genere, in maniera tale da tenere traccia del giorno in cui è stata effettuata l’ultima modifica: YYYYMMDDNN dove NN è il numero di volte che il file di zona è stato modificato in quello specifico giorno. Assumendo che oggi è il 12/06/2014 andiamo a modificare il seriale in
2014061201 ; serial
Riavviamo BIND sul master.
Editiamo anche il file con la zona di reverse (file rz-172-16-1)
$TTL 1D
@ IN SOA ns1.esempio.tst. lantuin.esempio.tst. (
2014061201 ; serial
1D ; refresh
1H ; retry
1W ; expire
3H ) ; minimum
IN NS ns1.esempio.tst.
IN NS ns2.esempio.tst.
1 IN PTR mail.esempio.tst.
2 IN PTR www.esempio.tst.
3 IN PTR ns1.esempio.tst.
4 IN PTR ns2.esempio.tst.
Possiamo ora verificare che anche lo slave si sia preso la modifica appena effettuata. Per fare ciò, basta effettuare un cat sul nome del file di zona dello slave oppure eseguire un nslookup impostandosi come dns il 172.16.1.4
