Un server DNS e DHCP su Debian
 Versioni Compatibili Tutte le versioni supportate di Debian |
Introduzione
In una rete locale con un server Linux e client Windows "recenti" (quindi da Windows 2000 in poi), per far sì che le comunicazioni di rete avvengano in modo efficiente, è necessario avere un server DNS che sia in grado di risolvere i nomi host dei vari PC in rete. Linux risponde benissimo a quest'esigenza col pacchetto Bind, che è appunto il server DNS più utilizzato in ambiente Linux. Il problema però è che se abbiamo una rete abbastanza estesa e con cambi frequenti, dovremmo aggiornare a mano i record A e PTR del server DNS, cosa alquanto scomoda per ovvi motivi, senza considerare che un inserimento manuale si presta benissimo ad errori di digitazione.
Per ovviare a questo problema, è bene far lavorare Bind in stretto contatto con un server DHCP (dhcp3 su Debian Etch/Lenny, isc-dhcp su Debian Squeeze), il quale assegnerà dinamicamente la configurazione IP ai vari host, e contestualmente aggiornerà dinamicamente i record DNS su Bind, in modo che l'intervento manuale dell'amministratore di sistema sia ridotto al minimo. Il server DNS sarà utilizzato anche per risolvere i nomi di dominio Internet, impostando uno o più forwarders da interrogare se un dominio non è stato definito sul server DNS locale.
Installazione e configurazione del server DNS
Il primo passo per organizzare questa architettura di rete è quello di installare Bind9 sul server Linux e le relative utilità, col comando:
# apt-get install bind9 dnsutils
A questo punto va configurato Bind in modo che possa risolvere i nomi host per il dominio che andremo a creare. Il primo passo, consiste nel dire al server Linux che la risoluzione dei nomi dev'essere delegata a se stesso, editando opportunamente il file /etc/resolv.conf. Successivamente, bisogna modificare il file /etc/bind/named.conf, che è il file principale di configurazione di Bind, il quale indica dove sono posizionati i file in cui sono definite le zone corrispondenti ai vari domini che si vogliono configurare.
Una configurazione alternativa (suggerita dagli stessi commenti presenti nel file /etc/bind/named.conf) è di inserire le nostre zone "locali" in un file apposito, chiamato /etc/bind/named.conf.local. Questa seconda strada è quella che seguiremo in questa guida.
Ipotizziamo quindi di avere un dominio test.lan sulla rete 192.168.1.0: dovremo configurare due file di zona, uno chiamato /etc/bind/db.test ed uno chiamato /etc/bind/db.192.168.1, che rappresenta il file in cui inserire i record PTR (quelli di ricerca inversa). Di seguito vediamo come impostare il file /etc/resolv.conf, dopodiché vedremo il contenuto del file di configurazione generico di Bind9 /etc/bind/named.conf, ed infine esamineremo i file di zona /etc/bind/db.test e /etc/bind/db.192.168.1, che rappresentano la zona che descrive la nostra rete LAN:
/etc/resolv.conf:
search test.lan nameserver 127.0.0.1
/etc/bind/named.conf:
Le seguenti modifiche sono necessarie solo in Lenny (o precedenti). Da Squeeze questi parametri sono gia´ inclusi di default tramite un richiamo al file named.conf.default-zones.
include "/etc/bind/named.conf.options";
// prime the server with knowledge of the root servers
zone "." {
type hint;
file "/etc/bind/db.root";
};
zone "localhost" {
type master;
file "/etc/bind/db.local";
};
zone "127.in-addr.arpa" {
type master;
file "/etc/bind/db.127";
};
zone "0.in-addr.arpa" {
type master;
file "/etc/bind/db.0";
};
zone "255.in-addr.arpa" {
type master;
file "/etc/bind/db.255";
};
include "/etc/bind/named.conf.local"
/etc/bind/named.conf.local:
zone "test.lan" {
type master;
file "/etc/bind/db.test";
};
zone "1.168.192.in-addr.arpa" {
type master;
file "/etc/bind/db.192.168.1";
};
/etc/bind/db.test:
Descrive la zona della nostra rete LAN. Non è presente nella directory /etc/bind, ma va creato con un editor di testo.
$TTL 86400 ; 1 day
test.lan. IN SOA ns1.test.lan. hostmaster.test.lan. (
2007081501 ; serial
86400 ; refresh (1 giorno)
28800 ; retry (8 ore)
604800 ; expire (1 settimana)
86400 ; minimum (1 giorno)
);
IN NS ns1.test.lan.
;NOTA: ns1 è il nome del server che funge da DNS server
ns1 IN A 192.168.1.1
; Qui potete inserire gli IP dei client-server che hanno un IP statico
client IN A 192.168.1.3
La prima linea del file specifica il TTL (Time To Live) di questa zona e indica quanto tempo deve trascorrere prima che Bind controlli i file locali per verificare eventuali cambiamenti. Il valore di default è espresso in secondi.
Le linee successive indicano il SOA (Start Of Authority); il formato di questi record è il seguente:
<domain name>. IN SOA <primary nameserver>. <email address of admin>. (
<serial number>
<time to refresh>
<time to retry>
<time to expire>
<negative caching ttl>
)
dove
- domain name - indica il nome del dominio, seguito da un punto
- IN e SOA indicano che il server è un SOA e un DNS per internet
- primary nameserver - è il nome di dominio del server che stiamo installando
- email address of admin - l'email dell'amministratore del server
- serial number - è il valore utilizzato dai server DNS slave per determinare se sono occorsi cambiamenti dall'ultima volta che hanno contattato il master DNS. Aumenta automaticamente ad ogni cambiamento
- refresh - è l'intervallo di tempo che deve trascorrere prima che un server slave ricontatti il proprio master
- retry - è il numero di tentativi di connessione che un server slave deve effettuare prima di chiudere il tentativo di aggiornamento
- expire - indica quanto tempo lo slave server deve continuare a fornire dati dopo che si è verificato un errore negli aggiornamenti da un master server
- negative caching ttl - è il periodo di tempo in cui uno slave server fornisce risposte negative alle interrogazioni
Seguono poi le linee che indicano i Server DNS della rete, nel formato:
<domain name>. IN NS <nameserver1>.
<domain name>. IN NS <nameserver2>.
- NS significa Name Server. Possono essere specificati sia con un FQDN sia con un indirizzo IP. Nel nostro caso il Name Server si chiama
ns1e pertanto la linea diventa:
IN NS ns1.test.lan.
Infine vengono specificati gli indirizzi delle macchine locali che posseggono un indirizzo IP statico, con la seguente sintassi:
<full domain name>. IN A <IP address>
/etc/bind/db.192.168.1:
Descrive la zona della nostra rete LAN. Non è presente nella directory /etc/bind, ma va creato con un editor di testo.
;
; BIND reverse data file for local loopback interface
;
$TTL 604800
@ IN SOA test.lan. hostmaster.test.lan. (
2007081501 ; serial
604800 ; refresh
86400 ; retry
2419200 ; expire
604800 ; negative cache ttl
);
@ IN NS ns1.test.lan.
1 IN PTR ns1.test.lan.
3 IN PTR client.test.lan.
Il file segue la stessa sintassi vista analizzando il file db precedente.
/etc/bind/db.0, db.127, db.255, db.empty, db.local
Questi file descrivono le zone locali predefinite in bind e non andrebbero toccati.
Riavvio del server
Fatta la configurazione, bisogna riavviare il demone bind9:
# /etc/init.d/bind9 restart
Risoluzione di indirizzi internet
Ora il server DNS può risolvere i nomi host per il dominio test.lan presente sulla rete LAN, a condizione che gli IP indicati nel file di configurazione non cambino (da tenere presente che i valori indicati sono puramente indicativi); ciò implica che la nostra rete deve essere configurata con indirizzi IP statici, condizione accettabile se i PC non superano le 10 unità, altrimenti si deve considerare l'utilizzo di un server DHCP. Altra cosa da considerare, è che in questa situazione, Bind non riesce a risolvere i nomi di dominio Internet; per ovviare al problema, bisogna indicare a Bind uno o più server DNS pubblici che possano soddisfare le richieste che il server Linux fa per conto dei client, editando opportunamente il file /etc/bind/named.conf.options aggiungendo queste righe:
allow-query { 127.0.0.1; 192.168.1/24; } ;
allow-transfer { none; } ;
allow-recursion { 127.0.0.1; 192.168.1/24; } ;
forwarders {
208.67.222.222;
208.67.220.220;
};
all'interno della sezione principale del file:
options {
directory "/var/cache/bind";
...
...
...
auth-nxdomain no; # conform to RFC1035
listen-on-v6 { any; };
};
In questo modo i client potranno tranquillamente risolvere sia i nomi host in LAN sia i nomi di dominio Internet.
Per aumentare il livello di protezione sono state aggiunte anche le direttive allow, permettendo le interrogazioni DNS solo dall'interno della lan e impedendo i trasferimenti di zona.
Installazione e configurazione del server DHCP
A questo punto prendiamo in considerazione l'ipotesi di necessitare dello stesso tipo di configurazione, ma per una rete locale di 20 (o più) host: in questo contesto, non è saggio mantenere un indirizzamento di rete con IP fissi. È sicuramente più indicato utilizzare un indirizzamento dinamico, servizio fornito da un server DHCP. Nella situazione indicata in precedenza però, i file di zona del dominio test.lan dovranno essere editati ogniqualvolta cambia l'assegnazione dell'indirizzo IP ad un host, per cui va a farsi benedire la comodità dell'utilizzo di un server DHCP; è evidente quindi che la situazione ideale consiste nell'assegnazione di indirizzi IP dinamici agli host e nel contestuale aggiornamento dinamico della corrispondenza indirizzo IP -> nome host. Per fortuna, in Linux ciò è possibile, poiché sarà il server DHCP, opportunamente configurato, ad effettuare gli aggiornamenti dinamici sul server DNS, il quale dev'essere configurato per accettare gli aggiornamenti inviati dal server DHCP. Il primo passaggio della messa in opera della configurazione appena esaminata consiste nell'installazione ed attivazione del server DHCP, senza per il momento prendere in esame l'aggiornamento dinamico del server DNS; per installare il pacchetto dhcp3, utilizzare il solito apt:
- Debian Etch/Lenny
# apt-get install dhcp3-common dhcp3-server
- Debian Squeeze
# apt-get install isc-dhcp-common isc-dhcp-server
quindi, fare una copia di salvataggio del file di configurazione di esempio, crearne uno nuovo vuoto ed editarlo:
- Debian Etch/Lenny
# mv /etc/dhcp3/dhcpd.conf /etc/dhcp3/dhcpd.old # touch /etc/dhcpd3/dhcpd.conf # nano /etc/dhcp3/dhcpd.conf
- Debian Squeeze
# mv /etc/dhcp/dhcpd.conf /etc/dhcp/dhcpd.old # touch /etc/dhcp/dhcpd.conf # nano /etc/dhcp/dhcpd.conf
Ora, aggiungere un ambito DHCP con le opzioni del caso che ci permetta di distribuire i parametri della configurazione TCP/IP ai client della LAN, operazioni che si traducono nel seguente contenuto del file dhcpd.conf:
authoritative;
server-identifier 192.168.1.1;
ignore client-updates;
subnet 192.168.1.0 netmask 255.255.255.0
{
range 192.168.1.100 192.168.1.150;
range 192.168.1.200 192.168.1.250;
option subnet-mask 255.255.255.0;
default-lease-time 604800;
max-lease-time 2592000;
option broadcast-address 192.168.1.255;
option routers 192.168.1.254;
option domain-name-servers 192.168.1.1;
option domain-name "test.lan";
option netbios-name-servers 192.168.1.1;
option netbios-node-type 8;
}
# Assegnare un IP fisso ad un particolare client
host pc_fisso {
hardware ethernet 00:0D:87:B3:AE:A6;
fixed-address 192.168.1.150;
}
A questo punto, far partire (o ripartire) il demone dhcp3-server per attivare la configurazione:
- Debian Etch/Lenny
# /etc/init.d/dhcp3-server start
- Debian Squeeze
# /etc/init.d/isc-dhcp-server start
Configurazione del DNS Dinamico
Giunti fin qui, rimangono da configurare gli aggiornamenti dinamici del server DNS. In questo caso, come già esposto, sarà il server DHCP ad aggiornare dinamicamente il server DNS, al quale dovremo dire che sono consentiti gli aggiornamenti dinamici solamente da parte degli host coinvolti nel processo. In questo caso, ipotizzando che DNS e DHCP siano sulla stessa macchina, abiliteremo solamente localhost all'aggiornamento dinamico del server DNS, e come ulteriore misura di sicurezza, specificheremo che l'aggiornamento delle zone coinvolte avverrà solamente utilizzando una chiave segreta che viene creata automaticamente all'installazione di Bind ed il cui nome file è /etc/bind/rndc.key. Il primo passaggio consiste nel modificare il file /etc/bind/named.conf.local per indicare che il server DNS accetta aggiornamenti dinamici solamente da localhost utilizzando la chiave segreta:
include "/etc/bind/rndc.key";
controls {
inet 127.0.0.1 allow {localhost; } keys { "rndc-key"; };
};
Un'ulteriore modifica da fare al file /etc/bind/named.conf.local è relativa alle zone create in precedenza, poiché anche in esse è necessario indicare che è possibile l'aggiornamento solamente tramite l'utilizzo della chiave segreta:
zone "test.lan" {
type master;
file "/etc/bind/db.test";
allow-update { key rndc-key; };
};
zone "1.168.192.in-addr.arpa" {
type master;
file "/etc/bind/db.192.168.1";
allow-update { key rndc-key; };
};
Fatto questo, far ripartire il demone bind9. Ora, rimane da configurare il server DHCP, il quale sarà incaricato di effettuare gli aggiornamenti sul server DNS, e che quindi dovrà obbligatoriamente "autenticarsi" su Bind utilizzando la chiave segreta /etc/bind/rndc.key. Ciò si traduce nell'aggiunta delle seguenti opzioni nel file di configurazione /etc/dhcp3/dhcpd.conf (/etc/dhcp/dhcpd.conf da Squeeze):
ddns-updates on;
update-static-leases on; # i client con ip statico sono compresi negli aggiornamenti
ddns-update-style interim;
ddns-domainname "test.lan.";
ddns-rev-domainname "in-addr.arpa.";
include "/etc/bind/rndc.key";
zone test.lan. {
primary 192.168.1.1;
key rndc-key;
}
zone 1.168.192.in-addr.arpa. {
primary 192.168.1.1;
key rndc-key;
}
L'ultimo passaggio consiste nel rendere la directory /etc/bind scrivibile anche per l'utente bind, in modo tale che Bind possa creare i file di zona con estensione .jnl che contengono i record DNS generati dinamicamente tramite l'aggiornamento di Bind da parte del server DHCP:
# chmod 775 /etc/bind
Ora, un riavvio del demone dhcp3-server (isc-dhcp-server da Squeeze) completerà l'opera, ed avremo una rete con i PC che prendono la configurazione IP da un server DHCP, il quale aggiorna dinamicamente il server DNS in modo tale che tutte le operazioni di risoluzione dei nomi host avvengano correttamente sull'intera rete locale. Il vantaggio di questa soluzione è l'elevata automatizzazione dei processi descritti, che comporta un intervento dell'amministratore di sistema che si limita alla configurazione iniziale ed alla normale manutenzione del server, senza dover svolgere noiosi, inutili e ripetitivi aggiornamenti manuali.
Troubleshooting Bind
Bind non riparte dopo un riavvio
Utilizzando il comando rndc reload qualche volta Bind può rifiutarsi di partire:
metaserver:/etc/bind# rndc reload rndc: connection to remote host closed
Questo può indicare che
- il server sta usando una vecchia versione del protocollo
- l'host da cui tentiamo di connetterci non è autorizzato alla connessione a Bind
- i clock non sono sincronizzati
- la chiave non è valida
Errori in /var/log/syslog
Una volta che Bind è ripartito, con il comando /etc/init.d/bind9 restart il passo successivo è controllare il file /var/log/syslog in cerca di eventuali errori. Qui sotto proverò ad elencare i più comuni. Ricordatevi di riavviare Bind ogni volta che correggete un errore.
Missing Period in a Zone File
Questo errore indica che ci siamo dimenticati di inserire un punto . alla fine della dichiarazione del FQDN all'interno dei files:
/etc/bind/db.test/etc/bind/db.192.168.1
Filename Typo
I nomi dei files delle zone creati in /etc/bind non corrispondono a quelli specificati nel file /etc/bind/named.conf.local. Dovreste trovare anche un errore come il seguente:
Jul 3 19:22:42 eyrie named[2847]: zone 1.168.192.in-addr.arp/IN: loading from master file /etc/bind/db.1.169.192 failed: file not found
Ignoring out-of-zone-data and 0 SOA/NS Records for Reverse DNS?
Questo è un po' criptico:
Jul 3 19:49:28 eyrie named[3028]: /etc/bind/db.1.168.192:3: ignoring out-of-zone data (raptor.loc) Jul 3 19:49:28 eyrie named[3028]: /etc/bind/db.1.168.192:12: ignoring out-of-zone data (raptor.loc) Jul 3 19:49:28 eyrie named[3028]: zone 1.168.192.in-addr.arp/IN: has 0 SOA records Jul 3 19:49:28 eyrie named[3028]: zone 1.168.192.in-addr.arp/IN: has no NS records
Probabilmente uno dei files di zona non contiene le corrette dichiarazioni SOA.
Turning Logging On/Off
Quando siamo alla ricerca di errori, può essere comodo abilitare temporaneamente il log di tutte le operazioni DNS sul file /var/log/syslog usando il comando:
rndc querylog
Questo porterà alla registrazione di numerose linee come le seguenti:
Jul 3 21:25:40 eyrie named[3189]: client 192.168.1.200#32793: query: eyrie.raptor.loc IN A + Jul 3 21:25:41 eyrie named[3189]: client 192.168.1.200#32793: query: gyrfalcon.raptor.loc IN A +
Per disabilitare il log occorre ridare il comando precedente.
Test di funzionamento
Una volta eliminati gli errori dai log possiamo testare il corretto funzionamento del server DNS, con il comando:
host
Qui di seguito sono elencati alcuni problemi comuni:
- Record non found
eyrie:~# host eyrie eyrie A record not found, server failure
Il client non sta usando il corretto server DNS. Occorre modificare il file /etc/resolv.conf oppure agire sulla configurazione di Network Manager.
- Host does not exist
eyrie:~# host eyrie eyrie does not exist, try again
Problema simile al precedente, per risolvere il quale occorre specificare il dominio di ricerca all'interno del file /etc/resolv.conf.
- Record query refused
eyrie:~# host eyrie eyrie.raptor.loc A record query refused
Dopo aver ottenuto questo errore comparirà una linea in /var/log/syslog sul server DNS:
eyrie:~# tail /var/log/daemon.log Jul 3 21:02:22 eyrie named[3095]: client X.X.X.X#32790: query 'eyrie.raptor.loc/A/IN' denied
Questo indica un problema con la direttiva allow-query { } in /etc/bind/named.conf.options.
- Does not exist (Authoritative answer)
gyrfalcon:~# host eyrie eyrie.raptor.loc does not exist (Authoritative answer)
Di solito questo indica un problema con il Forward DNS, oppure che è stato dimenticato un punto finale in uno di questi files:
/etc/bind/db.test/etc/bind/db.192.168.1