How to Domain Name Service
I DNS, acronimo di “Domain Name Service”, è uno dei servizi essenziali di Internet. Questo servizio ha il compito di gestire la risoluzione di nomi in indirizzi IP e l’inverso, possiamo quindi scrivere www.spremuta.com invece di 154.34.22.7.
Prima di addentrarci nel lato tecnico vediamo cosa e perché è stato inventato il servizio dei DNS.
Agli albori della rete, quando erano pochi i computer, la gestione dei nomi e degli indirizzi IP era affidata al file di nome “hosts” presente nelle macchine colllegate alla rete. Questo file è presente nella cartella /etc dei sistemi UNIX-like o in Windows sotto la cartella di sistema, in system32/drivers/etc (per dire due nomi noti 
).
Il file hosts è una semplice lista di indirizzi e nomi che vengono consultati localmente per risolvere i nomi e gli indirizzi.
Questo sistema non era possibile applicarlo ad una rete in grande espansione come internet, per questo fu creato il sistema DNS.
Esistono vari programmi che possono funzionare da server DNS, ma per i nostri esempi useremo BIND (Berkeley Internet Name Domain) 9..
Il dominio
Vediamo di far capire prima di tutto come è strutturato un dominio. La definizione di dominio e di DNS parte da questo frammento della RFC 819:
“La serie di domini forma una gerarchia. Usando una rappresentazione della teoria dei grafi può essere modellata come un grafo diretto (directed graph). Un grafo diretto consiste di una serie di nodi e di una collezione d’archi, in cui gli archi sono identificati da coppie ordinate (ordered pairs) di nodi distinti. Ogni nodo di un grafo rappresenta un dominio. Una coppia ordinata (B,A), un arco da B a A, indica che B è un sottodominio del dominio A e B è un nome semplice univoco nell’ambito di A.”
RFC 819, Anno di pubblicazione 1982, Autori Zaw-Sing Su e Jon Postel.
Per tradurlo da questo linguaggio comunque non immediato i DNS è un sistema la cui organizzazione è simile a quella di una piramide la cui punta si trova il dominio più importante, che è il “dominio radice/root domain”, il quale è indicato da un punto “.”. Al di sotto di questo punto si trovano i domini più elevati i “Top Level Domain” (TLD) come i ben noti com, it, de, org, net, info per citarne alcuni.
Sotto questi TLD esistono i dominio di secondo livello, come il nostro “spremuta” e ancora dopo potrebbero esserci altri nomi di sottodomini.
Quindi per ricapitolare “www.spremuta.it” è in verità scritto come “www.spremuta.it.” dove il punto alla fine “it.” è il “root domain”, “it” è il TLD seguito dal nome del dominio di secondo livello “spremuta” e in seguito dal nome della macchina “www”. Ovviamente poteva invece che il nome della macchina poteva esserci il nome di un altro sottodominio.
Meccanismo di ricerca
Quando digitiamo nel nostro browser Web preferito il nome di qualche sito, una delle prime operazioni che si scatenano dopo ever battuto invio è la risoluzione del nome del sito nel suo indirizzo IP.
Quindi il server DNS inizia prima di tutto a vedere se il dominio ricercato non si trovi nella cache se no inizia la vera e propria ricerca. Se il nostro server DNS non conosce perchè il sito non è presente nel suo database dei nomi come record o nella cache inizia a consultarsi con i DNS di livello superiore che si spera siano in possesso di informazioni maggiori.
Queste interrogazioni ad altri server DNS prendono nome di “query iterative”, chi risponde a questa query è un client DNS (chiamato anche DNS resolver) il quale invia a sua volta una “query ricorsiva”. La query ricorsiva una volta inviata ad un altro server DNS non generano un altra chiamata ad un altro server DNS ma esegue delle interrogazioni ricorsive per ottenere l’indirizzo.
Per intenderci meglio se vogliamo conoscere l’indirizzo IP di www.spremuta.it il nostro sistema di DNS opera nel caso non conosca nulla di nulla cosi:
Inizia a controllare se conosce “www.spremuta.it.”, si accorge che non conosce nella, allora chiede a qualcuno di livello superiore se conosce lui quell’indirizzo “www.spremuta.it.”, il quale inizia a procedere con le interrogazioni. Quindi procede ricorsivamente nella gerarchia dei domini, tradotto cerca prima il punto “.” poi “it” dopodiché “spremuta” e ancora dopo “www”.
Name Cache
Quando il server DNS funziona da Name Cache, esso funziona come cache per i nomi risolti recentemente. Questo alleggerisce il compito di alcuni server DNS, rendendo più veloce la navigazione.
Gerarchia dei Domini
Come abbiamo vista fino ad adesso la struttura dei DNS è una gerarchia dove ogni dominio gestisce solo se stesso e delega ad un altro server DNS le informazioni di eventuali sottodomini.
Cosi il DNS del dominio “com” conterrà solo riferimenti ai server DNS dei domini di secondo livello e non conterra le informazini contenute nei server DNS, come altri sottodomini del dominio e/o eventuali macchine.
Notare anche che per esempio un dominio di primo livello come “it.” delega l’autorità (l’autorità di gestire quel dominio, quindi quello che lui dice e vero e tutti gli altri cacciano palle proposito di quel dominio su cui ha autorità) per esempio di “spremuta.it” al server DNS di “spremuta.it”. Questo permette di alleggerire il carico di lavoro del DNS “it.”. Ovviamente “spremuta.it” una volta preso il controllo del dominio può delegare il controllo di altri sottodomini ad altri server DNS
Concetto di Start of Authority
Quando un server DNS è contrassegnato per un dominio nel suo database interno che per quel dominio è SOA (Start of Authority), significa quindi che lui gestisce quel dominio e quel dominio è di sua competenza.
Esempio zan.cnx
Un “dominio” quindi è un nome composto cosi: “nomedominio.nomeTLD.”, per esempio il dominio di www.spremuta.it è spremuta.it.
Proseguiremo quindi alla generazione del dominio di esempio zan.cnx. Nel mio caso specifico per installare bind eseguo il comando:
$ emerge bind bind-tools
Quindi proseguo con la sua configurazione. Quello che segue è il contenuto del file /etc/bind/named.conf che configura alcune impostazioni del dominio “localhost”.
zone "0.0.127.in-addr.arpa" {
type master;
file "0.0.127.in-addr.arpa.zone";
};
zone "localhost" {
type master;
file "localhost.zone";
};
La versione che troverete in /etc/bind/named.conf è diversa come credo anche nelle altre distro ma la perte di codice vitale per definire il dominio localhost e la sua risoluzione dell’indirizzo 127.0.0.1 è quella di sopra.
E’ interessante notare che il DNS salva gli indirizzi IP al inverso e solo i primi 3 ottetti.
Io voglio creare il dominio zan.cnx la cui macchina all’indirizzo IP 172.22.0.65 risponda al nome di “ns” (ns: NameServer ) e funziona da DNS per il dominio, ovviamente stiamo lavorando sulla macchina 172.22.0.65 della rete 172.22.0.0/24. Quindi aggiungiamo le informazioni seguenti nel file named.conf.
zone "0.22.172.in-addr.arpa" {
type master;
file "0.22.172.in-addr.arpa.zone";
};
zone "zan.cnx" {
type master;
file "zan.cnx.zone";
};
Dalla prima riga possiamo capire che risolve gli indirizzi 172.22.0.0/24, dalla seconda apprendiamo che è master, quindi il DNS risolve quegli indirizzi. Nella seconda riga vediamo un indicazione sul tipo di zona che stiamo definendo, nel nostro caso “type master” stiamo informando che per questa zona il nostro server è Master, tradotto e lui che gestisce questo dominio. Nella terza riga abbiamo un indicazione di come si chiama il file contenente maggiori informazioni sulla zona.
Vediamo il contenuto del file “0.22.172.in-addr.arpa.zone”:
$TTL 86400
@ IN SOA ns.zan.cnx. root.ns.zan.cnx. (
3
28800
7200
604800
86400
)
@ IN NS ns.zan.cnx.
65 IN PTR ns.zan.cnx.
Nella prima riga troviamo $TTL 86400, che indica il periodo di vita di questa dichiarazione, (TTL Time To Live) di 86400 secondi (3 giorni). Nella seconda riga troviamo @, che significa se stesso in parole semplici.
SOA significa Start of Authority che indica che da qui il server DNS prende l’autorita per rispondere, segue poi la dichiarazione della macchina che fa da Name Server, nel nostro caso si tratta di ns.zan.cnx. (quindi 172.22.0.65).
Molto spesso i server DNS non gestiscono altro servizio oltre a quello di DNS, poichè quest’ultimo è vitale ed un suo offline di poco tempo può provocare l’inraggiungibilita del dominio per molto tempo.
Segue poi la mail del amministratore di rete “root.ns.zan.cnx.”, che viene tradotta (viene sostituito il primo punto con @) in root@ns.zan.cnx. Seguono poi tra le parentesi questi valori:
3 ; Serial
28800 ; Refresh
7200 ; Retry
604800 ; Expire
86400 ; Minimum TTL
Questi valori influenzano le impostazioni di vario tipo per la zona ( il ; seguito dal testo è il comento in questo file).
La prima riga con il valore 3 (nel nostro caso) indica il “Numero di Serie”, questo valore indica che versione delle informazioni del DNS. Quindi è un valore che noi incrementiamo quando eseguiamo delle modifiche per informare che i server secondari si devono aggiornare con le nuove informazioni.
La seconda riga indica la frequenza con cui un server DNS secondario debba controllare i dati presenti sul server primario.
L terza riga indica il tempo che deve trascorrere tra i tentativi di connessione del server secondari nel caso la connessione non avvenga.
La quarta riga indica qaunto tempo deve passare dopo il quale il server secondario deve smettere di provare a contattare il server DNS primario per aggiornarsi.
L’ultimo campo indica quanto le informazioni possono rimanere in cache negli altri server DNS.
AGGIUNGERE DEF: DNS SECONDARI e DNS PRIMARI.
Dopo queste parentesi contenenti informazioni sul tempo di validita delle informazioni stesse segue la parte cruciale del DNS, la parte che indica a quali nomi nel dominio corrispondono quali indirizzi IP. La prima riga di questa parte è:
@ IN NS ns.zan.cnx.
Inizia con una @ (non obbligatoria), che indica se stesso il se stesso viene poi assegnato tramite NS alla funzione di Name Server al nome della macchina ns.zan.cnx. (ricordarsi il punto alla fine). Segue poi anche la risoluzione inversa del indirizzo 172.22.0.65 che corrisponde alla macchina server (è il server stesso). Adesso analizziamo la risoluzione diretta da nome a indirizzo IP, indicata dalla porzione del file di /etc/bind/named.conf:
zone "zan.cnx" {
type master;
file "zan.cnx.zone";
};
Come gia detto la spiegazione rispetto alla risoluzione inversa non si distanziano da questa e avendo capito la precedente zona è facile capire anche essa, quindi passiamo al suo file “zan.cnx.zone”
$TTL 86400
@ IN SOA ns.zan.cnx. root.ns.zan.cnx. (
3
28800
7200
604800
86400
)
@ IN NS ns.zan.cnx.
ns.zan.cnx. IN A 172.22.0.65
Come vedete per la maggior parte il codice è simile a quello precedente. Nell’ultima riga si trova il comando che indica al server DNS che il nome ns.zan.cnx. corrisponde all’idirizzo 172.22.0.65.
Con questo concludo il mio breve scrocio sui DNS.
Bibliografia & Sitografia
- http://it.tldp.org/HOWTO/DNS-HOWTO.html
- TCP/IP Tutto&Otre edit. SAMS/APOGEO Autori Karanjit S. Siyan, Tim Parker
- Red Hat LINUX 7 Tutto&Oltre edit. SAMS/APOGEOA Autori David Pitts, Bill Ball