Il Domain Name System

Transcript

1 Il Domain Name System Università di Parma - Appunti di Telematica A - per esclusivo uso interno A. Lazzari 2004 GENERALITÀ...1 LA GERARCHIA DEI NOMI DI DOMINIO...2 I RESOURCE RECORD (RR)...3 I PROTOCOLLI DEL DNS... 5 WINDOWS INTERNET NAMING SERVICE (WINS)... 8 Generalità Il Domain Name System (DNS) è un sistema di base dati distribuito e di protocolli associati che costituisce un insieme di informazioni relative a risorse di rete, quali indirizzi IP di host o di server di posta. Lo schema della base dati è un sistema di nomi simbolici che permettono di accedere a tali risorse. Questi nomi sono detti nomi di dominio (domain name), l'operazione di ricavare l'informazione dal nome viene indicata come risoluzione del nome. Storicamente la risoluzione di un nome serviva a ottenere l indirizzo IP di un host identificato mediante una stringa mnemonica, e veniva effettuata interrogando una tabella (contenuta nel file HOSTS sui sistemi Unix e poi anche Windows) che faceva corrispondere all identificativo mnemonico l indirizzo IP. Questa tabella, presente su ogni host, doveva essere aggiornata in seguito a qualsiasi variazione di rete, come l inserimento di un nuovo host. Chiaramente questo approccio era accettabile per reti di piccole dimensioni e inadatto a seguire la crescita di Internet. Nel 1984 venne introdotto il DNS. Possiamo pensarlo formato da tre tipi di componenti: Domain Name Space; Name Server; Resolver. Domain Name Space. Specifica la struttura ad albero dei nomi di dominio. È costituito dall'insieme di tutti i nomi esistenti. In tutta Internet ne esiste uno e ad esso appartengono tutti i nomi di dominio. Name Server. È un processo che contiene informazioni sullo spazio dei nomi. Un Name Server ha informazioni su alcune parti dello spazio dei nomi, queste parti vengono dette zone e il Name Server costituisce una AUTHORITY per tali zone; si dice anche che esso è un authoritative name server per tali zone. Le zone sono dei domini, ma non tutti i domini sono zone. Un name server contiene anche puntatori ad altri name server che possono essere usati per ricavare informazioni sulle altre zone. In un sistema Unix questo processo viene di solito chiamato named (name daemon) e basa il suo funzionamento sui parametri di un file di configurazione denominato named.boot. Una realizzazione molto diffusa di Name Server si chiama Berkeley Internet Name Domain (BIND). Il Domain Name System pag. 1

2 Resolver. Componente software che estrae informazioni dal Name Server. Tipicamente viene realizzato da routines del Sistema Operativo. Ad esempio quando si chiamano le "gethostbyname" e "gethostbyaddr" di Unix si accede al resolver. La gerarchia dei nomi di dominio Lo spazio dei nomi di dominio è organizzato ad albero. Ogni nodo e ogni foglia dell'albero hanno un nome (label), meno il nodo di radice (ROOT) che non ha nome (ha cioè una null label ). L albero viene rappresentato rovesciato, cioè con la radice in alto e le foglie in basso. Un dominio è quella parte dello spazio dei nomi che corrisponde a un nodo e a tutto ciò che sta sotto il nodo. Un nodo che dipende immediatamente da un altro nodo è un suo sottodominio, così il dominio it (Italia) ha come sottodomini i domini unimi (Università di Milano), cnr (CNR - Centro Nazionale delle Ricerche), unipr (Università di Parma) e altri ancora. Lo schema di Figura 1 mostra una parte del Domain Name Space. (ROOT) uk fr it edu gov mil org com polito unige unimi cnr unipr Firenze telecomitalia cedi eng habana speedy linus.. Figura 1 - Struttura generale del Domain Name Space Un nome di dominio rappresenta un dominio ed è formato da una concatenazione di label. I nomi sono letti da sinistra a destra, dal meno significativo al più significativo e le label vengono rappresentate separate dal carattere. (punto). Così cedi.unipr è un nome di dominio, dove cedi (Centro Didattico) è un sottodominio di unipr. Anche cedi.unipr.it, unipr, cedi sono nomi di dominio. Un nome che arriva fino alla radice è detto nome assoluto o fully qualified domain name (FQDN), così il nome assoluto del dominio cedi visto sopra è cedi.unipr.it.. Un dominio come it non è sottodominio di alcuno, ma dipende direttamente dalla radice. Si dice che it è un dominio di primo livello, o livello massimo (top level domain). Spesso un nome assoluto viene rappresentato senza il punto finale, come in cedi.unipr.it, ma in tal caso si rende la vita più difficile ai resolver che devono capire che it è un dominio di primo livello. Una label può comprendere caratteri alfanumerici e il carattere - (trattino), deve iniziare con una lettera e può avere un lunghezza massima di 63 caratteri. Lettere maiuscole e minuscole sono equivalenti. Una label è memorizzata come una stringa di byte (un carattere equivale a un byte), preceduta da un byte che dice quanto è lunga (e che quindi contiene un valore compreso fra 0 e pag. 2 Il Domain Name System

