Protocolli di rete

Bibliografia:
Computer Networking. Cap. 3. Autori: James F. Kurose (University of Massachusetts, Amherst) Keith W. Ross (Polytechnic Institute of NYU).

Domain Name Server: DNS

DNS - Il servizio Directory di Internet

Esistono molti modi per risalire all'identità di una persona: con il nome che compare sul certificato di nascita, con il codice fiscale, con il numero della patente di guida. Ogni informazione di identificazione, in un dato contesto può essere più appropriata di un altra. Ad esempio, i computer presso l'agenzia delle entrate utilizzano il codice fiscale, piuttosto che il nome. D'altra parte, la gente preferisce usare il nome per riferirsi ad una persona, perchè lo ricorda più facilmente di un numero.

Proprio come gli esseri umani possono essere identificati in molti modi, possono farlo anche gli host su Internet. Un identificatore per un host è il nome dell'host. Nomi host come cnn.com, www.yahoo.com, frapec.edu e cis.poly.edu sono mnemonici e pertanto sono apprezzati dagli esseri umani. Tuttavia i nomi di host forniscono poche informazioni sulla posizione dell'host all'interno di Internet. (Un hostname come www.euro.fr, che termina con il codice del paese Fr, dice che l'host è probabilmente in Francia, ma non dice molto di più). Inoltre, poichè i nomi degli host possono essere costituiti da caratteri alfanumerici di lunghezza variabile, sarebbero difficili da trattare dai router. Per queste ragioni, gli host sono identificati dai cosiddetti indirizzi IP.

Un indirizzo IP consiste di quattro byte e ha una struttura gerarchica rigida. Un indirizzo IP assomiglia a 121.7.106.83, dove ogni punto separa uno dei byte espressi in notazione decimale da 0 a 255. L'indirizzo IP è gerarchico, perchè mentre si scandisce da sinistra a destra, si ottengono informazioni più specifiche su dove si trova l'host in Internet (cioè, entro quale rete). Allo stesso modo, la scansione di un indirizzo postale dal basso verso l'alto, consente di ottenere informazioni più specifiche su dove si trova il destinatario.

Servizi forniti dal DNS

Abbiamo appena visto che ci sono due modi per identificare un host: per nome e per indirizzo IP. La gente preferisce l'identificatore di host più mnemonico, mentre i router preferiscono gli indirizzi IP di lunghezza fissa, gerarchicamente strutturati. Per conciliare queste preferenze, serve un servizio di directory che traduca i nomi host in indirizzi IP. Questo è il compito principale del sistema dei nomi di dominio di Internet (DNS). Il DNS è (1) un database distribuito implementato in una gerarchia di server DNS, e (2) un protocollo del livello di applicazione che consente agli host di interrogare il database distribuito. Il protocollo DNS è eseguito su UDP e utilizza la porta 53.

DNS è comunemente impiegato da altri protocolli del livello applicazione - tra cui HTTP, SMTP e FTP - con il compito di tradurre i nomi degli host forniti dall'utente in indirizzi IP. Come esempio, si consideri cosa succede quando un browser (cioè, un client HTTP), in esecuzione sull'host di qualche utente, richiede l'URL index.html presso il dominio www.scuola.edu/. Affinchè l'host dell'utente sia in grado di inviare un messaggio di richiesta HTTP al server Web, l'host dell'utente deve prima ottenere l'indirizzo IP di www.scuola.edu. Questo viene fatto come segue:

1. Sulla macchina utente si gestisce il lato client dell'applicazione DNS.

2. Il browser estrae il nome host, www.scuola.edu, dall'URL e passa il nome host al lato client dell'applicazione DNS.

3. Il client DNS invia una interrogazione contenente l'hostname ad server DNS.

4. Il client DNS riceve una risposta, che contiene l'indirizzo IP corrispondente all'hostname.

5. Una volta che il browser riceve l'indirizzo IP dal DNS, può aprire una connessione TCP con il processo server HTTP in ascolto sulla porta 80 a quell'indirizzo IP.

Da questo esempio si vede che il DNS aggiunge un ulteriore ritardo per le applicazioni Internet che lo utilizzano. Fortunatamente, come si vedrà di seguito, l'indirizzo IP desiderato è spesso memorizzato nella cache in un server DNS "vicino", che aiuta a ridurre il traffico di rete e il ritardo medio di risposta del DNS.

