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

Vai alla navigazione Vai alla ricerca

Un server DNS e DHCP su Debian (visualizza wikitesto)

Versione delle 18:41, 12 feb 2012

39 byte aggiunti ,  12 feb 2012
m
→‎Installazione e configurazione del server DHCP
Riga 318: Riga 318:
# /etc/init.d/isc-dhcp-server start
# /etc/init.d/isc-dhcp-server start
</pre>
</pre>
=== Aggiornamento dinamico DNS ===
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>
include "/etc/bind/rndc.key";
controls {
        inet 127.0.0.1 allow {localhost; } keys { "rndc-key"; };
};
</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:
<pre>
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; };
};
</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 (/etc/dhcp/dhcpd.conf da Squeeze):
<pre>
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 "1.168.192.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;
        }
</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:
<pre>
# chmod 775 /etc/bind
</pre>
Verificare  che anche i file <code>db.test</code> e  <code>db.192.168.1</code> siano scrivibili da bind (potrebbe  succedere che uno o entrambi i file abbiano come proprietario  <code>root:bind</code> e che i permessi di gruppo siano di  sola lettura).<br />
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.


=== Alcune note generali ===  
=== Alcune note generali ===  
Riga 379: Riga 424:
Se non risultano indirizzi disponibili quando un client ne fa richiesta, il server tenterà di utilizzare uno degli indirizzi contrassegnati come abbandonati. Dopo aver contrassegnato detto indirizzo come libero si ripete la precedente procedura; se non viene ricevuta alcuna risposta ''ICMP Echo'' allora il server procede alla sua assegnazione presso il client.<br>
Se non risultano indirizzi disponibili quando un client ne fa richiesta, il server tenterà di utilizzare uno degli indirizzi contrassegnati come abbandonati. Dopo aver contrassegnato detto indirizzo come libero si ripete la precedente procedura; se non viene ricevuta alcuna risposta ''ICMP Echo'' allora il server procede alla sua assegnazione presso il client.<br>
Il server DHCP non effettua alcuna iterazione degli indirizzi IP abbandonati se il primo che tenta di reclamare risulta libero. Piuttosto, quando riceve il successivo ''DHCPDISCOVER'' dal client tenterà tipicamente una nuova allocazione usando lo stesso metodo qui descritto, ma su un nuovo indirizzo IP.
Il server DHCP non effettua alcuna iterazione degli indirizzi IP abbandonati se il primo che tenta di reclamare risulta libero. Piuttosto, quando riceve il successivo ''DHCPDISCOVER'' dal client tenterà tipicamente una nuova allocazione usando lo stesso metodo qui descritto, ma su un nuovo indirizzo IP.
=== 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:
<pre>
include "/etc/bind/rndc.key";
controls {
        inet 127.0.0.1 allow {localhost; } keys { "rndc-key"; };
};
</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:
<pre>
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; };
};
</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 (/etc/dhcp/dhcpd.conf da Squeeze):
<pre>
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 "1.168.192.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;
        }
</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:
<pre>
# chmod 775 /etc/bind
</pre>
Verificare che anche i file <code>db.test</code> e <code>db.192.168.1</code> siano scrivibili da bind (potrebbe succedere che uno o entrambi i file abbiano come proprietario <code>root:bind</code> e che i permessi di gruppo siano di sola lettura).<br />
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 ==
== Troubleshooting Bind ==
Wtf
3 155

contributi

Estratto da "https://guide.debianizzati.org/index.php/Speciale:DiffMobile/27479"

Menu di navigazione