Un server DNS e DHCP su Debian: differenze tra le versioni

m
- <br />; min
m (ha spostato Un server DNS e DHCP su Debian Etch a Un server DNS e DHCP su Debian: La guida è valida anche per Lenny e Squeeze e il titolo è fuorviante.)
m (- <br />; min)
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 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/>
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 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:
Riga 8: Riga 10:
# 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 <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/>
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.
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/>
 
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.
 
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:
 
=== /etc/resolv.conf: ===
=== /etc/resolv.conf: ===
<pre>
<pre>
Riga 15: Riga 21:
nameserver 127.0.0.1  
nameserver 127.0.0.1  
</pre>
</pre>
=== /etc/bind/named.conf: ===
=== /etc/bind/named.conf: ===
<pre>
<pre>
Riga 53: Riga 60:
};  
};  
</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.
Riga 71: Riga 79:
client          IN      A      192.168.1.3
client          IN      A      192.168.1.3
</pre>
</pre>
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 files locali per verificare eventuali cambiamenti. Il valore di default è espresso in secondi.<br/>
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:
Le linee successive indicano il '''SOA''' (Start Of Authority); il formato di questi record è il seguente:
<pre>
<pre>
Riga 133: Riga 142:
<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 <code>/etc/bind/named.conf.options</code> aggiungendo queste righe:
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 159: Riga 169:
};
};
</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.
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.
 
Per aumentare il livello di protezione sono state aggiunte anche le direttive <code>allow</code>, permettendo 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. È 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:
<pre>
<pre>
# apt-get install dhcp3-common dhcp3-server
# apt-get install dhcp3-common dhcp3-server
Riga 206: Riga 217:


== 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 <code>/etc/bind/named.conf.local</code> per indicare che il server DNS accetta aggiornamenti dinamici solamente da localhost utilizzando la chiave segreta:
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 213: Riga 224:
};
};
</pre>
</pre>
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:  
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 226: Riga 237:
};
};
</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 <code>/etc/bind/rndc.key</code>. Ciò si traduce nell’aggiunta delle seguenti opzioni nel file di configurazione /etc/dhcp3/dhcpd.conf:
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 243: Riga 254:
         }
         }
</pre>
</pre>
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:
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:
<pre>
<pre>
# chmod 775 /etc/bind
# chmod 775 /etc/bind
</pre>
</pre>
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 ==
Riga 261: Riga 272:
* 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 <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.
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 <code>.</code> alla fine della dichiarazione del FQDN all'interno dei files:
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.test</code>
* <code>/etc/bind/db.192.168.1</code>
* <code>/etc/bind/db.192.168.1</code>
==== Filename Typo ====
==== Filename Typo ====
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:
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:
Riga 273: Riga 287:
   /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:
Riga 294: Riga 309:
</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:
Riga 331: Riga 347:
* <code>/etc/bind/db.test</code>
* <code>/etc/bind/db.test</code>
* <code>/etc/bind/db.192.168.1</code>
* <code>/etc/bind/db.192.168.1</code>
<br/>
 
: [[Utente:Ferdybassi|Ferdybassi]]
: [[Utente:Ferdybassi|Ferdybassi]]
----
----
[[Categoria:Server]]
[[Categoria:Server]]
[[Categoria:Networking]]
[[Categoria:Networking]]
914

contributi