3 63); la radice è individuata da un byte di valore 0 a cui non segue alcun carattere. Il limite massimo per il nome è di 255 byte, compresi i byte di lunghezza e i byte dei caratteri. I domini di primo livello sono storicamente quelli delle diverse aree che partecipavano ad ARPAnet: edu per le Università americane, gov per gli enti governativi, mil per le organizzazioni militari, org per enti di tipo non-profit, com per le organizzazioni commerciali. In seguito si sono aggiunti i domini dei vari stati al di fuori degli USA, come it per l'italia o fr per la Francia, codificati con due lettere secondo la norma ISO 3166, nonché altre nuove categorie come ad esempio net per gli enti preposti alla gestione di Internet. Complessivamente sono stati registrati circa 170 domini di primo livello. In prima approssimazione si può dire che un dominio rappresenta un insieme di nodi di rete (cioè di apparati che possono essere host o router) e che a ognuno di essi è attribuito un nome di dominio di livello minimo (una foglia dell albero del Domain Name Space). Ad esempio il nome habana.cedi.unipr.it. è una foglia dell albero (non esistono sottodomini di habana) e corrisponde a una macchina inserita in rete (più precisamente un host). Bisogna però tener presente che questa regola è solo indicativa. In particolare: a) Un nodo di rete può non avere nome di dominio (quindi non è registrato nel DNS); b) Un nodo di rete può avere più di un nome. In tal caso uno di questi nomi è quello ufficiale ed è detto Canonical Name (CNAME), mentre gli altri sono detti alias. Ad esempio è un alias di habana.cedi.unipr.it. che è il nome ufficiale del nodo. Gli alias sono riconosciuti come tali dal DNS; c) Un nome di dominio di livello minimo potrebbe essere associato non a un nodo di rete, ma a un altra risorsa come ad esempio una porta di un router. In un caso come questo il singolo nodo di rete (ossia il router) potrebbe avere più nomi di dominio, indipendenti fra loro, che per il DNS sono dei nomi indipendenti e non degli alias. Nel caso più comune un nome di dominio di livello minimo è usato per indicare un host, questo host ha un unico indirizzo IP e la risoluzione del nome consiste nel ricavare l indirizzo IP dal nome. È questa l operazione che viene effettuata comunemente quando ad esempio si contattano siti Web come habana.cedi.unipr.it, o simili. I Resource Record (RR) Le informazioni contenute in un dominio sono memorizzate nei Name Server sotto forma di Resource Record (RR). Un RR comprende i seguenti campi: NAME TYPE Nome del proprietario (Owner), ossia il nome ( fully qualified ) del nodo a cui questo Resource Record appartiene; Codice di due byte che definisce il tipo del RR. I tipi più comuni sono: SOA (Start Of Authority) - indica l'inizio di una zona e contiene molte informazioni nel campo RDATA A (address): indirizzo IP di host (32 bit per la classe IN) Il Domain Name System pag. 3

