Creare un server DNS casalingo su piattaforma *buntu con Bind9

Che un server DNS casalingo non sia proprio una necessità è risaputo, soprattutto quando gli host della nostra LAN si contano sulle dita di una mano. Però, nonostante tutto, ci sono alcuni vantaggi che mi hanno spinto a realizzare un nameserver sulla mia linux box, ovvero:

1) il caching, per non interrogare continuamente i DNS del mio ISP ed avere risposte più rapide (si spera) alle query;

2) creare una configurazione ad hoc in modo da riprendere confidenza con bind.

Bene, per prima cosa installiamo bind9 sulla box, sfruttando il solito aptitude:

nightfly@nightbox:~$ sudo apt-get install bind9

Una volta completata l'installazione posizioniamoci nella directory /etc/bind

nightfly@nightbox:~$ cd /etc/bind

Passiamo subito alla configurazione di bind, editando il file named.conf.options

nightfly@nightbox:~$ sudo nano named.conf.options

a questo punto sostituiamo

// forwarders {
// 0.0.0.0;
// };

con

forwarders {
x.x.x.x;
y.y.y.y;
};

dove x.x.x.x ed y.y.y.y sono rispettivamente il DNS primario e secondario del nostro ISP.

Bene, ora passiamo alla configurazione del file named.conf.local, in cui specificare le zone per le quali il nostro nameserver risulta autoritativo:

nightfly@nightbox:~$ sudo nano named.conf.local

ed inseriamo la seguente configurazione:

zone "mylittlelan.org" {
type master;
file "/etc/bind/db.mylittlelan";
};

Abbiamo quasi finito. Non ci resta che creare il file db.mylittlelan all'interno della dir /etc/bind e metterci dentro i seguenti parametri:

$TTL 10800
@ IN SOA server.mylittlelan.org. root.mylittlelan.org. (
2006050644 ; Serial
10800 ; Refresh
3600 ; Retry
3600 ) ; Negative Cache TTL
;
mylittlelan.org. NS server.mylittlelan.org.
;
server IN A 192.168.1.1
host1 IN A 192.168.1.4
host2 IN A 192.168.1.2
firewall IN A 192.168.1.7
router IN A 192.168.1.8
;

Analizziamo tale configurazione passo passo:

la direttiva TTL (Time To Live) specifica la durata delle entry DNS (in secondi), ovvero per quanto tempo una data associazione IP - hostname deve rimanere memorizzata nel nostro nameserver.

Il record SOA fornisce informazioni fondamentali sulla zona, ovvero il nameserver autoritativo server.mylittlelan.org., l'indirizzo email dell'amministratore (ovvero root.mylittlelan.org., in cui la @, che in questo contesto ha ben altro significato, è stata sostituita con un . - leggasi [email protected])

All'interno del record in questione notiamo inoltre la presenza di altre info, quali:

Serial, ovvero il nuero di serie (incrementale) associato ai record della zona, sfruttato per individuare le entry più aggiornate nel caso in cui vi siano più DNS autoritativi per la zona (master-slave);

Refresh, ovvero ogni quanto tempo un eventuale slave deve effettuare un refresh delle entry in suo possesso, contattando il master (le cui entry dovrebbero essere più recenti);

Retry, ovvero dopo quanto tempo un eventuale slave deve richiedere nuovamente un trasferimento di zona al master, poichè i tentativi precedenti non sono andati a buon fine.

Successivamente specifico il nameserver autoritativo per la mia zona (record NS):

mylittlelan.org. NS server.mylittlelan.org.

che è equivalente a scrivere:

@ IN NS server.mylittlelan.org.

e quindi l'associazione hostname - IP per la mia zona (record A):

server IN A 192.168.1.1
host1 IN A 192.168.1.4
host2 IN A 192.168.1.2
firewall IN A 192.168.1.7
router IN A 192.168.1.8

che è equivalente a scrivere:

server.mylittlelan.org. A 192.168.1.1
host1.mylittlelan.org. A 192.168.1.4
host2.mylittlelan.org. A 192.168.1.2
firewall.mylittlelan.org. A 192.168.1.7
router.mylittlelan.org. A 192.168.1.8

NB: il ; viene utilizzato per i commenti. Da notare, inoltre, il punto alla fine dell'hostname completo (ad esempio server.mylittlelan.org). Questo dice a bind che l'hostname che gli è stato fornito è completo. Se infatti avessimo scritto server.mylittlelan.org senza punto finale, bind sarebbe andato alla ricerca di server.mylittlelan.org.mylittlelan.org