DNS fornisce alcuni altri importanti servizi, oltre a tradurre nomi di host in indirizzi IP:

• Host aliasing. Un host con un nome complicato può avere uno o più nomi alternativi. Ad esempio, un hostname come relay1.west-coast.enterprise.com potrebbe avere, ad esempio, due alias come enterprise.com e www.enterprise.com. In questo caso, il nome del computer relay1.westcoast.enterprise.com si dice che è un hostname canonico. I nomi di host alternativi, quando presenti, sono in genere più mnemonici dei nomi host canonici. Il servizio DNS può essere richiamato da un'applicazione per ottenere l'hostname canonico per un nome alternativo fornito, così come l'indirizzo IP dell'host.

• Mail server aliasing. Per ovvie ragioni, è altamente auspicabile che gli indirizzi di posta elettronica siano mnemonici. Ad esempio, se Bob ha un account con Hotmail, l'indirizzo e-mail di Bob potrebbe essere semplice come bob@hotmail.com. Tuttavia, il nome host del server di posta elettronica Hotmail è più complicato e meno mnemonico che semplicemente hotmail.com (per esempio, il nome host canonico potrebbe essere qualcosa di simile a relay1.west-coast.hotmail.com). Il DNS può essere richiamato da un applicazione di posta elettronica per ottenere l'hostname canonico per un hostname alternativo fornito, così come l'indirizzo IP dell'host. Infatti, il record MX (vedi sotto) permette al server mail di una società e ai server Web di avere hostname identici (alias); per esempio, il server Web e il server di posta di una società possono essere chiamati entrambi enterprise.com.

• Load distribution. Il DNS è utilizzato anche per distribuire il carico tra i server replicati, quali i server Web replicati. I Siti occupati, come cnn.com, vengono replicati su più server, con ogni server in esecuzione su un sistema terminale diverso e ciascuno con un indirizzo IP diverso. Per i server Web replicati, un insieme di indirizzi IP viene associato ad un nome host canonico. Il database DNS contiene questa serie di indirizzi IP. Quando i client interrogano il DNS per un nome corrispondente ad un insieme di indirizzi, il server risponde con l'intero insieme di indirizzi IP, ma ruota l'ordine degli indirizzi all'interno di ciascuna risposta. Poichè un client invia tipicamente il suo messaggio di richiesta HTTP all'indirizzo IP che viene nominato per primo nell'insieme, la rotazione DNS distribuisce il traffico tra i server replicati. La rotazione del DNS è utilizzata anche per la posta elettronica in modo che più server di posta elettronica possano avere lo stesso nome alternativo.

Panoramica del DNS

Adesso si presenta una panoramica del funzionamento del DNS. La discussione si concentrerà sui servizi di traduzione da hostname a indirizzo IP.

Si supponga che alcune applicazioni (come un browser Web o un lettore di posta) in esecuzione su un computer di un utente abbia bisogno di tradurre un nome host in un indirizzo IP. L'applicazione richiama il lato client del DNS, specificando il nome host che deve essere tradotto. (Su molte macchine basate su UNIX, l'applicazione richiama la funzione gethostbyname()). Il DNS host dell'utente si assume poi, l'incarico di inviare un messaggio di interrogazione in rete. Tutte le query DNS e i messaggi di risposta vengono inviati in altri pacchetti UDP sulla porta 53. Dopo un ritardo, che varia da pochi millisecondi a qualche secondo, il DNS dell'utente riceve un messaggio di risposta DNS che fornisce la corrispondenza desiderata. Questa corrispondenza è poi passata all'applicazione chiamante. Così, dal punto di vista dell'applicazione chiamante sull'host dell'utente, il DNS è una scatola nera che fornisce un servizio di traduzione semplice e diretto. Ma in realtà, la scatola nera che implementa il servizio è complessa, costituita da un gran numero di server DNS distribuiti in tutto il mondo, nonchè da un protocollo del livello di applicazione che specifica come comunicano i server DNS e gli host che emettono l'interrogazione.

