Combinare dhcp e dns
Usare un server dhcp per gestire anche una rete molto piccola può sembrare uno spreco di risorse e di energie per effettuare la configurazione iniziale, ma a meno che non si preveda di non modificare più la topologia e le componenti della rete per molto tempo, credo che il piccolo sforzo iniziale necessario per configurare il server dhcp venga ampiamente ripagato nel medio/lungo periodo. Inoltre, un server dhcp non richiede molte risorse.
Discorso analogo si potrebbe fare per un server dns che gestisca i nomi della rete locale, con la non lieve differenza che Bind, il server dns usato di seguito, richiede un bel po' di memoria se viene configurato per funzionare anche come una sorta di cache tra i computer della rete interna ed i server dns del provider.
Una volta attivati indipendentemente i due servizi, combinarli per automatizzare la gestione di nomi ed indirizzi è molto semplice e permette di non dover propagare manualmente eventuali modifiche a nomi e/o indirizzi.
Fissiamo alcune basi:
- il server (biancaneve) ha indirizzo 192.168.1.1 e ricoprirà anche il ruolo di dns server e gateway;
- la rete (casetta.nel.bosco) è 192.168.1.0/24;
- ci sono 7 client (dotto, brontolo, pisolo, mammolo, eolo, gongolo, cucciolo) ufficialmente riconosciuti, ma si intende lasciare la possibilità di aggiungerne temporaneamente qualche altro senza dover alterare la configurazione ogni volta;
- useremo i server DHCPd e BIND9 dell Internet Software Consortium.
Piccola postilla: una lettura della documentazione ufficiale che accompagna i due server non è certamente dannosa.
Dhcp
Configurazione iniziale
La configurazione del server dhcp può essere tanto complicata o tanto semplice, secondo i bisogni. Nel nostro caso, è possibile partire con un file di configurazione molto semplice:
# File /etc/dhcpd.conf
# L'indirizzo di biancaneve.
option routers 192.168.1.1;
option subnet-mask 255.255.255.0;
# I tempi sono espressi in secondi.
default-lease-time 600;
max-lease-time 7200;
subnet 192.168.1.0 netmask 255.255.255.0 {
range 192.168.1.101 192.168.1.107;
}
Come è "prassi" comune, il carattere `#' indica l'inizio di una riga che viene completamente ignorata, quindi un buon posto per scrivere alcuni commenti, e le righe contenenti le direttive di configurazione terminano con `;'. Inoltre, la possibilità di creare blocchi annidati permette di limitare l'azione delle direttive che vi compaiono a particolari sottogruppi di client.
Nell'esempio riportato, abbiamo in ordine di comparizione: l'impostazione dell'indirizzo del gateway, della maschera di rete, della durata standard e massima del "prestito" e per finire l'indicazione della rete da gestire, con un range di indirizzi assegnabili molto ristretto. Dato che è possibile gestire contemporaneamente più di una rete, l'indicazione della rete deve avvenire in maniera esplicita. Inoltre, è bene notare che le direttive che compaiono all'esterno di qualunque blocco presente nel file, si applicano globalmente.
Proseguendo il nostro esempio, è possibile spostare per chiarezza le direttive globali all'interno della dichiarazione della rete; ne approfittiamo anche per allungare la durata del "prestito".
# File /etc/dhcpd.conf
authoritative;
subnet 192.168.1.0 netmask 255.255.255.0 {
# default gateway
option routers 192.168.1.1;
option subnet-mask 255.255.255.0;
# 6 ore
default-lease-time 21600;
# 1 giorno
max-lease-time 86400;
range 192.168.1.101 192.168.1.107;
}
La direttiva authoritative indica che le informazioni riportate nel file di configurazione sono corrette e che il server dhcp è "quello che comanda" nelle zone di competenza indicate in seguito, quindi in caso di conflitti sull'uso degli indirizzi il server invierà ai client incriminati pacchetti del protocollo dhcp per "invitarli" a cessare l'utilizzo degli indirizzi errati. Senza questa direttiva, il server dhcp assumerà che le informazioni riportate non siano necessariamente corrette. Anche questa direttiva globale può essere spostata all'interno di una o più zone di competenza.
Di seguito viene dichiarata una sola zona di competenza gestita dal server dhcp che coincide con la rete interna 192.168.1.0/24; all'interno di questo blocco verranno indicate le opzioni, che abbiamo già visto, da applicare automaticamente agli indirizzi gestiti dal server.
Nel file riportato precedentemente si è impostato un range di 7 indirizzi ed è importante notare che se vi fosse un numero maggiore di client contemporaneamente attivi nella rete, qualcuno rimarrebbe senza indirizzo.
Vi sono molte altre direttive che possono essere aggiunte alla configurazione di partenza per indicare ai client la presenza di altri servizi ed impostarli automaticamente; ripredendo anche quelle viste in precedenza, ecco una brevissima lista di alcune direttive utili:
- option routers <indirizzo ip>; (indica l'indirizzo di uno o più gateway)
- option subnet-mask <indirizzo ip>; (indica la maschera di rete)
- option domain-name-servers <indirizzo ip>; (indica l'indirizzo di uno o più server dns)
- option domain-name "<nome di dominio>"; (indica il nome di dominio da aggiungere al nome del client)
- option nis-domain "<nome del dominio NIS>"; (indica il nome del dominio NIS a cui appartiene il client)
- option ntp-servers <indirizzo ip>; (indica l'indirizzo di uno o più server NTP)
- option netbios-name-servers <indirizzo ip>; (indica l'indirizzo di uno o più server NetBIOS)
- option netbios-node-type <tipo di nodo>; (indica il tipo di nodo NetBIOS che il client deve diventare: se il server Samba è configurato in maniera appropriata, un valore di 8 permette di evitare che i client effettuino il broadcasting per ogni operazione che richieda la risoluzione dei nomi)
- use-host-decl-names on; (indica che il client deve assumere il nome inviato dal server assieme all'indirizzo; ha un'utilità abbastanza limitata in quanto lo standard non obbliga i client ad accettare questo nome)
Partizionare lo spazio di indirizzamento
Abbiamo visto che l'insieme di indirizzi assegnabili può essere ristretto con la direttiva range, che può comparire anche più di una volta. Spostando queste direttive range all'interno di blocchi creati con la direttiva pool è possibile dividere la rete in più blocchi a seconda delle esigenze e controllarne l'assegnazione. Uno dei requisiti iniziali era quello di poter aggiungere temporaneamente qualche client "estraneo" alla rete locale; aggiungiamo che vogliamo tenere ben separati gli indirizzi dei client locali da quelli degli eventuali ospiti (magari per applicare qualche restrizione agli ospiti).
Per risolvere questo compito dovremo avere a disposizione i MAC delle schede di rete dei client locali; una volta raccolti i dati che ci serviranno, sarà necessario modificare la configurazione precedente aggiungendo una direttiva host per ogni client locale con la seguente sintassi:
host <nome del client> {hardware ethernet <MAC>;}
Inoltre, dovremo creare un blocco pool nel quale indicare il range di indirizzi allocabili ed i requisiti da soddisfare per permetterne l'utilizzo con le direttive allow o deny:
pool {
range 192.168.1.101 192.168.1.107;
deny unknown clients;
}
Con queste modifiche il server dhcp assegnerà gli indirizzi del range indicato in quel blocco pool solo ai client considerati noti in quanto il loro MAC è indicato esplicitamente nel file di configurazione. Tutte gli altri client saranno classificati come sconosciuti e dovremo indicare un range di indirizzi da assegnare loro:
pool {
range 192.168.1.201 192.168.1.203;
allow unknown clients;
}
Dato che stiamo modificando la configurazione, potremmo anche aggiungere le direttive elencate in precedenza, magari limitandone alcune ai soli client noti. Per effettuare questa distinzione, potremmo aggiungere fuori dal blocco subnet un nuovo blocco group e spostare tutte le direttive host in questo nuovo blocco; ogni altra direttiva aggiunta in questo blocco verrà applicata solo ai client facenti parte di questo gruppo ristretto.
Riassumendo le modifiche ed aggiungendo le direttive elencate precedentemente, abbiamo:
# File /etc/dhcpd.conf
authoritative;
subnet 192.168.1.0 netmask 255.255.255.0 {
# default gateway
option routers 192.168.1.1;
option subnet-mask 255.255.255.0;
option domain-name-servers 192.168.1.1;
# 3 ore
default-lease-time 10800;
# 3 ore
max-lease-time 10800;
# Tutti quelli per cui non esiste un'entry host sono considerati
# sconosciuti.
pool {
range 192.168.1.101 192.168.1.107;
deny unknown clients;
}
pool {
range 192.168.1.201 192.168.1.203;
allow unknown clients;
}
}
group {
option domain-name "casetta.nel.bosco";
option nis-domain "casetta.nel.bosco";
option ntp-servers 192.168.1.1;
option netbios-name-servers 192.168.1.1;
option netbios-node-type 8;
# 6 ore
default-lease-time 21600;
# 1 giorno
max-lease-time 86400;
use-host-decl-names on;
host dotto {hardware ethernet 1A:C3:9D:C1:99:F0;}
host brontolo {hardware ethernet D5:33:4C:E6:45:DA;}
host pisolo {hardware ethernet 46:D3:36:69:24:90;}
host mammolo {hardware ethernet 74:A9:3C:3B:EC:D4;}
host eolo {hardware ethernet 8F:B8:BB:C2:D1:5F;}
host gongolo {hardware ethernet 23:13:35:C1:FA:EB;}
host cucciolo {hardare ethernet 72:6A:FF:6A:31:99;}
}
In questo modo, gli indirizzi "prestati" ai client ospiti hanno una durata molto inferiore; inoltre, questi ospiti saranno configurati automaticamente solo con l'indirizzo del gateway e del server dns. I client locali hanno un trattamento diverso: gli indirizzi hanno una durata molto più lunga, i pc ricevono automaticamente maggiori informazioni sulla rete e se il client dhcp lo permette viene impostato anche il nome del computer.
Host con indirizzo fisso assegnato dal server
Se vi fosse la reale necessità od il desiderio di assegnare ad un client particolare sempre lo stesso indirizzo, ciò può essere fatto anche senza alterare la configurazione del client agendo direttamente sul file di configurazione del server dhcp, tenendo ben presente che l'indirizzo assegnato staticamente non deve essere compreso in alcun range attualmente in uso.
Se volessimo assegnare al client gongolo l'indirizzo 192.168.1.10 (che non è parte di alcun range in uso), basterebbe aggiungere alla direttiva host che riguarda gongolo l'istruzione
fixed-address <indirizzo ip>;
quindi nel nostro caso avremmo
host gongolo {
hardware ethernet 23:13:35:C1:FA:EB;
fixed-address 192.168.1.10;
}
Dns
Configurare un server dns, se si procede a piccoli passi e si tralasciano molte cose, non è difficile anche se una prima occhiata alla documentazione ufficiale potrebbe far pensare il contrario. Partiremo senza molte pretese con una configurazione molto semplice nella quale nomi ed indirizzi sono statici e nella quale il server gestirà solamente la risoluzione di nomi ed indirizzi della rete locale (la creazione di un server dns che funga esclusivamente da cache tra la rete locale ed i nameserver del provider è banale; in ogni caso, la configurazione finale prevederà l'utilizzo del server dns locale anche come cache). In questo scenario il consumo di memoria è proporzionale alla dimensione della rete, ma non incide molto.
Configurazione iniziale
La configurazione del server dns avviene attraverso l'uso di più file, la cui posizione potrebbe differire da sistema a sistema. Nel seguito assumeremo che il file di configurazione principale sia /etc/named.conf e gli altri file si trovino nella directory /var/named/.
// File /etc/named.conf
options {
directory "/var/named";
pid-file "/var/run/named/named.pid";
};
zone "." in {
type hint;
file "named.ca";
};
zone "casetta.nel.bosco" in {
type master;
file "db.casetta.nel.bosco";
};
zone "1.168.192.in-addr.arpa" in {
type master;
file "db.192.168.1";
};
Il formato di questo file ricorda molto quello usato per dhcpd.conf, ma notate la presenza di `;' anche dopo le parentesi graffe che concludono un blocco ed il fatto che anche la sequenza `//' può essere usata per indicare un commento che si estende fino al termine della riga (è possibile anche usare la sintassi classica del C con /*...*/).
Le direttive di configurazione sono raggruppate in blocchi omogenei. Nel blocco relativo alle opzioni abbiamo l'indicazione della directory "di lavoro" nella quale andranno ricercati i file indicati nel seguito della configurazione (quindi named.ca, db.casetta.nel.bosco e db.192.168.1 si troveranno tutti in /var/named/). Sempre in questo blocco abbiamo l'indicazione del file che conterrà il PID del server dns.
Troviamo poi la dichiarazione di tre zone: la prima è la radice della rete e contiene gli indirizzi dei nameserver mondiali; la seconda rappresenta il nostro dominio locale fittizzio casetta.nel.bosco e permette di passare dal nome di un pc al suo indirizzo; la terza zona è necessaria per effettuare la traduzione inversa.
Notate i nomi delle ultime due zone: una è chiamata come il dominio locale fittizzio mentre l'altra è chiamata usando il dominio in-addr.arpa, quindi il nome completo è <indirizzo di rete "rovesciato">.in-addr.arpa; in contrasto con queste indicazioni, i nomi dei file che definiscono le zone possono essere scelti a piacere e nel nostro esempio sono db.<qualche cosa> (tranne named.ca, che dipende dal sistema).
I file di zona
Passando ad una prima scrittura dei nostri due nuovi file di zona, abbiamo db.casetta.nel.bosco:
$TTL 86400 $ORIGIN casetta.nel.bosco. @ IN SOA biancaneve.casetta.nel.bosco. root.biancaneve.casetta.nel.bosco. ( 2004120101 ; serial 10800 ; refresh 3600 ; retry 604800 ; expire 86400) ; negative cache @ IN NS biancaneve.casetta.nel.bosco. biancaneve IN A 192.168.1.1 dotto IN A 192.168.1.101 brontolo IN A 192.168.1.102 pisolo IN A 192.168.1.103 mammolo IN A 192.168.1.104 eolo IN A 192.168.1.105 gongolo IN A 192.168.1.106 cucciolo IN A 192.168.1.107
Analizziamone il contenuto un po' alla volta:
- $TTL 86400 indica che la validità delle informazioni distribuite da questo nameserver è di un giorno; il periodo di validità ha un'estrema importanza in uno scenario più complesso nel quale si abbiano server slave oppure il nameserver sia pubblico, perché in questi casi gli altri nameserver non rileverebbero eventuali modifiche al contenuto della zona prima della scadenza del periodo di validità;
- $ORIGIN casetta.nel.bosco. (notare il punto finale!) indica che qualunque nome non pienamente qualificato che comparirà nel resto della definizione della zona dovrà essere automaticamente completato aggiungendo questa stringa; questa direttiva può essere tralasciata ed in quel caso il valore di $ORIGIN è pari al nome della zona indicato in named.conf;
- nelle righe seguenti `@' è una notazione speciale che si riferisce al valore di $ORIGIN
- il primo vero record che troviamo è di tipo SOA ed indica succintamente la zona, la macchina che la gestisce, l'indirizzo e-mail del responsabile della gestione ed alcuni valori numerici che hanno a che fare con la trasmissione della zona ai nameserver slave (i nameserver secondari); notate che i nomi pienamente qualificati compaiono tutti con un `.' finale, ad indicare il loro stato di qualificazione onde evitare che $ORIGIN venga aggiunto in coda; altra cosa da notare è che l'indirizzo e-mail del gestore non contiene `@' in quanto questo carattere ha un altro significato che abbiamo già visto; torneremo sui valori numerici del record SOA in seguito;
- il record successivo è di tipo NS e serve ad indicare il nameserver responsabile per questa zona;
- per terminare abbiamo una lista di record di tipo A, che servono ad associare un nome ad un indirizzo; nel nostro esempio, i nomi non sono pienamente qualificati (cioè non terminano con un `.') e quindi verranno "espansi" aggiungendovi $ORIGIN.
Per mappare gli indirizzi sui nomi usiamo db.192.168.1:
$TTL 86400 $ORIGIN 1.168.192.in-addr.arpa. @ IN SOA biancaneve.casetta.nel.bosco. root.biancaneve.casetta.nel.bosco. ( 2004120101 ; serial 10800 ; refresh 3600 ; retry 604800 ; expire 86400) ; negative cache @ IN NS biancaneve.casetta.nel.bosco. 1 IN PTR biancaneve.casetta.nel.bosco. 101 IN PTR dotto.casetta.nel.bosco. 102 IN PTR brontolo.casetta.nel.bosco. 103 IN PTR pisolo.casetta.nel.bosco. 104 IN PTR mammolo.casetta.nel.bosco. 105 IN PTR eolo.casetta.nel.bosco. 106 IN PTR gongolo.casetta.nel.bosco. 107 IN PTR cucciolo.casetta.nel.bosco.
Evitando di ripetere quanto già esposto, c'è da notare unicamente il nuovo tipo di record, PTR, che permette di indicare la corrispondenza tra indirizzi e nomi.
Contrariamente a quanto suggerito da alcuni, non creeremo alcuna zona per gestire l'accoppiata localhost e 127.0.0.1: se il server biancaneve è stato configurato come si deve ed in /etc/hosts si è specificato il minimo indispensabile, il sistema funziona perfettamente.
Torniamo ai valori numerici che compaiono nel record SOA; nell'ordine abbiamo:
- il numero seriale serve ad identificare univocamente le "versioni" successive del file di zona in modo che le informazioni vengano trasferite dal master agli slave solo quando il numero seriale della zona del master è maggiore di quella presente sugli slave, quindi deve essere incrementato ad ogni modifica (la prassi comune è di utilizzare la il formato <aaaa><mm><gg><numero>, per assicurare la monotonicità);
- il periodo di refresh, scaduto il quale i nameserver slave controlleranno se il master è stato aggiornato;
- il periodo di retry indica ogni quanto tempo lo slave cercherà di contattare il master in caso di fallimento del controllo precedente;
- il periodo scaduto il quale, se lo slave non sarà riuscito a contattare il master, la zona verrà rimossa dal nameserver secondario;
- il tempo di validità delle risposte NXDOMAIN inviate da questa macchina.
Modifiche a /etc/resolv.conf
Per poter utilizzare il nuovo servizio appena configurato è necessario alterare il file di sistema /etc/resolv.conf aggiungendo prima di tutto il resto solo un paio di righe:
search <nome del dominio locale fittizzio> nameserver <indirizzo del server>
Queste modifiche permetteranno la corretta risoluzione di nomi completi ed incompleti facenti parte del dominio. Nel nostro caso, quindi, aggiungeremo:
search casetta.nel.bosco nameserver 192.168.1.1
Limitare l'accesso al dns
Questa prima configurazione è un po' troppo permissiva in quanto accetta richieste da qualunque indirizzo. Per correggere questo comportamento è possibile indicare esplicitamente un insieme di indirizzi che potranno interrogare il server dns tramite il blocco acl. Aggiungiamo il blocco indipendente ed indichiamo che siamo disposti ad accettare interrogazioni solo dagli indirizzi della sottorete e dall'indirizzo di loopback:
acl "retelocale" {
192.168.1.0/24;
127.0.0.1;
};
Poi aggiungiamo tra le opzioni:
options {
// ...
allow-query {
"retelocale";
};
// ...
};
Si nota chiaramente quanto siamo stati "larghi" nella definizione dell'acl, quindi si tratta più che altro di un esempio da modificare secondo i bisogni (soprattutto restringendo il range di indirizzi).
Inoltrare le richieste di risoluzione
All'inizio abbiamo affermato che configurare il server dns per fungere da cache dei nomi è banale. Per dimostrare quanto affermato, ecco le modifiche da apportare alla configurazione:
options {
// ...
forward first;
forwarders {
193.70.152.15;
193.70.152.25;
};
// ...
};
Nell'esempio, 193.70.152.15 e 193.70.152.25 sono gli indirizzi di due nameserver del provider in uso, ma nulla vieta di utilizzare altri nameserver (se la rete è parte di una struttura più grande, con i propri nameserver, conviene usare quelli).
Il valore first della direttiva forward indica che il server dns inoltrerà ogni richiesta per zone che non gli competono ai nameserver indicati nel blocco forwarders e se la ricerca dovesse fallire tenterà di risolvere la richiesta per proprio conto; se anche questa ricerca dovesse fallire restituirà un messaggio di errore.
Per fare in modo che il server dns non effettui questa ricerca è possibile sostituire first con only.
Per evitare di dover modificare la configurazione nel caso che l'indirizzo di qualche nameserver dovesse cambiare, è possibile spostare il blocco forwarders in un file indipendente ed includerlo tramite la direttiva include:
options {
// ...
forward first;
include "/var/named/forwarders";
// ...
};
In questo modo è anche possibile aggiornare automaticamente gli indirizzi dei nameserver prelevandoli dai file di configurazione di sistema durante la fase di inizializzazione del computer.
Dns + dhcp = aggiornamento dinamico delle zone
È giunto il momento di passare a trattare le modifiche necessarie ad integrare i due servizi: faremo in modo che il server dhcp comunichi al server dns le assegnazioni e le revoche degli indirizzi e che quest'ultimo aggiorni automaticamente le zone.
Identificare chi può chiedere l'aggiornamento
Per evitare problemi di qualunque tipo, solo entità ben identificate devono essere in grado di chiedere al server dns l'aggiornamento delle zone gestite da quest'ultimo. Il modo di identificare queste entità è l'utilizzo di chiavi crittografiche condivise dal server dns e dal server dhcp.
Generare una di queste chiavi è molto semplice:
dnssec-keygen -a hmac-md5 -b 128 -n HOST DHCP_UPDATER
La chiave sarà disponibile in un file chiamato KDHCP_UPDATER*.private, in corrispondenza della riga "Key:". Dovremo copiare la chiave in un file indipendente, diciamo /etc/dhcp-dns.key, in un apposito blocco key:
key DHCP_UPDATER {
algorith hmac-md5;
secret <la chiave>;
};
I permessi di lettura di questo file dovrebbero essere tali che solo agli utenti con le cui credenziali vengono eseguiti il server dns ed il server dhcp siano in grado di leggerne il contenuto.
Modifiche a named.conf
Nel file di configurazione principale del server dns aggiungeremo l'istruzione per includere la chiave e trasformeremo i due blocchi di dichiarazione delle zone come segue:
include "/etc/dhcp-dns.key";
zone "casetta.nel.bosco" in {
type master;
file "db.casetta.nel.bosco";
allow-update {key DHCP_UPDATER;};
};
zone "1.168.192.in-addr.arpa" in {
type master;
file "db.192.168.1";
allow-update {key DHCP_UPDATER;};
};
Modifiche ai file di zona
I file di zona verranno semplificati drasticamente lasciando inalterata la prima parte e riducendo gli elenchi di record di tipo A e di tipo PTR ad un solo elemento: l'unico record rimasto in ogniuno dei due elenchi sarà il primo, quello relativo al server stesso.
Modifiche a dhcpd.conf
Le modifiche alla configurazione del server dhcp sono molto semplici: dovremo includere il file /etc/dhcp-dns.key per avere la chiave che autorizzi il server ad inviare le richieste di modifica alle zone, indicheremo lo schema di aggiornamento da utilizzare ed aggiungeremo la dichiarazione delle due zone.
ddns-update-style interim;
include "/etc/dhcp-dns.key"
zone casetta.nel.bosco. {
primary 127.0.0.1;
key DHCP_UPDATER;
}
zone 1.168.192.in-addr.arpa {
primary 127.0.0.1;
key DHCP_UPDATER;
}
Terminate anche queste modifiche, i due server saranno in grado di comunicare tra loro e le zone gestite dal server dns saranno popolate automaticamente con i nomi e gli indirizzi gestiti dal server dhcp, che si occuperà anche di richiederne la rimozione alla scadenza del prestito o quando gli indirizzi non saranno più in uso.
Trattare gli host con indirizzo fisso assegnato dal server dhcp
La gestione degli host a cui il server dhcp assegna un indirizzo statico avviene in maniera diversa in quanto, normalmente, il server dhcp non invia alcuna richiesta di aggiornamento al server dns. La documentazione originale del server dhcp lo sconsiglia, ma è possibile obbligare il server dhcp ad inviare richieste di aggiornamento delle zone anche per gli host a cui viene assegnato un indirizzo fisso aggiungendo quanto segue:
update-static-leases on;
A conti fatti, però, se non si tratta di un numero elevato di client oppure se non ci si trova nella condizione di aver associato ad un client più di un indirizzo, conviene indicare direttamente nei file di zona i nomi e gli indirizzi dei client che riceveranno un indirizzo fisso dal server dhcp.
Riassunto dei file di configurazione
dhcpd.conf
ddns-update-style interim;
authoritative;
subnet 192.168.1.0 netmask 255.255.255.0 {
# default gateway
option routers 192.168.1.1;
option subnet-mask 255.255.255.0;
option domain-name-servers 192.168.1.1;
# 3 ore
default-lease-time 10800;
# 3 ore
max-lease-time 10800;
# Tutti quelli per cui non esiste un'entry host sono considerati
# sconosciuti.
pool {
range 192.168.1.101 192.168.1.107;
deny unknown clients;
}
pool {
range 192.168.1.201 192.168.1.203;
allow unknown clients;
}
}
group {
option domain-name "casetta.nel.bosco";
option nis-domain "casetta.nel.bosco";
option ntp-servers 192.168.1.1;
option netbios-name-servers 192.168.1.1;
option netbios-node-type 8;
# 6 ore
default-lease-time 21600;
# 1 giorno
max-lease-time 86400;
use-host-decl-names on;
host dotto {hardware ethernet 1A:C3:9D:C1:99:F0;}
host brontolo {hardware ethernet D5:33:4C:E6:45:DA;}
host pisolo {hardware ethernet 46:D3:36:69:24:90;}
host mammolo {hardware ethernet 74:A9:3C:3B:EC:D4;}
host eolo {hardware ethernet 8F:B8:BB:C2:D1:5F;}
host gongolo {hardware ethernet 23:13:35:C1:FA:EB;}
host cucciolo {hardare ethernet 72:6A:FF:6A:31:99;}
}
include "/etc/dhcp-dns.key"
zone casetta.nel.bosco. {
primary 127.0.0.1;
key DHCP_UPDATER;
}
zone 1.168.192.in-addr.arpa {
primary 127.0.0.1;
key DHCP_UPDATER;
}
dhcp-dns.key
key DHCP_UPDATER {
algorith hmac-md5;
secret <la chiave>;
};
named.conf
acl "retelocale" {
192.168.1.0/24;
127.0.0.1;
};
options {
directory "/var/named";
pid-file "/var/run/named/named.pid";
allow-query {
"retelocale";
};
forward first;
forwarders {
193.70.152.15;
193.70.152.25;
};
};
zone "." in {
type hint;
file "named.ca";
};
# La chiave è in comune con il server dhcp.
include "/etc/dhcpd.key";
zone "casetta.nel.bosco" in {
type master;
file "db.casetta.nel.bosco";
allow-update {key DHCP_UPDATER;};
};
zone "1.168.192.in-addr.arpa" in {
type master;
file "db.192.168.1";
allow-update {key DHCP_UPDATER;};
};
db.casetta.nel.bosco
$TTL 86400 $ORIGIN casetta.nel.bosco. @ IN SOA biancaneve.casetta.nel.bosco. root.biancaneve.casetta.nel.bosco. ( 2004120101 ; serial 10800 ; refresh 3600 ; retry 604800 ; expire 86400) ; negative cache @ IN NS biancaneve.casetta.nel.bosco. biancaneve IN A 192.168.1.1
db.192.168.1
$TTL 86400 $ORIGIN 1.168.192.in-addr.arpa. @ IN SOA biancaneve.casetta.nel.bosco. root.biancaneve.casetta.nel.bosco. ( 2004120101 ; serial 10800 ; refresh 3600 ; retry 604800 ; expire 86400) ; negative cache @ IN NS biancaneve.casetta.nel.bosco. 1 IN PTR biancaneve.casetta.nel.bosco.
Ultima modifica: Tue Mar 21 08:40:29 CET 2006
