1 508
contributi
Un server DNS e DHCP su Debian: differenze tra le versioni
corretta gerarchia titoli, revisionata
(corretta gerarchia titoli, revisionata) |
|||
| Riga 1: | Riga 1: | ||
{{Versioni compatibili|Debian Etch 4.0<br/>Debian Lenny 5.0<br/>Debian Squeeze<br/>Debian Sid|}} | {{Versioni compatibili|Debian Etch 4.0<br/>Debian Lenny 5.0<br/>Debian Squeeze<br/>Debian Sid|}} | ||
=Introduzione= | == Introduzione == | ||
In una rete locale con un server Linux e | 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.<br/> | ||
Per ovviare a questo problema, è bene far lavorare Bind in stretto contatto con un server DHCP (dhcp3 su Linux), 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. | Per ovviare a questo problema, è bene far lavorare Bind in stretto contatto con un server DHCP (dhcp3 su Linux), 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= | == Installazione e configurazione del server DNS == | ||
Il primo passo per organizzare questa architettura di rete è quello di installare Bind9 sul server Linux (la solita Debian Etch) e le relative utilità, col comando: | Il primo passo per organizzare questa architettura di rete è quello di installare Bind9 sul server Linux (la solita Debian Etch) e le relative utilità, col comando: | ||
<pre> | <pre> | ||
# apt-get install bind9 dnsutils | # apt-get install bind9 dnsutils | ||
</pre> | </pre> | ||
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 < | 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 <code>/etc/resolv.conf</code>. Successivamente, bisogna modificare il file <code>/etc/bind/named.conf</code>, 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.<br/>Una configurazione alternativa (suggerita dagli stessi commenti presenti nel file <code>/etc/bind/named.conf</code>) è di inserire le nostre zone "locali" in un file apposito, chiamato <code>/etc/bind/named.conf.local</code>. Questa seconda strada è quella che seguiremo in questa guida.<br/> | ||
Ipotizziamo quindi di avere un dominio test.lan sulla rete 192.168.1.0: dovremo configurare due file di zona, uno chiamato < | Ipotizziamo quindi di avere un dominio test.lan sulla rete 192.168.1.0: dovremo configurare due file di zona, uno chiamato <code>/etc/bind/db.test</code> ed uno chiamato <code>/etc/bind/db.192.168.1</code>, che rappresenta il file in cui inserire i record PTR (quelli di ricerca inversa). Di seguito vediamo come impostare il file <code>/etc/resolv.conf</code>, dopodiché vedremo il contenuto del file di configurazione generico di Bind9 <code>/etc/bind/named.conf</code>, ed infine esamineremo i file di zona <code>/etc/bind/db.test</code> e <code>/etc/bind/db.192.168.1</code>, che rappresentano la zona che descrive la nostra rete LAN:<br/> | ||
==/etc/resolv.conf:== | === /etc/resolv.conf: === | ||
<pre> | <pre> | ||
search test.lan | search test.lan | ||
nameserver 127.0.0.1 | nameserver 127.0.0.1 | ||
</pre> | </pre> | ||
==/etc/bind/named.conf:== | === /etc/bind/named.conf: === | ||
<pre> | <pre> | ||
include "/etc/bind/named.conf.options"; | include "/etc/bind/named.conf.options"; | ||
| Riga 41: | Riga 41: | ||
</pre> | </pre> | ||
==/etc/bind/named.conf.local:== | === /etc/bind/named.conf.local: === | ||
<pre> | <pre> | ||
zone "test.lan" { | zone "test.lan" { | ||
| Riga 52: | Riga 52: | ||
}; | }; | ||
</pre> | </pre> | ||
==/etc/bind/db.test:== | === /etc/bind/db.test: === | ||
Descrive la zona della nostra rete LAN. Non è presente nella directory <code>/etc/bind</code>, ma va creato con un editor di testo. | Descrive la zona della nostra rete LAN. Non è presente nella directory <code>/etc/bind</code>, ma va creato con un editor di testo. | ||
<pre> | <pre> | ||
| Riga 96: | Riga 96: | ||
<domain name>. IN NS <nameserver2>. | <domain name>. IN NS <nameserver2>. | ||
</pre> | </pre> | ||
* '''NS''' significa '''N'''ame '''S'''erver. Possono essere specificati sia con un FQDN sia con un indirizzo IP. Nel nostro caso il Name Server si chiama < | * '''NS''' significa '''N'''ame '''S'''erver. Possono essere specificati sia con un FQDN sia con un indirizzo IP. Nel nostro caso il Name Server si chiama <code>ns1</code> e pertanto la linea diventa: | ||
<pre> | <pre> | ||
IN NS ns1.test.lan. | IN NS ns1.test.lan. | ||
| Riga 105: | Riga 105: | ||
</pre> | </pre> | ||
==/etc/bind/db.192.168.1:== | === /etc/bind/db.192.168.1: === | ||
Descrive la zona della nostra rete LAN. Non è presente nella directory <code>/etc/bind</code>, ma va creato con un editor di testo. | Descrive la zona della nostra rete LAN. Non è presente nella directory <code>/etc/bind</code>, ma va creato con un editor di testo. | ||
<pre> | <pre> | ||
| Riga 125: | Riga 125: | ||
Il file segue la stessa sintassi vista analizzando il file db precedente. | Il file segue la stessa sintassi vista analizzando il file db precedente. | ||
==/etc/bind/db.0, db.127, db.255, db.empty, db.local== | === /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. | Questi file descrivono le zone locali predefinite in bind e non andrebbero toccati. | ||
==Riavvio del server== | === Riavvio del server === | ||
Fatta la configurazione, bisogna riavviare il demone bind9: | Fatta la configurazione, bisogna riavviare il demone bind9: | ||
<pre> | <pre> | ||
# /etc/init.d/bind9 restart | # /etc/init.d/bind9 restart | ||
</pre> | </pre> | ||
==Risoluzione di indirizzi internet== | === 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 < | 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 <code>/etc/bind/named.conf.options</code> aggiungendo queste righe: | ||
<pre> | <pre> | ||
allow-query { 127.0.0.1; 192.168.1/24; } ; | allow-query { 127.0.0.1; 192.168.1/24; } ; | ||
| Riga 146: | Riga 146: | ||
</pre> | </pre> | ||
In questo modo i client potranno tranquillamente risolvere sia i nomi host in LAN sia i nomi di dominio Internet.<br/> | In questo modo i client potranno tranquillamente risolvere sia i nomi host in LAN sia i nomi di dominio Internet.<br/> | ||
Per aumentare il livello di protezione sono state aggiunte anche le direttive < | Per aumentare il livello di protezione sono state aggiunte anche le direttive <code>allow</code>, pemettendo le interrogazioni DNS solo dall'interno della lan e impedendo i trasferimenti di zona. | ||
=Installazione e configurazione del server DHCP= | == 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. E' 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. | 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. E' 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: | 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: | ||
| Riga 191: | Riga 191: | ||
</pre> | </pre> | ||
=Configurazione del DNS Dinamico= | == 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 < | 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 <code>/etc/bind/named.conf.local</code> per indicare che il server DNS accetta aggiornamenti dinamici solamente da localhost utilizzando la chiave segreta: | ||
<pre> | <pre> | ||
include "/etc/bind/rndc.key"; | include "/etc/bind/rndc.key"; | ||
| Riga 199: | Riga 199: | ||
}; | }; | ||
</pre> | </pre> | ||
Un’ulteriore modifica da fare al file < | Un’ulteriore modifica da fare al file <code>/etc/bind/named.conf.local</code> è relativa alle zone create in precedenza, poiché anche in esse è necessario indicare che è possibile l’aggiornamento solamente tramite l’utilizzo della chiave segreta: | ||
<pre> | <pre> | ||
zone "test.lan" { | zone "test.lan" { | ||
| Riga 212: | Riga 212: | ||
}; | }; | ||
</pre> | </pre> | ||
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 < | 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 <code>/etc/bind/rndc.key</code>. Ciò si traduce nell’aggiunta delle seguenti opzioni nel file di configurazione /etc/dhcp3/dhcpd.conf: | ||
<pre> | <pre> | ||
ddns-updates on; | ddns-updates on; | ||
| Riga 235: | Riga 235: | ||
Ora, un riavvio del demone dhcp3-server 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. | Ora, un riavvio del demone dhcp3-server 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= | == Troubleshooting Bind == | ||
==Bind non riparte dopo un riavvio== | === Bind non riparte dopo un riavvio === | ||
Utilizzando il comando < | Utilizzando il comando <code>rndc reload</code> qualche volta Bind può rifiutarsi di partire: | ||
<pre> | <pre> | ||
metaserver:/etc/bind# rndc reload | metaserver:/etc/bind# rndc reload | ||
| Riga 247: | Riga 247: | ||
* i clock non sono sincronizzati | * i clock non sono sincronizzati | ||
* la chiave non è valida | * la chiave non è valida | ||
==Errori in /var/log/syslog== | === Errori in /var/log/syslog === | ||
Una volta che Bind è ripartito, con il comando < | Una volta che Bind è ripartito, con il comando <code>/etc/init.d/bind9 restart</code> il passo successivo è controllare il file <code>/var/log/syslog</code> 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=== | ==== Missing Period in a Zone File ==== | ||
Questo errore indica che ci siamo dimenticati di inserire un punto < | Questo errore indica che ci siamo dimenticati di inserire un punto <code>.</code> alla fine della dichiarazione del FQDN all'interno dei files: | ||
* < | * <code>/etc/bind/db.test</code> | ||
* < | * <code>/etc/bind/db.192.168.1</code> | ||
===Filename Typo=== | ==== Filename Typo ==== | ||
I nomi dei files delle zone creati in < | I nomi dei files delle zone creati in <code>/etc/bind</code> non corrispondono a quelli specificati nel file <code>/etc/bind/named.conf.local</code>. Dovreste trovare anche un errore come il seguente: | ||
<pre> | <pre> | ||
Jul 3 19:22:42 eyrie named[2847]: zone 1.168.192.in-addr.arp/IN: loading from master file | 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 | /etc/bind/db.1.169.192 failed: file not found | ||
</pre> | </pre> | ||
===Ignoring out-of-zone-data and 0 SOA/NS Records for Reverse DNS?=== | ==== Ignoring out-of-zone-data and 0 SOA/NS Records for Reverse DNS? ==== | ||
Questo è un po' criptico: | Questo è un po' criptico: | ||
<pre> | <pre> | ||
| Riga 269: | Riga 269: | ||
Probabilmente uno dei files di zona non contiene le corrette dichiarazioni SOA. | Probabilmente uno dei files di zona non contiene le corrette dichiarazioni SOA. | ||
===Turning Logging On/Off=== | ==== Turning Logging On/Off ==== | ||
Quando siamo alla ricerca di errori, può essere comodo abilitare temporaneamente il log di tutte le operazioni DNS sul file < | Quando siamo alla ricerca di errori, può essere comodo abilitare temporaneamente il log di tutte le operazioni DNS sul file <code>/var/log/syslog</code> usando il comando: | ||
<pre> | <pre> | ||
rndc querylog | rndc querylog | ||
| Riga 280: | Riga 280: | ||
</pre> | </pre> | ||
Per disabilitare il log occorre ridare il comando precedente. | Per disabilitare il log occorre ridare il comando precedente. | ||
===Test di funzionamento=== | ==== Test di funzionamento ==== | ||
Una volta eliminati gli errori dai log possiamo testare il corretto funzionamento del server DNS, con il comando: | Una volta eliminati gli errori dai log possiamo testare il corretto funzionamento del server DNS, con il comando: | ||
<pre> | <pre> | ||
| Riga 291: | Riga 291: | ||
eyrie A record not found, server failure | eyrie A record not found, server failure | ||
</pre> | </pre> | ||
Il client non sta usando il corretto server DNS. Occorre modificare il file < | Il client non sta usando il corretto server DNS. Occorre modificare il file <code>/etc/resolv.conf</code> oppure agire sulla configurazione di Network Manager. | ||
* Host does not exist | * Host does not exist | ||
<pre> | <pre> | ||
| Riga 297: | Riga 297: | ||
eyrie does not exist, try again | eyrie does not exist, try again | ||
</pre> | </pre> | ||
Problema simile al precedente, per risolvere il quale occorre specificare il dominio di ricerca all'interno del file < | Problema simile al precedente, per risolvere il quale occorre specificare il dominio di ricerca all'interno del file <code>/etc/resolv.conf</code>. | ||
* Record query refused | * Record query refused | ||
<pre> | <pre> | ||
| Riga 303: | Riga 303: | ||
eyrie.raptor.loc A record query refused | eyrie.raptor.loc A record query refused | ||
</pre> | </pre> | ||
Dopo aver ottenuto questo errore comparirà una linea in < | Dopo aver ottenuto questo errore comparirà una linea in <code>/var/log/syslog</code> sul server DNS: | ||
<pre> | <pre> | ||
eyrie:~# tail /var/log/daemon.log | 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 | Jul 3 21:02:22 eyrie named[3095]: client X.X.X.X#32790: query 'eyrie.raptor.loc/A/IN' denied | ||
</pre> | </pre> | ||
Questo indica un problema con la direttiva < | Questo indica un problema con la direttiva <code>allow-query { }</code> in <code>/etc/bind/named.conf.options</code>. | ||
* Does not exist (Authoritative answer) | * Does not exist (Authoritative answer) | ||
<pre> | <pre> | ||
| Riga 315: | Riga 315: | ||
</pre> | </pre> | ||
Di solito questo indica un problema con il Forward DNS, oppure che è stato dimenticato un punto finale in uno di questi files: | Di solito questo indica un problema con il Forward DNS, oppure che è stato dimenticato un punto finale in uno di questi files: | ||
* < | * <code>/etc/bind/db.test</code> | ||
* < | * <code>/etc/bind/db.192.168.1</code> | ||
<br/> | <br/> | ||
: [[Utente:Ferdybassi|Ferdybassi]] | : [[Utente:Ferdybassi|Ferdybassi]] | ||