4 NS (Name Server): un authoritative name server per il dominio MX (Mail Exchanger): una o più coppie costituite da: 1) un indice di preferenza di 16 bit (minore è meglio), 2) il nome di un server di posta. Specifica gli host che gestiscono la posta per il dominio PTR (Pointer): puntatore a un altra parte del Domain Name Space. Usato per effettuare risoluzione di nome inversa. CNAME (Canonical Name): un nome di dominio. Identifica il nome ufficiale di un alias. CLASS TTL Codice di due byte della classe. Solitamente vale IN, che significa: formato d'indirizzi IP (altri formati usati in passato erano ad esempio CS, per indicare gli indirizzi della rete Computer Science Network - CSNET); (Time To Live) Intero di quattro byte che specifica per quale durata massima si può tenere una copia del RR in una cache, prima di interrogare di nuovo il Name Server che possiede l informazione; RDLENGTH RDATA campo di due byte che specifica la lunghezza del campo successivo; campo di lunghezza variabile che descrive la risorsa. Qualche esempio di RR è riportato in Tabella 1. Name Type RDATA habana.cedi.unipr.it. A unipr.it. NS caio.cce.unipr.it. unipr.it. MX 10 caio.cce.unipr.it in-addr.arpa PTR habana.cedi.unipr.it. Tabella 1 - Esempi di Resource Record Il primo record di Tabella 1 è di tipo Address (A) e ci dice che l'indirizzo IP di habana.cedi.unipr.it. è Il secondo record (tipo NS) dice che un authoritative name server per il dominio unipr.it. è caio.cce.unipr.it. Il record successivo (tipo MX) dice che caio.cce.unipr.it. svolge anche le funzioni di mail exchanger per lo stesso dominio. In questo record è presente anche il valore 10 che indica il grado di preferenza per questo server. Se si trovassero altri mail exchanger per lo stesso dominio si dovrebbe dare la preferenza a quello col valore minore. L'ultimo record (tipo PTR) è strettamente associato al primo e serve ad effettuare una risoluzione inversa, ossia a ricavare un nome di dominio da un indirizzo IP. Per permettere ciò, quando si inserisce nel NS il record di tipo A si inserisce anche questo record di tipo PTR, da esso ricavato. Il campo NAME (che contiene sempre un nome di dominio fully qualified) viene costruito utilizzando i quattro campi dell'indirizzo IP (in notazione decimale) in ordine inverso (il primo a sinistra è il meno significativo) e aggiungendovi il top level domain convenzionale arpa, sotto cui c'è un sottodominio in-addr (indirizzi della classe Internet). pag. 4 Il Domain Name System

5 I protocolli del DNS Per interrogare il DNS un resolver deve accedere a un Name Server (NS). Tipicamente si usa il NS del dominio in cui si trova il resolver. L interrogazione avviene mandando una richiesta (query) per ottenere un certo record. Il caso più frequente si ha quando si vuole risolvere un nome (ossia ricavare un indirizzo IP); in tal caso la query sarà per un record di tipo A (address). Questa richiesta è inserita in un messaggio trasportato da un datagramma UDP; ad essa il NS risponde con un altro datagramma e la transazione è terminata. Naturalmente l informazione voluta potrebbe essere relativa a un dominio che non è di competenza del NS e non è detto che il NS la possieda. In tal caso si hanno due alternative: 1. Il resolver ha effettuato una query di tipo ricorsivo. Viene messa in atto la procedura di recurse : il NS ripete la richiesta a un altro NS e questo eventualmente ad altri ancora, fino a soddisfare la richiesta. All'host dell'utente finale basta conoscere l indirizzo del proprio NS. Si dice che si è effettuata una risoluzione ricorsiva. 2. Il resolver ha effettuato una query non ricorsiva. Il NS risponde negativamente alla query, inserendo nella risposta delle indicazioni utili per la risoluzione (ad esempio indicando il NS che ha autorità sul dominio richiesto). L'host dell'utente ripete la query a un nuovo NS; se riceve ancora risposta negativa ripete la query a un terzo NS e così via, fino a soddisfare la richiesta. Si dice che si è effettuata una risoluzione iterativa. Si noti che un NS intermedio può anche possedere informazioni relative a un dominio non di sua competenza, tipicamente perché ha già soddisfatto in precedenza la stessa richiesta e ha tenuto in memoria (cache) una copia della risposta. In questo caso il NS fornisce una risposta dichiarandola di tipo non authoritative. Si noti inoltre che durante una risoluzione ricorsiva un NS intermedio si comporta da resolver nei confronti del successivo NS. Può darsi che quest'ultimo rifiuti query ricorsive, dato che in genere i NS di livello gerarchico elevato tendono a limitare il carico di lavoro superfluo. In tal caso da un certo punto in avanti la procedura può diventare iterativa, ma l'utente finale non se ne accorge. I NS che servono un dominio dove si trovano gli host su cui corrono le applicazioni finali (in terminologia DNS essi costituiscono gli stub resolver) generalmente accettano sempre query ricorsive, anche perché spesso gli stub resolver si trovano in reti protette e non potrebbero accedere a NS esterni. La Figura 2 mostra lo schema generale di un messaggio scambiato fra client e server DNS (ossia fra resolver e NS). Il server aspetta sulla well known port 53. Ogni striscia orizzontale in figura rappresenta una coppia di ottetti (byte). Il messaggio comprende un header di 10 ottetti e un corpo di lunghezza variabile. Il Domain Name System pag. 5

