Creiamo un server DNS con Bind [Parte 2.1° - I file di zona e la risoluzione diretta]

Ieri vi ho spiegato cos’è e come funziona un server dns a seconda della tipologia alla quale appartiene…

durante il proliferarsi dell’articolo ho fatto riferimento più volte ai file di zona, ma precisamente queste zone che cosa sono?

Dicesi zona, l’insieme di parametri che servono al server dns per effettuare la risoluzione diretta o inversa tra nome host ed indirizzo ip. Mentre il file ovviamente, è quel file di testo che contiene la zona in questione.

Nel caso di bind i file di zona sono locati dentro /etc/bind e iniziano tutti per db. seguito dal nome dominio (es. db.logubuntu.it) e dentro contengono la zona per il dominio annesso.

Nella figura in alto possiamo vedere una zona correttamente configurata, come esempio, per il dominio albacos.net, come potete vedere ha una struttura precisa, uguale per tutte le zone esistenti.

Passiamo ora ad analizzarla per comprenderne il funzionamento, a tal proposito prendiamo in esame la zona del dominio logubuntu.it, quella di questo blog:

Vedendo la figura, vediamo dapprima una serie di stringhe commentate che non vengono interpretate, e riconoscibili dal carattere punto e virgola ( ; ) e poi il primo record utile:

$TTL 86400

Questo record indica il TTL della zona ossia il time to live; è un record che va inserito obbligatoriamente prima di tutti gli altri record della zona, ed indica il tempo massimo che i vari server dns possono tenerla in cache, viene da se quindi che è utile impostare un valore alto per zone con poche modifiche, viceversa per quelle frequentemente aggiornate. Il ttl inoltre è una direttiva che può essere inserita opzionalmente, a singoli record, utile se magari la zona subisce frequenti modifiche solo in un determinato record e quindi anzichè costringere tutti gli altri dns a ricaricare l’intera zona, viene fatto ricaricare il singolo record aggiornato, l’unità di misura è in secondi.

@ IN SOA localhost. root.localhost. (
1 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
86400 ) ; Negative Cache TTL


A seguire, vediamo il record SOA che sta per Start of Authority ed è la parte principale della zona. Il record SOA viene letto dagli eventuali server dns slave, o secondari, con questo record sanno quale è il server dns autoritativo del dominio (in questo caso di esempio è localhost ma va specificato l’intero hostname del server dns), quindi a chi chiedere per poter effettuare il refresh della stessa. A seguire troviamo l’indirizzo del responsabile della zona, per indirizzo intendo la casella di posta, generalmente i manteiner indicano il proprio postmaster, il bot che vi manda le mail di errore quando per qualsiasi motivo non si riesce a recapitare una vostra mail (es. postmaster@logubuntu.it), solo che al posto della @ dell’indirizzo di posta, viene messo un punto ( . ) vediamo perchè…

Il carattere AT (@) nella sintassi dei file di zona, viene chiamato record NULL e, in maniera molto semplice, indica il secondo livello del dominio, cioè in questo caso, logubuntu.it. Tra un pò capirete meglio a cosa serve

All’interno della direttiva SOA vediamo prima il record null, poi il record IN poi il vero e proprio record SOA, e poi una serie di stringhe tra parentesi, dapprima incontriamo il serial, che è naturalmente, il seriale della zona; è quel record che va incrementato ad ogni modifica della zona, di modo che i server slave e quelli dell’authority sanno che la zona è cambiata e quindi va ricaricata.

Per comodità da ora in poi mi riferirò ai record come se la zona fosse riferita ad eventuali server slave e ai server dell’authority, di modo da non dover ripetere ad esempio “di modo che i server slave e quelli dell’authority sanno che la zona è cambiata e quindi va ricaricata.” Spero di essere stato abbastanza comprensibile

