DNS & DHCP – DNS
Per gestire la risoluzione dei nomi all’interno della nostra azienda, realizzeremo 2 DNS server: il primo farà funzioni di DNS master (quello in cui manterremo aggiornata il file della nostra zona) ed il secondo con funzioni di slave (quello che passivamente accetta le zone inviate dal primario). Possono esistere più DNS master che DNS slave; chiaramente, in caso di multi-master quando modifico una configurazione devo modificarla in tutti i master; lo slave punterà ad uno qualunque dei master.
I server sono indipendenti l’uno dall’altro nel senso che vengono interrogati dai client in maniera totalmente indipendentre l’uno dall’altro ed entrambi forniscono la medesima risposta al client.
Il DNS primario è quello che contiene le zone (informazioni relative ad un dominio) e trasferisce tali informazioni in modo protetto allo slave ogni volta che la zona viene modificata o quando scade il tempo di vita (chiamato TTL) della zona.
Dopo aver effettuato un’installazione di base per la distribuzione Linux CentOS 7.0, procediamo all’installazione del servizio DNS; l’installazione è identica sia per il DNS primario che per il secondario.
# # Aggiorniamo il sistema # yum -y update # #Installiamo alcuni package che ci serviranno successivamente # yum -y install net-tools lsof ntp ntpdate autogen-libopts # # Stoppiamo e disabilitiamo il firewall # systemctl stop firewalld # systemctl disable firewalld # # Riavviamo il sistema # init 6
Dopo aver configurato il servizio NTP come indicato in questo post, procediamo all’installazione, all’abilitazione ed all’avvio del servizio DNS:
# yum -y install bind bind-libs bind-chroot bind-utils # systemctl enable named # systemctl start named
Creiamo una chiave che permetterà ai DNS server server01 e server02 di scambiarsi gli aggiornamenti delle zone in modo sicuro. Questo canale sicuro denominato TSIG (Transaction SIGnature) è un protocollo definito dall’RFC 2845 ed è principalmente usato dal DNS e dal DHCP per fornire aggiornamenti tramite autenticazione; può essere utilizzato anche per interrogazioni normali. TSIG utilizza chiavi private e hashing one-way per fornire cruittografia.
# cd /usr/src # dnssec-keygen -r /dev/urandom -a HMAC-MD5 -b 512 -n HOST server01.anthesia.lan.
Apriamo il file Kserver01.anthesia.lan.+157+48537.private (o simile, l’importante che finisca con .private) che è stato generato dal comando precedente e copiamo la riga che inizia con Key; dovrebbe essere simile alla seguente:
PFZe/cJphpgdkwdK/71Fufn44uK8H1+R7Dd_0rIBUG2AMU7K+rFK+Ejisc7NV88ctalaUWSVr6uzVNbegqUmeg==
Creiamo anche la chiave che permetterà al DHCP di fornire aggiornamenti sicuri al DNS:
# cd /usr/src # dnssec-keygen -r /dev/urandom -a HMAC-MD5 -b 512 -n HOST server01-server02
Analogamente per la chiave sever01-server02:
vMRWHTEuqhlhd7KOfgnu8iVN9xX7Dqfh/83HeDh4o620kzrqhe6OyEkHL/3F++jMDByKpWjVGzPG5a5o9K62Ng=
Creiamo il nuovo file /etc/named/anthesia.lan.key, fatto in questo modo:
key server01.anthesia.lan. {
algorithm hmac-md5;
secret "PFZe/cJphpgdkwdK/71Fufn44uK8H1+R7Dd_0rIBUG2AMU7K+rFK+Ejisc7NV88ctalaUWSVr6uzVNbegqUmeg==";
};
server 172.28.0.201 {
keys { server01.anthesia.lan; };
keys { server01-server02; };
};
key server01-server02 {
algorithm hmac-md5;
secret "vMRWHTEuqhlhd7KOfgnu8iVN9xX7Dqfh/83HeDh4o620kzrqhe6OyEkHL/3F++jMDByKpWjVGzPG5a5o9K62Ng=";
};
server 127.0.0.1 {
keys { server01-server02; };
};
server 172.28.0.201 {
keys { server01-server02; };
};
Una volta creato il file che contiene all’interno la chiave di interscambio, modifichiamo il file /etc/named.conf:
options {
listen-on port 53 { 127.0.0.1; 172.28.0.200; };
//listen-on-v6 port 53 { ::1; };
directory "/var/named";
dump-file "/var/named/data/cache_dump.db";
statistics-file "/var/named/data/named_stats.txt";
memstatistics-file "/var/named/data/named_mem_stats.txt";
allow-query { localhost; 172.28.0.0/22; };
recursion no;
dnssec-enable yes;
dnssec-validation yes;
dnssec-lookaside auto;
bindkeys-file "/etc/named.iscdlv.key";
managed-keys-directory "/var/named/dynamic";
pid-file "/run/named/named.pid";
session-keyfile "/run/named/session.key";
};
logging {
channel default_debug {
file "data/named.run";
severity dynamic;
};
};
zone "." IN {
type hint;
file "named.ca";
};
include "/etc/named.rfc1912.zones";
include "/etc/named.root.key";
include "/etc/named/anthesia.lan.key";
zone "anthesia.lan" {
type master;
file "anthesia.lan.db";
allow-query { any; };
also-notify {172.28.0.201; };
allow-transfer { 172.28.0.201 };
allow-update { key server01-server02};
};
Creiamo il file della zona anthesia.lan ( /var/named/anthesia.lan.db, come dichiarato nel file /etc/named.conf):
; $ORIGIN defines a base value from which 'unqualified' name ; (those without a terminating dot) substitutions are made when ; processing the zone file. Zone files which do not contain an ; $ORIGIN directive, while being perfectly legitimate, can also ; be highly confusing. ; In general, always explicitly define an $ORIGIN directive unless ; there is a very good reason not to. $ORIGIN anthesia.lan. ; TTL in the DNS context defines the duration in seconds that the record may be cached. ; Zero indicates the record should not be cached. Note: ; RFC 1912 cautions that 0 = no caching is not widely implemented so make no assumptions. $TTL 0 @ IN SOA server01.anthesia.lan. hostmaster.server01.anthesia.lan. ( 2014070701 ; serial 86400 ; refresh (1 day) 7200 ; retry (2 hours) 2592000 ; expire (4 weeks 2 days) 86400 ; minimum (1 day) ) NS server01.anthesia.lan. NS server02.anthesia.lan. A 172.28.0.200; ; define mail server for the zone anthesia.lan with priority 10 MX 10 mail-server.anthesia.lan. ; HOST Definition server01 A 172.28.0.200 server02 A 172.28.0.201 www CNAME server01 mail-server A 172.28.0.202
Cambiamo i diritti al nostro file della zona:
chown root.named /var/named/anthesia.lan.db chmod 640 /var/named/anthesia.lan.db
Controlliamo che sia la configurazione del nostro mail server che la configurazione della nostra zona siano corrette:
named-checkconf /etc/named.conf named-checkzone anthesia.lan /var/named/anthesia.lan.db
Il comando precedente ritorna solo gli errori, per cui in mancanza di output la nostra configurazione è corretta; in caso positivo possiamo riavviare il servizio:
systemctl restart named
Effettuiamo dei test per vedere se la nostra zona funziona correttamente:
# dig @localhost anthesia.lan ; <<>> DiG 9.9.4-RedHat-9.9.4-14.el7 <<>> @localhost anthesia.lan ; (2 servers found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<
Chiediamo al nostro DNS server qual è il mail server della zona anthesia.lan:
# dig @localhost anthesia.lan MX ; <<>> DiG 9.9.4-RedHat-9.9.4-14.el7 <<>> @localhost anthesia.lan MX ; (2 servers found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<
Dunque il nostro mail server primario funziona correttamente; configuriamo ora il DNS server secondario. Di seguito la modifica al file /etc/named.conf:
....listen-on port 53 { 127.0.0.1; 172.28.0.201; };listen-on port 53 { 127.0.0.1; 172.28.0.200; }; ... zone "anthesia.lan" {type master;type slave; masters { 172.28.0.200; }; allow-query { any; };file "anthesia.lan.db";file "slaves/anthesia.lan.db";allow-transfer { key server01.anthesia.lan.; }; also-notify {192.168.44.86; };}; ....
Modifichiamo anche il file /etc/named/anthesia.lan.key:
server 172.28.0.201 {server 172.28.0.200 { keys { server01.anthesia.lan; }; };
Facciamo partire il servizio nel nostro DNS server secondario e testiamo il trasferimento della zona tra i due server; modifichiamo il seriale della zona nel DNS master e ricarichiamo la zona:
2014070701 ; serial2014080401 ; serial systemctl restart named
Dai file di log del server DNS primario:
Aug 4 17:02:01 server01 named[19203]: client 172.28.0.201#47020: transfer of 'anthesia.lan/IN': AXFR-style IXFR started: TSIG server01.anthesia.lan Aug 4 17:02:01 server01 named[19203]: client 172.28.0.201#47020: transfer of 'anthesia.lan/IN': AXFR-style IXFR ended
Dai file di log del server DNS secondario:
Aug 4 17:02:01 server02 named[9510]: client 172.28.0.200#56461: received notify for zone 'anthesia.lan': TSIG 'server01.anthesia.lan' Aug 4 17:02:01 server02 named[9510]: zone anthesia.lan/IN: Transfer started. Aug 4 17:02:01 server02 named[9510]: transfer of 'anthesia.lan/IN' from 172.28.0.200#53: connected using 192.168.33.86#47020 Aug 4 17:02:01 server02 named[9510]: zone anthesia.lan/IN: transferred serial 2014080403: TSIG 'minou.anthesia.net' Aug 4 17:02:01 server02 named[9510]: transfer of 'anthesia.lan/IN' from 172.28.0.200#53: Transfer completed: 1 messages, 12 records, 731 bytes, 0.001 secs (731000 bytes/sec)
A questo punto la configurazione della nostra zone è terminata; non ci resta che popolare il file della zona (anthesia.lan.db) con gli altri server ed apparati che vogliamo risolvere tramite nome e non tramite indirizzo IP.
