Copyright © 1996, 1997 Università di Firenze. All rights reserved.

license available.

Domain Name System

La seconda funzione fondamentale del metodo dei nomi di dominio è quella di implementare un sistema distribuito efficiente, affidabile e di applicabilità generale per porre in corrispondenza i nomi di dominio con gli indirizzi IP corrispondenti. Il sistema si definisce distribuito perché la risoluzione di un nome di dominio avviene attraverso una collaborazione di più server dislocati in posti distinti. Vale infatti la regola generale che se un server DNS non conosce l'indirizzo IP di una certa macchina (ovvero dalla stringa del nome si accorge che non riguarda il suo dominio), passa la richiesta al server DNS di dominio superiore, o comunica come risposta l'indirizzo del DNS superiore. Efficiente perchè la risoluzione nella maggioranza dei casi avviene localmente senza incrementare ulteriormente il traffico in rete. La maggior parte delle volte (specialmente all'interno di grandi azienda) si interroga il DNS per conoscere l'indirizzo IP di altre macchine poste sempre all'interno dell'azienda. Con un sistema gerarchico tutte queste richieste non escono fuori dalla LAN della azienda, ma vengono gestite internamente. Affidabile perché l'interruzione, per cause accidentali, di un collegamento ad un server di risoluzione dei nomi non comporta l'interruzione del servizio: le richieste verranno dirottate su un altro server. Quasi sempre in tutte le macchine vengono infatti specificati due o più indirizzi di server DNS, e la macchina automaticamente interroga i server successivi al primo in caso di mancata risposta.
La risoluzione di un nome di dominio avviene grazie a dei programmi appositi chiamati server di nomi (Name Server), spesso situati su macchine apposite dette anch'esse server di nomi. Sulla macchina client gira un software detto risolutore di nomi (Local Resolver) che interroga uno o più server di nomi per convertire un nome di dominio in indirizzo IP.
Per capire come avvenga la risoluzione di un nome di dominio facciamo un esempio, seguendo come riferimento lo schema concettuale rappresentato nella Slide 6. Supponiamo che un host collegato al dominio dec.com (ad esempio Host1.dec.com) voglia scoprire l'indirizzo IP della macchina Host2.va.us. L'Host1 porrà la sua richiesta al DNS dec.com che analizzerà il nome dell'Host2. Il DNS di dec.com si renderà conto che la richiesta riguarda una macchina non appartenente al suo dominio, e passerà la richiesta al server .com. Anch'egli noterà che la macchina destinazione ha come ultima estensione .us e quindi scaricherà la richiesta al server di radice. Procedendo in questo modo la richiesta tornerà giù per i domini .us e va.us, dove incontrerà il server DNS va.us in grado di associare al nome Host2.va.us un indirizzo IP. A questo punto la risposta non ripercorrerà la stessa strada della domanda, ma tornerà direttamente al Host1.dec.com che entrerà a conoscenza dell'indirizzo IP richiesto (in realtà non è proprio così, ma prendiamolo momentaneamente per vero).

In realtà le connessioni di rete tra i vari server non sono esattamente come nella Slide 6 In altre parole la struttura nella Slide 6 non rappresenta fedelmente la struttura della rete: essa rappresenta soltanto i server di nomi che un server conosce e che quindi può contattare. Nella pratica la struttura è più complessa, i server possono essere dislocati nelle posizioni più impensabili. Spesso in un unico server ci sono più server di nomi capaci di risolvere più domini. La Slide 6 risulta semplicemente una semplificazione teorica. La Slide successiva mostra uno schema più realistico in cui un server contiene più server di nomi.

Questo tipo di organizzazione gerarchica ha pochi livelli. Il server radice contiene informazioni sui domini di massimo livello, ogni organizzazione, poi, impiega un singolo server per risolvere i nomi di dominio locali. Questo significa che la risoluzione di un nome, molto spesso impiega un solo livello dell'albero, riducendo il traffico in rete. Ad esempio per risolvere l'indirizzo xinu.cs.purdue.edu si contatteranno solo due server: quello radice e quello relativo al dominio purdue.edu. Ogni DNS, in pratica, dovrà gestire uno spazio di nomi non più composto ad un nodo singolo, ma da un sottoalbero dello spazio dei nomi complessivo.
Questa struttura semplificata opera correttamente, ma può diventare inefficiente per due motivi: il primo è dovuto alla centralità del nodo radice, cioè se dovesse rompersi il collegamento non saremmo in grado di risolvere il nome di dominio; oggiogiorno il server di radice è ricopiato su più macchine, al fine di garantire il servizio anche nel caso in cui una di esse dovesse venire a mancare. Il secondo motivo percui questa struttura perde in qualità è che il server radice (o i server di radice) ritorna ad essere centro di un elevato traffico.
Per questo secondo motivo internet implementa il name caching al fine di migliorarne l'efficienza. Ogni server di dominio mantiene in una memoria cache locale la lista dei nomi risolti recentemente; quando arriva una richiesta di risoluzione, controlla avanti nella chace, se è presente restituisce immediatamente l'indirizzo IP senza ulteriori passaggi, altrimenti interpella il server di livello superiore, il quale esegue le stesse operazioni. In questo modo si limita il flusso di dati verso il nodo radice. Le informazioni contenute nella cache di un server, hanno una durata di vita caratterizzata dal Time to Live, cioè dopo un tempo prestabilito vengono cancellate o aggiornate. Quando un server restituisce un indirizzo IP prelevato dalla cache locale lo contrassegna come un legame non autorevole e restituisce anche il nome del server da cui ha ottenuto tale indirizzo. In questo modo comunica al client che tale indirizzo potrebbe essere cambiato, ma gli fornisce anche l'indirizzo del server che conterrà l'informazione aggiornata. Un Server può però inviare anche informazioni autorvoli, il che significa che sono informazioni prelevate dal proprio spazio dei nomi.
È importante scollegare il nome di un certo dominio dalla posizione della macchina che ne implementa il DNS. A tutti gli effetti, il server di dominio di die.unifi.it (dominio di nomi del laboratorio di ing. elettronica di Firenze) "potrebbe" fisicamente trovarsi anche in Germania. Un server di nomi per il dominio .UK (inglese) stà in America, in modo tale che le richieste americane di risoluzione di un nome di dominio .UK non devono passare le limitate linee oceaniche.

Il DNS nient'altro è che un data base (consultabile in rete e distribuito) in grado di associare ad un nome un indirizzo IP e (a volte) viceversa.

Un'altra importante nota riguarda proprio quest'ultima affermazione: i DNS (come tutti i data base) non solo sono in grado di collegare un oggetto ad un altro, ma possono anche collegare un oggetto a molti, e molti ad uno. Al DNS in genere si richiede di elaborare un certo nome in modo da farsi rendere un indirizzo IP: è comunque possibile fare richieste più complesse, e ottenere come risposta un set di indirizzi IP ed eventuali alias di nomi. Questo perchè una stessa macchina può avere più nomi (ed un unico indirizzo IP), e più macchine (gemelle) possono avere lo stesso nome (ma differenti indirizzi IP).

Riassumendo, ogni sistema DNS è costituito da tre componenti principali :

Spazio del dominio dei nomi e Record di risorse :

     Lo spazio del dominio di nomi è una struttura ad albero in cui ogni nodo contiene delle informazioni, che sono salvate sotto forma di Resource Record. Sempre con i Resource Records è possibile fare delle query su questa struttura.

Server di Nomi

     Sono programmi che contengono informazioni su una piccola parte dello spazio del dominio dei nomi. Ogni Name Server è un'autorità per il suo spazio (le informazioni sono autorevoli), e possiede le informazioni su altri Name Server per poter accedere a tutto lo spazio di nomi.

Risolutori

     Sono programmi che estraggono l'informazione dai name server in risposta alle richieste dell'utente. I Risolutori devono poter accedere almeno ad un name server. L'informazione ottenuta dai name server può essere diretta o può essere l'indirizzo di un altro name server a cui avanzare la richiesta. Un Risolutore tipicamente è una routine di sistema che è direttamente accessibile dai programmi utente. Per questo motivo non è necessario nessun protocollo tra il Risolutore ed il programma utente.

Un nome di dominio identifica un nodo. Ogni nodo ha un set non ordinato di Resource Records, (eventualmente nessuno). Ogni Resource Record contiene i seguenti campi :

Possessore :

     Indica il nome di dominio che possiede questa RR

Tipo :

     E' un valore a 16 bit che specifica di che tipo di RR si tratta.
A = Indirizzo dell'host
CNAME = Nome canonico di un Alias
HINFO = Informazioni di CPU e OS
MX = Individua il Mail Exchenge del dominio
NS = Il Name Server Autorità del dominio
PTR = Un puntatore ad un altro Name Server
SOA = Identifica l'inizio di una zona di autorit\agrave



Classe :

     E' un valore a 16 bit che identifica la famiglia di protocolli o un particolare protocollo
IN = Sistema Internet
CH = Sistema Chaos




TTL :

     E' un valore intero a 32 bit (Time To Live) ed è usato dai Risolutori per "cachare" le RR

Rdata :

     E' il dato della RR, e dipende dal tipo e dalla classe.

 

Tipo del RR	Contenuto di Rdata
A	Indirizo IP a 32 bit (IN) o Chaos a 16 bit (CH)
CNAME	Nome di Dominio
MX	Valore a 16 bit e Nome dell'host server di Mail Exchange
PTR	Nome di un dominio
SOA	Diversi campi

Ogni Query può essere dei seguenti tipi :

Standard : Sono le classiche query, in cui si specifica un nome e si ottiene in cambio una serie di Resource Record che il DNS possiede

Reverse : Sono le query inverse, in cui si specifica un indirizzo IP e si vuole sapere il nome (o i nomi) del rispettivo host.

Il protocollo DNS prevede che avvenga uno scambio di Query tra Local Resolver e Name Server. Questo scambio di messaggi avviene sulla porta 53 (decimale) con servizio TCP o UDP, ed ha il vincolo che ogni Query non sia più lunga di 513 bytes. Ogni messaggio di Query scambiato è composto dalle sezioni raffigurate nella Slide 11. Più avanti analizzeremo in dettaglio ogni sezione, ma per adesso limitiamoci a fare un esempio di Query e risposta :

Il DNS sta rispondendo (bit RESPONSE settato) in maniera autoritaria (AA) : nella sezione di risposta si nota bene (sotto forma testuale), il Resource Record che associa al nome (PIPPO.DIE.UNIFI.IT) un indirizzo di Internet (IN) 150.17.8.25.

Moltri altri esempi possono essere trovati in fondo alla RFC 1034

Analizziamo più in dettaglio il formato dell'header del messaggio di Query. Ecco i vari campi di cui si compone :

La sezione di domanda è usata per trasportare la domanda nella maggior parte delle Query. Essa contiene un numero di entry come quelle riportate nella Slide 13 pari a DQCOUNT (vedi formato dell'header). In queste entry si ha i seguenti parametri :

Le tre sezioni che seguono la seziona di domanda sono tutte costituite nello modo : ogni sezione è un numero variabile (scritto nell'header) di Resource Record. Descrivendo la codifica di un Resource Record si conclude quindi la descrizione della sintassi dei messaggi che il Local Resolver ed il Server di Nomi si scambiano.

Nella Slide 14 viene presentato il formato di un Resource Record sulla rete. Le dimensioni sono quelle rappresentate nella stessa Slide. A questo punto dovrebbe essere chiaro il significato dei vari campi del Resource Record. Da notare che il campo RDATA ha dimensione variabile. La dimensione ed il tipo di informazioni vengono definite in base ai campi RDLENGTH, CLASS e TYPE. E' inutile specificare quì i vari formati di RDATA (per questo si rimanda allo standard sui messaggi dei DNS, RFC 1035).

• RFC 1033
• RFC 1034
• RFC 1035