dopo il seriale troviamo il tempo di refresh, ossia il il tempo, espresso in secondi, trascorso il quale i server slave devono controllare, ed eventualmente ricaricare (tramite il serial quindi), la zona.

A seguire c’è il tempo di retry, ossia il tempo trascorso il quale, il server slave, deve riprovare a connettersi al dns primario del dominio per effettuare il refresh della zona, nel caso ad esempio durante il primo tentativo il processo non sia andato a buon fine, per un qualsiasi motivo.

Continuando troviamo il tempo di expire, ossia il tempo dopo del quale la zona deve essere non considerata come valida, e quindi, al di la del fatto che sia trascorso o meno in quel momento il tempo di refresh, deve essere ricaricata dagli slave, è importante che questo record sia il più grande tra quelli di refresh e di expire, altrimenti la zona verrebbe considerata come non valida prima ancora di essere caricata.

L’ultimo record di tipo ttl che troviamo è il record minimum, che indica il tempo massimo per il quale i server slave devono tenere in cache una query SOA non valida.

La direttiva soa generalmente viene tenuta ai valori di default, se proprio si deve agire pesantemente sui ttl si agisce su quello dell’intera zona.

All’inizio della direttiva SOA, abbiamo visto un record strano, IN, che non ho spiegato volutamente prima, perchè mi serviva che lo capiste ora, questo record sta a significare INternet ed indica che la direttiva all’interno della quale viene inserito, è da considerarsi pubblica, ossia consultabile sia dall’interno della lan, che da internet. E’ un record che va inserito necessariamente all’interno della direttiva SOA, in quanto i dns dell’authority devono poter caricare il SOA di un dominio per considerare il dominio valido. Nelle direttive che andranno a seguire invece è un parametro, che seppur è sempre presente, è opzionale, rendendo quindi la direttiva consultabile solo dalla propria lan.

@ IN NS localhost.

La prima direttiva che incontriamo è quella denominata NS che sta per Name Server, ed indica qual’è il server dns autoritativo del dominio.

Attenzione! qui inizia il bello, da questo momento in poi, per dominio è da intendere sia il secondo livello che i vari record di terzo livello, questo significa che ad esempio per il record @ io posso definire come name server il primario, ossia quello che contiene il file di zona per il dominio logubuntu.it, però posso avere la necessità che ad esempio per il terzo livello forum.logubuntu.it, il dns autoritativo non sia quello attuale ma un altro, perchè magari il terzo livello del mio dominio non si compone solo di forum.logubuntu.it, ma contiene altri sottodomini (1.forum.logubuntu.it, admin.forum.logubuntu.it, e cosi via) che devono essere gestiti da altri server, il record NS quindi non sarà più @ IN NS dns1.logubuntu.it, ma sarà scritto come forum IN NS dns2.logubuntu.it, questo indica che per il dominio logubuntu.it, e tutto quello scritto prima (per es. mail.logubuntu.it, blog.logubuntu.it, ecc..) l’authority deve fare riferimento al server dns1.logubuntu.it, mentre per il solo dominio di terzo livello forum.logubuntu.it, deve consultare il server dns2.logubuntu.it.

Come scritto prima, in questa direttiva può essere inserito in alternativa, un record ttl, per specificare che questa sola direttiva, deve essere ricaricata dopo il tempo ttl trascorso, la direttiva quindi sarà modificata cosi:

@ IN 300 NS localhost.

Il che indica che ogni 300 secondi deve essere ricaricata, notare infine che alla fine viene inserito un punto. Ebbene dovete sapere che la sintassi dei file di zona prevede che nelle direttive NS, l’hostname del server dns deve finire con un punto, questo perchè il punto in fase di lettura (che avviene in maniera sequenziale, cioè come se fosse in un unica riga) determina la fine della direttiva e quindi tutto ciò che viene dopo riguarda una nuova direttiva.

Infine c’è da sapere che per le direttive NS non sono accettati indirizzi ip, l’indirizzo del name server deve essere necessariamente espresso sotto forma di hostname completo.