Un semplice progetto per il DNS consisterebbe di un server DNS che contiene tutte le associazioni "Nome Host - Indirizzo IP". In questa struttura centralizzata, i client semplicemente indirizzano tutte le query al server DNS singolo, e il server DNS risponde direttamente ai client che lo interrogano. Nonostante questo progetto sia semplice ed attraente, non è appropriato per Internet attuale, con il suo vasto (e crescente) numero di host. I problemi con un design centralizzato includono:

• Un singolo punto di guasto. Se il server DNS si guasta, l'intera rete Internet sarebbe inutilizzabile!

• Volume di Traffico. Un singolo server DNS dovrebbe gestire tutte le query DNS (per tutte le richieste HTTP e per tutti i messaggi di posta elettronica generati da centinaia di milioni di host).

• Database centralizzato a distanza. Un singolo server DNS non può essere "vicino a" tutti i client di interrogazione. Se si mette il server DNS solo a New York, poi tutte le domande provenienti dall'Australia devono viaggiare dall'altra parte del globo, forse su collegamenti lenti e congestionati. Questo può portare a ritardi significativi.

• Manutenzione. Il singolo server DNS dovrebbe tenere una tabella per tutti gli host di Internet. Non solo questo database centralizzato sarebbe enorme, ma dovrebbe essere aggiornato frequentemente per tenere conto di ogni nuovo host.

In sintesi, un database centralizzato in un solo server DNS non si adatta alle esigenze della rete. Di conseguenza, il DNS è distribuito. Il DNS è un esempio di come un database distribuito può essere implementato in Internet.

Un Database Gerarchico Distribuito

Per affrontare il problema dell'adattamento alle variazioni della rete, il DNS utilizza un gran numero di server, organizzato in modo gerarchico e distribuito in tutto il mondo. Nessun server DNS ha tutte le corrispondenze per tutti gli host in Internet. Invece, le associazioni nome-indirizzo sono distribuite tra i server DNS. In prima approssimazione, ci sono tre classi di server DNS: server DNS root, server DNS di dominio di primo livello (TLD) e i server DNS autoritari. Questi sono organizzati in una gerarchia, come mostrato in Figura.

Per capire come queste tre classi di server interagiscono, si supponga che un client DNS voglia determinare l'indirizzo IP del nome host www.amazon.com. In prima approssimazione, si svolgeranno i seguenti eventi. Il client prima contatta uno dei root server, che restituisce gli indirizzi IP dei server TLD per il dominio di primo livello com. Il client poi contatta uno di questi server TLD, che restituisce l'indirizzo IP di un server autoritario per amazon.com. Infine, il client contatta uno dei server autoritari per amazon.com, che restituisce l'indirizzo IP per il nome host www.amazon.com. In seguito verrà esaminato questo processo di ricerca DNS in modo più dettagliato, ma adesso si vuole riepilogare il ruolo di queste tre classi di server DNS:

• Root DNS server. In Internet ci sono 13 server DNS (etichettati da A a M), la maggior parte dei quali si trovano in Nord America. un elenco degli attuali server DNS è disponibile tramite [root-server 2012]. Anche se ciascuno dei 13 server radice DNS viene immaginato come se fosse l'unico server, ogni "server" è in realtà una rete di server replicati, per motivi di sicurezza e affidabilità. In totale, ci sono 247 server principali a partire dal 2011.

• Top-level domain (TLD) server. Questi server sono responsabili per i domini di primo livello come com, org, net, edu, gov e tutti i domini di primo livello dei nomi dei paesi, quali uk, fr, ca e jp. La società Verisign Globale Registry Services mantiene i server TLD per il dominio com di primo livello, e la società Educause mantiene i server TLD per il dominio di primo livello edu. Vedere [IANA TLD 2012] per un elenco di tutti i domini di primo livello.

• Authoritative DNS server. Ogni organizzazione con gli host accessibili al pubblico (ad esempio server Web e server di posta) su Internet deve fornire i record DNS accessibili pubblicamente che mappano i nomi di tali host in indirizzi IP. Server DNS di fiducia di un'organizzazione ospitano questi record DNS. Un'organizzazione può scegliere di eseguire il proprio server DNS di fiducia per tenere questi record; in alternativa, l'organizzazione può pagare per avere questi record archiviati in un server DNS di qualche fornitore di servizi. La maggior parte delle università e grandi aziende implementano e mantengono i propri server DNS primario e secondario (backup).

