Domain Name System (Alessandro Silvestrini)
Chiunque si affacci al mondo affascinante della grande rete si domandera', prima o poi, come possano essere indirizzati e specificati i computer all'interno della stessa. La semplice (e ormai quotidiana) operazione di digitare una URL nel nostro browser preferito comporta una serie di di messaggi tra vari computer, ed il risultato finale puo' sembrare banale fin tanto che non si prende atto dei protocolli nascosti ma indispensabili per un buon funzionamento della rete. Vedremo come un nome pu≥ essere convertito in un indirizzo IP (di rete) e viceversa.

I nternet Φ, come ben sappiamo, una grande rete di calcolatori collegati tra loro nei modi pi∙ vari che esistano nell'ambito delle LAN e delle WAN. Tutto ci≥ Φ possibile tramite l'uso intensivo del concetto di rete aperta e di livelli OSI. Internet usa il protocollo TCP/IP, che a sua volta si appoggia al livello fisico della rete sottostante, convertendo l'indirizzo fisico univoco della machina in un indirizzo IP, della forma XXX.YYY.ZZZ.KKK. In questo modo, ogni computer collegatoad Internet possiede un indirizzo IP, indipendentemente dalla rete a cui Φ allacciato. Ma cosa succederebbe se si dovesse ricordare per ogni computer il solo indirizzo IP ? Ripensate a tutti i collegamenti che ogni giorno fate con il vostro browser (o con altri applicativi di rete come telnet, ftp, etc.) ed immaginate di dovere ogni volta specificare come macchina destinazione un indirizzo IP come quello descritto sopra. E' facile intuire che la cosa diventerebbe velocemente poco pratica ed poco gestibile soprattutto da parte di quel pubblico che si Φ affacciato alla rete solo da pochi anni, e non ne conosce gli aspetti pi∙ tecnici. Ma immaginate anche una media azienda, che decide di installare una rete locale su base TCP/IP per facilitare una connessione esterna ad Internet, ma che quindi si troverebbe a chiamare il computer del capo contabile 135.12.34.1, quello del vicedirettore 135.12.34.13, etc. La soluzione a tutto ci≥ si ottiene creando un nuovo "livello di indirizzamento" che converta un indirizzo alfanumerico (la classica URL che inserite nel vostro bowser per "Navigare") nell'indirizzo IP. Questa operazione viene effettuata in maniera trasparente dal DNS (Domain Name System - Domain Name Server). Se ad esempio inserite nel vostro browser la URL omnios.dsi.unifi.it, esso contatterα via rete il DNS per chiedergli la conversione del nome in indirizzo IP. Il DNS risponderα al browser indicando che il nome comunicatogli corrisponde all'indirizzo IP 150.217.15.243. Il browser potrα quindi contattare la macchina omnios e stabilire la connessione.