@ IN MX 5 alt2.aspmx.l.google.com.
@ IN MX 10 aspmx2.googlemail.com.
@ IN MX 10 aspmx3.googlemail.com.
@ IN MX 10 aspmx4.googlemail.com.
@ IN MX 10 aspmx5.googlemail.com.
@ IN MX 1 aspmx.l.google.com.

La direttiva successiva che incontriamo è quella MX che significa Mail eXchanger, ed indica gli hostname dei server di posta che gestiscono il traffico SMTP (e solo quello) del dominio.

Anche qui vale il discorso fatto prima per il record @, se prendiamo ad esempio i primi due record

@ IN MX 10 aspmx2.googlemail.com.
@ IN MX 10 aspmx3.googlemail.com.

e li trasformiamo in

staff IN MX 10 aspmx2.googlemail.com.
publishers IN MX 10 aspmx3.googlemail.com.

indicheremo che per tutta la posta diretta alle caselle che finiscono per @staff.logubuntu.it (attenzione a non confondere questa chiocciola con il record null del file di zona, qui stiamo parlando di caselle di posta ) il client deve spedire la posta a aspmx2.googlemail.com, mentre per tutta la posta diretta alle caselle con dominio @publishers.logubuntu.it deve essere dirottata su aspmx3.googlemail.com.

Di seguito incontriamo il record (che vi ricordo è opzionale) IN, e sappiamo già di cosa si tratta, e poi un record numerico, che non è da confondere con il ttl (il ttl eventualmente va inserito dopo il record IN ricordate? ), ma è invece il peso che ha il record all’interno della direttiva MX. Prendendo in esame l’intera direttiva infatti notiamo che il peso è specificato in ogni record, e deve essere specificato in ogni caso anche se il record è uno solo, il peso indica con quale priorità il server di posta mittente deve contattare i vari server di posta destinatari.

Avremo quindi che se viene spedita una mail ad un utente del dominio logubuntu.it, da un utente del dominio debian.org, il server di posta di debian.org contatterà per primo aspmx.l.google.com., in quanto ha peso minore, se non riesce a contattarlo, perchè per puro caso è down, debian.org passerà a contattare alt2.aspmx.l.google.com, che ha il peso subito dopo maggiore, se per un attacco di sfiga nemmeno questo sarà raggiungibile, debian.org proverà a deliverare la mail a aspmx2.googlemail.com, aspmx3.googlemail.com, aspmx4.googlemail.com e aspmx5.googlemail.com; questa volta verranno contattati tutti insieme e non uno solo, perchè come potete vedere dal file di zona hanno tutti peso uguale.

Infine notate che anche qui gli hostname dei server MX devono terminare con un punto, ed anche qui, sono accettati solo gli hostname completi dei server non gli indirizzi ip.

@ IN A 89.163.145.208
www IN A 89.163.145.208

Dopo la direttiva MX troviamo quella in A che significa Address, al contrario delle altre direttive, quella in A accetta solo indirizzi IP e non hostname, e non si deve mettere il punto a fine indirizzo. Valgono invece le regole per il ttl del singolo record e l’omissione o meno del record IN.

Questa direttiva è fondamentale, in quanto qui avviene la vera è propria risoluzione da hostname ad indirizzo ip, e qui vengono dichiarati gli hostname dei vari server del dominio.

Ad esempio se io nella direttiva NS avessi inserito il record @ IN NS dns.logubuntu.it, avrei dovuto dichiarare all’interno della direttiva in A che il record dns del dominio logubuntu.it corrisponde all’ip 64.121.56.254 (per esempio), altrimenti la zona non funzionerebbe in quanto non si riuscirebbe ad ottenere la risoluzione da dns.logubuntu.it ad ip del server. Stessa cosa dicasi ovviamente per la direttiva MX, se invece per la direttiva MX definiamo server all’esterno del nostro dominio non è necessario, anzi non si deve proprio farlo, definire all’interno della direttiva A l’indirizzo ip del server MX.