I server DNS radice, TLD, e di autorità appartengono tutti alla gerarchia di server DNS, come mostrato nella Figura. C'è un altro importante tipo di server DNS denominato server DNS locale. Un server DNS locale non appartiene strettamente alla gerarchia dei server, ma è comunque fondamentale per l'architettura DNS. Ogni ISP - come un'università, un dipartimento accademico, aziendale o di un ISP residenziale, dispone di un server DNS locale (chiamato anche un server di nomi di default). Quando un host si connette a un ISP, l'ISP fornisce l'host con gli indirizzi IP di uno o più dei suoi server DNS locali (tipicamente tramite DHCP). Si può facilmente determinare l'indirizzo IP del server DNS locale accedendo al pannello delle connessioni di rete in Windows o UNIX. Il Server DNS locale di un host è tipicamente "vicino a" l'host. Per un ISP istituzionale, il server DNS locale può essere sulla stessa LAN dell'host; un ISP residenziale è separato dall'host da qualche router. Quando un host effettua una query DNS, la query viene inviata al server DNS locale, che funge da proxy, inoltra la query in una gerarchia di server DNS, come si vedrà in dettaglio più avanti.

A - interazioni tra i server DNS		B - Query Ricorsive

Si propone questo semplice esempio: si supponga che l'host cis.poly.edu vuole l'indirizzo IP di gaia.cs.umass.edu. Si supponga anche che il server DNS locale del Politecnico si chiama dns.poly.edu e che il nome di un server DNS di autorità per gaia.cs.umass.edu sia dns.umass.edu. Come mostrato in Figura A, l'host cis.poly.edu invia prima un messaggio di query DNS al server DNS locale, dns.poly.edu. Il messaggio di query contiene il nome host da tradurre, cioè gaia.cs.umass.edu. Il server DNS locale inoltra il messaggio contenente la query a un server DNS principale. Il server radice DNS prende atto del suffisso edu e restituisce al server DNS locale un elenco di indirizzi IP per i server TLD responsabili di edu. Il server DNS locale quindi invia nuovamente il messaggio di richiesta ad uno di questi server TLD. Il server TLD prende atto del suffisso umass.edu e risponde con l'indirizzo IP del server DNS autorevole per l'Università del Massachusetts, vale a dire dns.umass.edu. Infine, il server DNS locale invia nuovamente il messaggio di query direttamente a dns.umass.edu, che risponde con l'indirizzo IP di gaia.cs.umass.edu. Si noti che in questo esempio, al fine di ottenere l'indirizzo corrispondente ad un hostname, sono stati inviati otto messaggi DNS: quattro messaggi di query e quattro messaggi di risposta! Si vedrà come il caching DNS riesce a ridurre questo traffico di query.

L'esempio precedente assume che il server TLD conosce il nome host del server DNS autorevole. In generale questo non è sempre vero. Al contrario, il server TLD può conoscere solo il nome di un server DNS intermedio, che a sua volta conosce il nome host del server DNS autorevole. Ad esempio, si supponga ancora che l'Università del Massachusetts abbia un server DNS per l'università, chiamato dns.umass.edu. Si supponga, inoltre, che ciascuno dei dipartimenti presso l'Università del Massachusetts abbia il proprio server DNS, e che ogni server DNS dipartimentale è autorevole per tutti gli host nel reparto. In questo caso, quando il server DNS intermedio, dns.umass.edu, riceve una query per un host con un hostname che termina con cs.umass.edu, ritorna all'host dns.poly.edu l'indirizzo IP dell'host dns.cs.umass.edu, che è autorevole per tutti gli hostname che terminano con cs.umass.edu. Il server DNS locale dns.poly.edu poi invia la query al server DNS autorevole, che restituisce la corrispondenza desiderata al server DNS locale, che a sua volta restituisce la corrispondenza all'host richiedente. In questo caso, vengono inviati un totale di 10 messaggi DNS!

L'esempio mostrato nella Figura A fa uso di entrambe le query ricorsive e iterative. La query inviata da cis.poly.edu a dns.poly.edu è una query ricorsiva, poichè l'interrogazione chiede a dns.poly.edu di avere la mappatura di sé stessa. Ma le successive tre query sono iterative in quanto tutte le risposte sono direttamente restituite a dns.poly.edu. In teoria, ogni query DNS può essere iterativa o ricorsiva. Ad esempio, la Figura B mostra una catena di query DNS per cui tutte le query sono ricorsive. In pratica, le query di solito seguono il modello in Figura A: La query dall'host richiedente per il server DNS locale è ricorsiva, e le restanti domande sono iterative.