Un po' di storia
La storia del DNS Φ un po' travagliata, a causa di una scelta inizialmente corretta, ma poco lungimirante e quindi rivelatasi insufficiente. Inizialmente il compito della fatidica conversione Nome > Indirizzo IP era stata delegata a macchine apposite, ognuna delle quali contenente una copia completa del DataBase dei nomi. Lo spazio dei nomi veniva perci≥ detto Piatto, in quanto ogni host di Internet rappresentava un entry nel DataBase al pari di tutti gli altri hosts. La situazione inizi≥ a diventare ingestibile non appena Internet inizi≥ ad allargarsi un po'. Tenere aggiornate tutte le copie del DataBase dei nomi (che tra l'altro iniziava a diventare grossino) costituiva un serio problema. Per questo motivo Φ stato deciso di dividere i compiti della conversione tra le varie macchine, in modo tale che ogni macchina gestisse un "sotto albero" dei nomi.

Un po' di teoria
La situazione teorica finale Φ stata quindi quella di gestire lo spazio dei nomi come un immenso albero. Ogni nodo dell'albero (tranne le foglie) costituisce un dominio, e deve garantire la conversione dei nomi a se sottostanti. Facciamo un piccolo esempio per chiarire meglio : supponiamo che la macchina sopracitata (omnios.dsi.unifi.it) richieda la conversione in indirizzo IP del nome telemat.die.unifi.it. Essa manderα la richiesta al DNS dsi, che a sua volta la passerα al DNS unifi. Esso la replicherα gi∙ al DNS die, che restituirα l'indirizzo IP della macchina Telemat, in esso registrata. Tutto questo avviene nella teoria. La pratica Φ ben diversa.

Un po' di pratica
Nella pratica un DNS pu≥ occuparsi tranquillamente di pi∙ domini, raggruppando dentro di se pi∙ livelli del teorico albero di nomi. Inoltre non Φ detto che il DNS di una o pi∙ reti / sottoreti stia fisicamente collegato a quella rete o sottorete. In effetti, un DNS del dominio inglese uk, si trova in America, al fine di evitare che le richieste americane di conversione di nomi di host inglesi attraversino l'oceano. Ma come Φ possibile tutto ci≥ ? semplicemente Φ possibile perchΘ il DNS nient'altro Φ che un DataBase in rete, e come tale pu≥ trovarsi qui o dall'altra parte del mondo, dando per scontato (ovviamente) di conoscere l'indirizzo IP del DNS stesso (se si conoscesse solo il nome sarebbe come il cane che si morde la coda). Essendo un DataBase, tra l'altro, Φ in grado anche di effettuare la conversione inversa, da indirizzo IP a nome o nomi dell'host corrispondente, fornendo anche informazioni sul tipo di macchina, di sistema operativo, etc. Il DNS si fonda su tre elementi chiave :

Il Local Resolver
Il Server di Nomi
I Resource Records
Local Resolver
Il local resolver nient'altro Φ che un piccolo programmino spesso richiamato da una API del sistema operativo. Questa API, inserita da un programmatore nel proprio codice, consente di interpellare il Server di Nomi e ricevere in dietro le informazioni richieste.

Il Server di Nomi
Il Server di Nomi Φ un programma (che gira su una particolare macchina della rete) che si mette in ascolto sulla porta 53 ed aspetta eventuali connessioni TCP o pacchetti UDP. Ricevuti i dati, elabora le richieste e rinvia al mittente la risposta. Il Server di nomi pu≥ a sua volta dialogare con altri Server di nomi, diventando a sua volta un Local Resover. Il Server di Nomi pu≥ cioΦ immagazzinare "risposte" (che poi in realtα sono Resource Record) in una cache, e restituirle in maniera non autoritaria, ovvero marcandole come non di sua competenza, ma praticamente attendibili.

I Resource Records
Un Resource Record (RR) Φ un'entitα base che un Server di Nomi scambia con un Local Resolver.




Un RR Φ composto da diversi campi che specificano il tipo di informazione contenuta, il tipo di rete, ed altre informazioni di gestione. I RR pi∙ importanti sono quelli che, dato un nome di un host, specificano l'indirizzo IP. Un tale RR apparirebbe in forma testuale come (ad esempio) :

es. ISI.EDU MX IN 10 VENERA.ISI.EDU

Che va letto cos∞ :
Il server di posta (MX) per il dominio ISI.EDI del sistema Internet (IN) ha Valore 10 e Nome VENERA.ISI.EDU.

Un alias (Un computer con due nomi) potrebbe essere invece codificato con due RR :

PIPPO.DIE.UNIFI.IT IN CNAME PLUTO.DIE.UNIFI.IT
PLUTO.DIE.UNIFI.IT IN A 150.17.8.24

I RR sono utilizzati sia dal Server per memorizzare i dati del dominio e per trasmetterli ai Local Resolver, sia dallo stesso Local Resolver, che li usa per inviare le richieste al Server.

Formato dei Messaggi
Il formato dei messaggi nel sistema DNS Φ abbastanza semplice : innanzitutto Φ opportuno specificare che i nomi di domino (es. telemat.die.unifi.it) vengono codificati label per label (telemat, die, unifi, it, NULL). Per ogni label viene specificata la lunghezza (1 byte) seguita dai caratteri stessi. Nelle figure dei messaggi quindi i campi dei nomi di dominio sono sempre rappresentati con dei trattini, a significare che la lunghezza di tali campi Φ variabile. Nello stesso messaggio scambiato dal Local Resolver al Server Φ presente (tra le altre cose) una sezione di domanda ed una sezione di risposta. Questo significa che il Server prende il messaggio ricevuto, analizza la sezione di domanda, e riempie la sezione di risposta, modificando per≥ anche l'header del messaggio stesso. Il formato del messaggio Φ rappresentato in figura, insieme ai formati dei RR delle sezioni di domanda e delle sezioni di risposta, autoritα, etc. Nelle query normali, il Server riempie solo la sezione di risposta, e marca il bit autoritario dell'header del messaggio. Pu≥ per≥ capitare per≥ che il Server possieda nella sua cache un RR proveniente da un altro Server. Allora il primo pu≥ rispondere in maniera non autoritaria, indicando nella sezione di autoritα il giusto Name Server a cui rivolgere la domanda per ottenere una risposta autoritaria.

Il formato del messaggio ad un DNS Φ composto da un header e da quattro sezioni di Domanda, Risposta, Autoritα, e Addizionale. Tutte contengono un certo numero di RR codificati in forma standard, tranne la prima sezione, che contiene dei RR particolari, leggermente diversi.






L'Header contiene alcune informazioni di stato, come un codice di operazione, un ID di operazione (il local resolover numera tutte le richieste per associare meglio le eventuali risposte), bit di Autorita', di Ricorsione, etc. Contiene anche il numero di RR contenuti nelle 4 rimanenti sezioni del messaggio.


Un RR di domanda contiene solo un nome di dominio, il tipo di richiesta (su quel nome) e la classe della richiesta. Quando inserite un nome nel vostro browser (es. Pippo), esso mandera' alcune richieste al DNS, con QName Pippo, Pippo.com, www.Pippo.com (maiuscole e minuscole). Le richieste avranno tutte QType = A (richiesta di indirizzo IP) e QClass = IN (Internet). (Ovviamente i valori A e IN sono codificati nelle rfc).



Un RR normale (come quelle che risiedono nelle ultime tre sezioni del messaggio) contiene qualche campo in piu' rispetto alle precedenti. Appaiono infatti i campi di TTL (Time to Leave) , ed il campo RData, che contiene l'informazione effettiva del RR. Un classico RR di risposta contiene in NAME il nome dell'host (es.www.Pippo.com) ed in RData l'indirizzo IP. Con queste poche pagine dovrebbe essere ormai chiaro come funziona (a grandi linee) un Server DNS. E' importante capire che esso implementa un data base distribuito, in cui la posizione dei nodi non segue in maniera esatta la struttura ideale dello spazio dei nomi. Ci sono molte altre regole che avvolgono lo scambio di messaggi fra le varie entita' (lunghezze massime, compressione, TTL e caching dei RR etc.) che non possono essere spiegate in questo piccolo spazio ma che si possono trovare nelle RFC 1033, 1034 e 1035.