Come potete vedere nella mia zona ci sono due record simili per indirizzo ip, ma differenti per il terzo livello, una infatti include il record @, un altra il record www…chi sa quanti di voi si saranno accorti che digitando http://www.logubuntu.it o http://logubuntu.it (senza www) finiscono sempre su questo blog il motivo è proprio questo, perchè con il record @ definisco che le richieste verso http://logubuntu.it vadano a finire su quell’ip, e con il record www definisco che http://www.logubuntu.it deve finire sullo stesso ip questo è un accorgimento che viene utilizzato praticamente da tutti i manteiner in quanto spesso l’utente dimentica di scrivere il www o magari incolla male, cosi facendo non si rischia di “perdere la visita”

Un altra direttiva che nella mia zona non c’è, ma che ad esempio potete vedere nella prima figura, quella più in alto, è la direttiva CNAME.

Questo acronimo sta per Common NAME, ed è sostanzialmente un alias, ma a cosa serve?

Con una direttiva cname possiamo fare una sorta di redirect da un determinato record ad un altro; se per esempio nella mia zona io avessi impostato:

www1 IN CNAME www.logubuntu.it.
lol IN CNAME logubuntu.it.
pornotron IN CNAME www1.logubuntu.it.

avrei definito tre alias all’interno della mia zona che avrebbero funzionato cosi: digitando www1.logubuntu.it all’interno del browser, finirei lo stesso sul blog perchè sarei redirettato su www.logubuntu.it (infatti l’indirizzo sul browser cambierà con quest’ultimo) che a sua volta, secondo la direttiva A corrisponde all’ip del server.

Stessa cosa dicasi per lol.logubuntu.it e per pornotron.logubuntu.it, quest’ultima in particolare l’ho scritta in maniera più complicata per farvi rendere conto della flessibilità dei record di zona, in quanto se scrivessi pornotron al terzo livello del mio dominio, sarei redirettato su www1.logubuntu.it, ma www1 è a sua volta un cname di www.logubuntu.it, che a sua volta ancora corrisponde all’ip del server.

Questo è ovviamente un esempio, non esistono pazzi che mettono dei cname annidati all’interno della loro zona, altrimenti ci ritroveremmo rimbalzati in Nmila hostname fittizzi prima di arrivare al sito vero e proprio

Anche per la direttiva CNAME valgono le regole del ttl, del record @ (che non ho messo volutamente per non creare confusione con l’esempio della direttiva in A di prima, in quanto inserendo un @ IN CNAME ed un @ IN A viene invalidato il record in CNAME), e, fate attenzione, gli hostname devono finire con un punto, quindi come avrete già capito, la direttiva cname accetta in ingresso solo hostname completi e non indirizzi ip.

L’ultima direttiva che è bene conoscere, ma che non è fondamentale, è la direttiva TXT:

@ IN TXT “direttiva in A per la rete locale”

questa direttiva è a puro scopo descrittivo, qui i record @ ed IN vengono inseriti per rispettare la sintassi, in realtà si potrebbe scrivere anche solo IN TXT “record txt” la cosa non cambierebbe, ai fini della risoluzione ip non hanno alcun ruolo, possono tuttavia essere utili in zone abbastanza complesse, per aggiungere stringhe descrittive per migliorare la leggibilità del file di zona, l’unica regola da osservare è che il record descrittivo deve essere incluso tra apici ( ” ).

Bene questo è tutto quello che riguarda il file di zona a risoluzione diretta, ossia la risoluzione da nome host ad indirizzo ip, perchè nel mondo web esiste anche la risoluzione inversa ma questa la vedremo nella prossima puntata

Per adesso buonanotte a tutti coloro che hanno avuto il piacere di leggere questo articolo, e a domani.