Verifichiamo la configurazione di bind mediante il comando:

nightfly@nightbox:~$ named-checkconf

Se non viene visualizzato alcun messaggio vuol dire che la configurazione è corretta.

Successivamente saggiamo la validità del file che identifica la nostra zona, ovvero db.mylittlelan:

nightfly@nightbox:~$ named-checkzone mylittlelan.org db.mylittlelan

Se otteniamo un output simile al seguente:

zone mylittlelan.org/IN: loaded serial 2086050644
OK

significa che anche il file di zona non presenta anomalie di sorta.

Per ragioni di sicurezza dobbiamo definire una specifica zona per gestire le query DNS inverse (che ci restituiscono l'hostname a partire da un dato indirizzo IP).

Poichè la nostra LAN sfrutta la tipica classe C privata (192.168.1.0) chiameremo la nostra zona 1.168.192.in-addr.arpa A tal proposito creiamo il file db.192 ed inseriamo al suo interno la seguente configurazione:

$TTL 10800
@   IN   SOA   server.mylittlelan.org. root.mylittlelan.org. (
2086050644 ; Serial
10800   ; Refresh
3600   ; Retry
604800   ; Expire
86400)   ; Minimum TTL
NS   server.mylittlelan.org.
1   PTR   server.mylittlelan.org.
2   PTR   host1.mylittlelan.org.
4      PTR      host2.mylittlelan.org.
7      PTR      firewall.mylittlelan.org.
8      PTR      router.mylittlelan.org.

Verifichiamo che la zona sia configurata correttamente utilizzando ancora una volta il comando named-checkzone:

nightfly@nightbox:/etc/bind$ named-checkzone 1.168.192.in-addr.arpa db.192

se otteniamo il seguente output:

zone 1.168.192.in-addr.arpa/IN: loaded serial 2086050644
OK

vuol dire che la zona è stata configurata correttamente.

Modifichiamo il file resolv.conf posizionato nella directory /etc:

nightfly@nightbox:~$ sudo nano /etc/resolv.conf

e nella prima riga inseriamo:

192.168.1.1

ovvero l'indirizzo IP del nostro DNS locale.

Riavviamo quindi bind digitando:

nightfly@nightbox:~$ sudo /etc/initd./bind9 restart

e finalmente il nostro nameserver è dovrebbe essere funzionante e pronto all'uso. Utilizziamo dig per esserne certi, provando dapprima una query diretta e successivamente una query inversa:

nightfly@nightbox:/etc/bind$ dig router.mylittlelan.org

e dovremmo ottenere un risultato simile al seguente:

; <<>> DiG * <<>> router.mylittlelan.org
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 38471
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1
;; QUESTION SECTION:
;router.mylittlelan.org.   IN   A
;; ANSWER SECTION:
router.mylittlelan.org. 10800 IN   A   192.168.1.8
;; AUTHORITY SECTION:
mylittlelan.org.   10800   IN   NS   server.mylittlelan.org.
;; ADDITIONAL SECTION:
server.mylittlelan.org.   10800   IN   A   192.168.1.1
;; Query time: 0 msec
;; SERVER: 192.168.1.1#53(192.168.1.1)
;; WHEN: Thu Aug 12 20:47:13 2010
;; MSG SIZE rcvd: 94

Proviamo ora la query inversa, utilizzando l'opzione -x:

nightfly@nightbox:/etc/bind$ dig -x 192.168.1.8

Dovremmo ottenere:

; <<>> DiG * <<>> -x 192.168.1.8
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 40059
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1
;; QUESTION SECTION:
;1.2.168.192.in-addr.arpa.   IN   PTR
;; ANSWER SECTION:
1.1.168.192.in-addr.arpa. 10800 IN   PTR   router.mylittlelan.org.
;; AUTHORITY SECTION:
1.168.192.in-addr.arpa. 10800   IN   NS   server.mylittlelan.org.
;; ADDITIONAL SECTION:
server.mylittlelan.org.   10800   IN   A   192.168.1.1
;; Query time: 0 msec
;; SERVER: 192.168.1.1#53(192.168.1.1)
;; WHEN: Thu Aug 12 20:53:12 2010
;; MSG SIZE rcvd: 115