DNS Caching

Finora si è ignorata la presenza della cache DNS, una caratteristica estremamente importante del sistema DNS. In verità, il DNS sfrutta ampiamente il caching per migliorare le prestazioni in termini di ritardo e allo scopo di ridurre il numero di messaggi DNS scambiati su Internet. L'idea alla base del caching DNS è molto semplice. In una catena di query, quando un server DNS riceve una risposta DNS (contenente, ad esempio, una corrispondenza da un nome host a un indirizzo IP), può memorizzare nella cache locale la corrispondenza. Per esempio, nella Figura A, ogni volta che il server DNS locale dns.poly.edu riceve una risposta da qualche server DNS, può memorizzare nella cache qualsiasi informazione contenuta nella risposta. Se una coppia hostname/indirizzo IP viene memorizzata nella cache di un server DNS e arriva un'altra query al server DNS per lo stesso nome host, il server DNS può fornire l'indirizzo IP desiderato, anche se non è autorevole per il nome host. Poichè l'associazione tra nomi host e indirizzi IP non sono permanenti, i server DNS scartano le informazioni memorizzate nella cache dopo un determinato periodo di tempo.

Come esempio, si supponga che l'host apricot.poly.edu interroghi dns.poly.edu per l'indirizzo IP del nome host cnn.com. Inoltre, si supponga che poche ore più tardi, un altro host dell'Università, per esempio, kiwi.poly.fr, interroga ancora dns.poly.edu con lo stesso nome host. Grazie al caching, il server DNS locale sarà in grado di restituire immediatamente l'indirizzo IP del cnn.com a questo secondo host richiedente, senza dover interrogare altri server DNS. Un server DNS locale può anche memorizzare nella cache gli indirizzi IP dei server TLD, consentendo in tal modo al server DNS locale di bypassare i server DNS in una catena di query.

Record e Messaggi DNS

I server DNS che insieme implementano il database DNS distribuito, memorizzano record di risorse (RR), compreso quelli che forniscono la corrispondenza da hostname a indirizzo IP. Ogni messaggio di risposta DNS trasporta uno o più record di risorse. In questo e nel prossimo paragrafo, viene fornita una breve panoramica dei record di risorse DNS e dei messaggi.

Un record di risorsa è un tupla che contiene i seguenti campi:

(Nome, Valore, Tipo, TTL)

TTL è il tempo di vita del record di risorse; determina quando una risorsa deve essere rimossa da una cache. Nei record di esempio riportati di seguito, si ignorerà il campo TTL. Il significato dei campi "Nome" e del campo "Valore" dipende dal campo "Tipo":

• Se Tipo = A, allora Nome è un nome host e Valore è l'indirizzo IP di quell'host. Così, un record Tipo A fornisce la corrispondenza standard hostname-IP. A titolo di esempio, (relay1.bar.foo.com, 145.37.93.126, A) è un record di tipo A.

• Se Tipo = NS, allora Nome è un dominio (ad esempio foo.com) e Valore è l'hostname di un server DNS autorevole che sa come ottenere gli indirizzi IP per gli host nel dominio. Questo record è utilizzato per inoltrare le query DNS nella catena di query. Ad esempio, (foo.com, dns.foo.com, NS) è un record di tipo NS.

• Se Tipo = CNAME, allora il Valore è un nome host canonico per il nome alternativo (alias) hostname. Questo record può fornire agli host il nome canonico per un ottenere l'hostname. A titolo di esempio, (foo.com, relay1.bar.foo.com, CNAME) è un record di tipo CNAME.

• Se Tipo = MX, allora il Valore è il nome canonico di un server di posta che ha un alias Nome. A titolo di esempio, (foo.com, mail.bar.foo.com, MX) è un record MX. I Record MX consentono ai nomi host del server di posta elettronica di avere alias semplici. Si noti che utilizzando il record MX, una società può avere lo stesso nome alias per il server di posta e per uno dei suoi altri server (come ad esempio il proprio server Web). Per ottenere il nome canonico per il server di posta elettronica, un client DNS potrebbe interrogare per un record MX; per ottenere il nome canonico per l'altro server, il client DNS interroga per il record CNAME.