6 1 = AUTHORITATIVE ANSWER 2 = SERVER STATUS 1 = RESPONSE 1 = IQUERY 1 = RECURSION AVAILABLE 0 = QUERY 0 = QUERY 1 = RECURSION DESIRED byte 1 byte 2 identificatore OPCODE RESPONSE CODE Numero di domande (di solito 1) HEADER Numero di RR di risposta Numero di RR di Authoritative Server Sezione questions Sezione answers 15 Figura 2 - Struttura di un messaggio DNS I primi 16 bit dell'header contengono un identificatore. Quando il resolver emette una richiesta le attribuisce un numero progressivo che il NS deve ripetere nella risposta in modo da identificarla correttamente (siamo in ambiente connectionless!). I successivi 16 bit sono suddivisi come segue: Un bit detto QR, se vale 0 il messaggio è una query, se vale 1 una risposta; Un codice di 4 bit detto OPCODE (Operation Code). Questo codice è utilizzato solo in un messaggio di richiesta e può valere: 0: si tratta di una richiesta normale (diretta - QUERY); 1: richiesta inversa (IQUERY); 2: richiesta di stato del server; 3-15: valori inutilizzati. Osserviamo che una IQUERY consiste nel ricavare un campo Name di un RR fornendo un campo RDATA. Se ad esempio si vuole sapere quale macchina ha l'indirizzo IP si può fare una query diretta chiedendo un RR di tipo PTR e fornendo il nome inaddr.arpa (vedi Tabella 1), oppure una IQUERY per un RR di tipo A fornendo il valore RDATA e chiedendo come risposta il nome. In questo secondo caso si chiederebbe al NS di svolgere un'operazione pag. 6 Il Domain Name System

7 più onerosa, che molti NS rifiutano di fare. Di norma si fanno solo query dirette e anzi esiste una proposta di abolire le IQUERY. Un bit detto AA (Authoritative Answer), usato nelle risposte. Se vale 1 il NS è authoritative; Un bit TC (Truncation), usato nelle risposte. Se vale 1 la risposta era troppo lunga per il canale di comunicazione (ad es. non stava tutta in un datagramma) ed è stata troncata; Un bit RD (Recursion Desired), usato nelle domande; Un bit RA (Recursion Available), usato nelle risposte; Un campo inutilizzato di 3 bit; Un codice di 4 bit detto RCODE (Response Code). Utilizzato nelle risposte, può valere: 0: tutto regolare; 1: errore di formato. Il NS non è riuscito a interpretare la domanda; 2: Server failure; 3: Name error. Questo codice può essere messo solo da un NS authoritative e significa che il nome di dominio richiesto non esiste; 4: Not implemented.. Il NS non supporta questa query; 5: Refused. Il NS si rifiuta di soddisfare questa richiesta per ragioni organizzative. Ad esempio si può ricevere questa risposta se si è richiesta una zone transfer; 6: - 15: valori inutilizzati. I successivi 16 bit contengono QDCOUNT: numero di richieste contenute nel corpo del messaggio. Normalmente questo numero (utilizzato solo nelle richieste) vale 1, ma è possibile accorpare più richieste in un unico messaggio. I successivi 16 bit (utilizzati solo nelle risposte) contengono ANCOUNT: numero di RR che seguono nel corpo del messaggio. Abbastanza comunemente una risposta può contenere più RR (ad esempio più MX). I successivi 16 bit (utilizzati solo nelle risposte) contengono NSCOUNT: numero di RR di tipo NS contenuti. Gli ultimi 16 bit dell'header contengono ARCOUNT (utilizzato solo nelle risposte), numero di RR addizionali. All'header segue una sezione questions che contiene la (o le) domanda, a cui il NS aggiunge una sezione answers con le risposte. Una domanda della sezione questions è costituita da un nome di dominio seguito da un valore type (ad esempio A se si chiede un indirizzo, MX per un server di posta ecc.). Una risposta della sezione answers è un RR. Il Domain Name System pag. 7