Se un server DNS è autorevole per un particolare hostname, allora il server DNS contiene un record Tipo A per il nome host. (Anche se il server DNS non è autorevole, può contenere un record Tipo A nella sua cache.) Se un server non è autorevole per un hostname, allora il server contiene un record di tipo NS per il dominio che include il nome host; conterrà anche un record di Tipo A che fornisce l'indirizzo IP del server DNS nel campo Valore del record NS. Come esempio, si supponga che un server edu TLD non è autorevole per l'host gaia.cs.umass.edu. Allora questo server conterrà un record per un dominio che include l'host gaia.cs.umass.edu, ad esempio, (umass.edu, dns.umass.edu, NS). Il server edu TLD potrebbe contenere anche un record Tipo A, che mappa il server DNS dns.umass.edu in un indirizzo IP, ad esempio, (dns.umass.edu, 128.119.40.111, A).

Messaggi DNS

Precedentemente in questa sezione, si è fatto riferimento a query DNS e messaggi di risposta. Questi sono gli unici due tipi di messaggi DNS. Inoltre, entrambi i messaggi di richiesta e di risposta hanno lo stesso formato, come mostrato in Figura:

Identificativo	Flag	12 byte
Numero di interrogazioni	Numero di risposte RR
Numero di RR autoritari	Numero di ulteriori RR
Interrogazioni (numero variabile)		campi Nome, Tipo di una query
Risposte (numero variabile di RR)		Record Risorse in risposta alla query
Autorità (numero variabile di RR)		Record per i server autorità
Informazioni aggiuntive (numero variabile di RR)		Informazioni utili

Il significato dei vari campi di un messaggio DNS è il seguente:

• I primi 12 byte costituiscono la sezione di intestazione, che è suddivisa in campi. Il primo campo è un numero di 16 bit che identifica la query. Questo identificatore viene copiato nel messaggio di risposta alla query, permettendo al client di confrontare le risposte ricevute con le query inviate. Ci sono un certo numero di bit nel campo flag. La flag query/risposta indica se il messaggio è una query (0) o una risposta (1). La flag autorità è posta a 1 in un messaggio di risposta quando un server DNS interrogato è un server autorevole. La flag ricorsione desiderata è impostata a 1 quando un client (host o server DNS) desidera che il server DNS esegua la ricorsione se non ha il record. La flag ricorsione disponibile è impostata a 1 in una risposta, se il server DNS supporta la ricorsione. Nell'intestazione, ci sono anche quattro campi "Numero di". Questi campi indicano il numero di occorrenze dei quattro tipi di sezioni di dati che seguono l'intestazione.

• La sezione Interrogazioni contiene informazioni relative all'interrogazione. Questa sezione include (1) un campo "nome" che contiene il valore da usare nel criterio di ricerca, e (2) un campo "tipo" che indica il tipo di interrogazione posta circa il nome - per esempio, l'indirizzo di un host associato ad un nome (Type A) o il server di posta corrispondente ad un nome (Type MX).

• In una risposta da un server DNS, la sezione Risposte contiene i record di risorse per il nome che è stato originariamente interrogato. Si ricordi che in ogni record di risorsa c'è il tipo (per esempio, A, NS, CNAME o MX), il valore e il TTL. Una risposta può restituire più record di risorse, dal momento che un host può avere più indirizzi IP (ad esempio, per i server Web replicati, come discusso in precedenza in questa sezione).

• La sezione Autorità contiene record di altri server authoritative.

• La sezione "Informazioni Aggiuntive" contiene altre informazioni utili. Ad esempio, il campo Risposte in una risposta ad una query MX contiene un record di risorsa che fornisce il nome host canonico di un server di posta. La sezione "Aggiuntive" contiene un record Tipo A se si fornisce l'indirizzo IP per il nome host canonico del server di posta.

Come si preferisce inviare una query DNS? direttamente dall'host su cui si sta lavorando ad un server DNS? Questo può essere fatto facilmente con il programma nslookup, che è disponibile in Windows e UNIX. Ad esempio, da un host Windows, aprire il prompt dei comandi e richiamare il programma nslookup digitando semplicemente nslookup. A questo punto è possibile inviare una query DNS a qualsiasi server DNS (root, TLD, o autorevole). Dopo aver ricevuto il messaggio di risposta dal server DNS, nslookup visualizzerà i record inclusi nella replica (in un formato leggibile). In alternativa alla esecuzione nslookup dal proprio host, è possibile visitare uno dei tanti siti web che permettono di impiegare in remoto nslookup. (Basta digitare nslookup in un motore di ricerca e si ottiene un elenco di questi siti).

Inserire Record nel Database DNS

La discussione precedente è stata incentrata su come i record vengono recuperati dal database DNS. Forse ci si sta chiedendo come ottenere i record nel database. Per rispondere a questa domanda si propone un esempio specifico. Si supponga si avere appena creato una nuova società chiamata "Network Utopia". La prima cosa che sicuramente si vuole fare è registrare il nome di dominio networkutopia.com presso un registro. Un registro è un ente commerciale che verifica l'unicità del nome di dominio, inserisce il nome del dominio nel database DNS (come discusso sotto), e chiede una piccola tassa per i suoi servizi. Prima del 1999, un unico registro, Network Solutions, aveva il monopolio sulla registrazione del nome di dominio com, net e org. Ma ora ci sono molti registri in competizione per i clienti, e la Internet Corporation for Assigned Names e Numbers (ICANN) accredita i vari registri. Un elenco completo dei registri accreditati è disponibile presso http://www.internic.net.

Quando si registra il nome di dominio networkutopia.com con alcuni registri, è necessario fornire al registro i nomi e gli indirizzi IP dei server DNS autorevoli primario e secondario. Si supponga che i nomi e gli indirizzi IP sono dns1.networkutopia.com, dns2.networkutopia.com, 212.212.212.1 e 212.212.212.2. Per ciascuno di questi due server DNS di fiducia, l'amministratore dovrebbe assicurarsi che un record tipo NS e un record tipo A vengano inseriti nel server TLD com. In particolare, per il server autorevole primario di networkutopia.com, l'amministratore avrebbe inserito i seguenti due record di risorse nel sistema DNS:

(networkutopia.com, dns1.networkutopia.com, NS)
(dns1.networkutopia.com, 212.212.212.1, A)

Ci si dovrà anche assicurare che il record di risorse di tipo A per il server Web www.networkutopia.com e il record di risorse Tipo MX per il server di posta mail.networkutopia.com vengano inseriti nei server DNS autorevoli. (Fino a poco tempo fa, il contenuto di ogni server DNS era configurato staticamente, per esempio, da un file di configurazione creato da un gestore del sistema). Più recentemente, un'opzione di aggiornamento è stata aggiunta al protocollo DNS per permettere ai dati di essere aggiunti o eliminati dinamicamente dal database tramite messaggi DNS.

Una volta che tutti questi passaggi sono stati completati, la gente sarà in grado di visitare il sito Web e inviare e-mail ai dipendenti dell'azienda. La discussione sul DNS si conclude verificando che questa affermazione è vera. Questa verifica aiuta anche a consolidare ciò che si è appreso sul DNS. Si supponga che Alice in Australia vuole visualizzare la pagina Web www.networkutopia.com. Come discusso in precedenza, il suo host prima invia una query DNS al suo server DNS locale. Il server DNS locale quindi contatta un server TLD com. (Il server DNS locale dovrà anche contattare un server DNS principale se l'indirizzo di un server TLD com non è memorizzato nella cache). Questo server TLD contiene i record di risorse di tipo NS e di tipo A specificati sopra, poichè l'amministratore aveva inserito questi record di risorse in tutti i server TLD com. Il server TLD com invia una risposta al server DNS locale di Alice, con la risposta contenente i due record di risorse. Il server DNS locale quindi invia una query DNS per 212.212.212.1, chiedendo il record di tipo A corrispondente a www.networkutopia.com. Questo record fornisce l'indirizzo IP del server Web desiderato, per esempio, 212.212.71.4, che il server DNS locale restituisce all'host di Alice. Il browser di Alice può ora avviare una connessione TCP con l'host 212.212.71.4 e inviare una richiesta HTTP tramite la connessione.