8 Ogni NS che ha autorità su un dominio è duplicato (a volte anche replicato più volte) per motivi di affidabilità; si ha così un Name Server Primario e un Name Server Secondario. I due devono essere periodicamente aggiornati in modo da contenere le stesse informazioni. Per fare ciò si devono trasferire in modo affidabile notevoli quantità di dati e un trasporto connectionless come quello usato nelle query fatte da uno stub resolver non è adatto. Per questa operazione si usa allora il trasporto TCP e di solito un NS è in ascolto sulla porta 53 TCP oltre che sulla porta 53 UDP. Windows Internet Naming Service (WINS) WINS provides dynamic NetBIOS name to IP address registration and resolution. This paper presents a functional description of the WINS server. Name registration and resolution processes are described as well as replication between WINS servers. The WINS database schema is documented. Finally, the paper discusses capacity planning and designing a WINS infrastructure. Nomi NetBIOS NetBIOS è un'interfaccia di programmazione di livello sessione (fornisce cioè dei servizi classificabili come servizi session OSI) nata sulle LAN Microsoft e quindi esportata in ambiente di intenetworking sulla pila TCP/IP. NetBIOS identifica le risorse di rete con nomi simbolici di 16 caratteri (non strutturati in una gerarchia come i domain name di Internet), che devono essere unici in una rete e sono allocati dinamicamente quando un computer è attivato o un utente si collega al sistema. La procedura di registrazione di un nome è basata su un messaggio di broadcast comunicato a tutta la rete dal nodo che vuole usare il nome. Se non si riceve alcuna obiezione si suppone che il nome sia utilizzabile e viene emessa una Name Overwrite Demand. A questo punto tutti sanno a chi appartiene il nome (e quindi la risoluzione è automatica). Questo sistema funziona bene su piccole LAN. Quando la rete cresce e soprattutto quando viene inserita in una internet, in cui normalmente i router non propagano i broadcast, il sistema diventa inutilizzabile. Una prima soluzione consiste nel file LMHOSTS in cui viene stabilita una corrispondenza fra indirizzi IP e nomi NetBIOS. I nodi che non possono rispondere ai broadcast utilizzano questo file per la risoluzione dei nomi NetBIOS. Oltre a questa funzionalità di base il file LMHOSTS serve tramite l'introduzione di alcune keyword -a validare i logon e a stabilire dei domini che comprendono più sottoreti. La maggior limitazione del file LMHOSTS è che è un file statico. Ogni variazione deve essere introdotta manualmente e replicata su tutti i nodi che usano questo file. Una gestione centralizzata, con distribuzione del file da un punto unico, semplifica l'amministrazione ma richiede comunque interventi manuali. Una gestione basata su LMHOSTS è praticamente impossibile in presenza di indirizzi IP dinamici. Il protocollo WINS, basato sul paradigma client/server, supera queste limitazioni permettendo la risoluzione dei nomi NetBIOS in una internet comunque complessa. La realizzazione di WINS nelle reti Microsoft è strettamente integrata col DNS. Questo permette a clienti non-wins di risolvere nomi NetBIOS facendo una query a un server DNS. pag. 8 Il Domain Name System