Guida DNS: caratteristiche e funzionamento di base

[TheWorm91]

In questo thread vedremo il funzionamento di base del servizio DNS e come avviene la traduzione degli hostname in indirizzi IP

1    Introduzione

Tutti gli host della rete internet sono identificati da un indirizzo ip e da un hostname.
Un hostname o nome di dominio è un identificativo simile a questi: www.yahoo.com, www.google.it, mail.google.com ...
Gli hostname nonostante siano molto facili da ricordare e immediati per noi, non lo sono per i router che devono inoltrare i pacchetti sulla rete poichè lavorano con i numeri (indirizzi ip tipo 142.251.143.206) e non con le parole (hostname).
Un nome di dominio è gerarchico perchè leggendolo da destra a sinistra si ottengono varie informazioni dell'host in internet, ad esempio:​

• .com la parte più significativa, è la prima partendo da destra, ed è chiamata TLD (top level domain)
• sito.com è un dominio di secondo livello
• it.sito.com è un dominio di terzo livello
• admin.it.sito.com è un dominio di quarto livello

Dal momento che esistono questi due modi di identificare un host abbiamo necessità di un servizio che tratti archivi di nomi per convertire gli hostname in indirizzi ip.
Questo compito è assolto dal Domain Name System di internet che ha come obiettivo di risolvere un fully qualified domain name (FQDN) in un indirizzo IP, questo processo è chiamato name resolution.​

2    Cos'è DNS?

Per DNS si intende:

1. Database distribuito implementato in una gerarchia di name server
2. Un protocollo del livello applicazione (vedere modelli ISO/OSI e TCP/IP) che permette agli host di comunicare con i name server tramite la porta 53 e UDP in modo da effettuare la traduzione.

3    Funzionamento teorico

Mettiamo che con il browser del mio pc voglio contattare un sito web, ad esempio www.inforge.net

• Sul nostro pc girerà il lato client dell'applicazione DNS che invierà una richiesta contenente l'hostname da tradurre al server DNS
• Il server DNS risponderà con l'indirizzo ip associato all'hostname.
• Fatto ciò il browser apre la connessione verso il portale di inforge.net

Sembra tutto molto semplice ma in realtà non è così e vediamo perchè.
Dall'esempio si potrebbe pensare al DNS come ad un unico server centralizzato che effettua la traduzione degli hostname in indirizzi IP per tutta la rete mondiale.​

Riflettendo un attimo si capisce che sorgerebbero diversi problemi con questo sistema, pensiamo solamente a quante richieste dovrebbe accogliere ogni istante un singolo server!
Ovviamente poi ci sarebbero:

• Un single point of failure per tutta la rete del mondo
• Lunghi ritardi in base alla distanza geografica del server
• Una rete congestionata dalle richieste DNS di tutti gli utenti mondiali
• Un database dall'enorme dimensione e della manutenzione ingestibile.

Un unico server non è quindi scalabile e di conseguenza il servizio DNS per essere fattibile dovrà per forza essere distribuito, infatti si dice che il DNS è un database distribuito.
DNS per funzionare usa diversi server sparsi per tutto il globo e nessuno di questi ha le correlazioni hostname/IP di tutta la rete che sono infatti distribuite tra tutti i server.

Per realizzare la distribuzione del carico si usa un approccio gerarchico, con gli elementi più alti della gerarchia che contengono molte informazioni non dettagliate, mentre gli elementi più bassi nella gerarchia contengono poche informazioni ma dettagliate.

​

4    Tipologie di server DNS

Possiamo classficare i server DNS in quattro tipi:

• Local name server;
• Root name server;
• Top level domain server;
• Authoritative name server;

Local Name Server (Local NS):

Primo server ad essere contattato dal client per risolvere un indirizzo, un local NS mantiene solo le informazioni nella propria cache per i client, in questo modo velocizza il traffico traducendo direttamente l'IP dell'hostname al richiedente senza dover contattare un root name server.
Se invece i dati richiesti non fossero memorizzati nella cache invierà una richiesta a un root name server seguita da un'altra richiesta a un TLD nameserver e quindi un'ultima richiesta a un Authoritative name server.
Il local name server funziona da "intermediario" e durante questo processo memorizza nella cache le informazioni per non ripetere le richieste agli altri server DNS.
Nel caso di reti LAN spesso corrisponde a un server interno mentre nel caso di reti di abitazioni private è esterno e se non configurato sul router o sui dispositivi viene usato quello di default fornito dall'ISP.
Per vedere quale server stiamo usando basta lanciare il comando nslookup(sia su distro linux-based che su windows)
​

I più conosciuti sono:

• Google DNS 8.8.8.8 e 8.8.4.4;
• OpenDNS 208.67.222.222 , 208.67.220.220 , 208.67.222.220 , 208.67.220.222 ;
• Cloudflare 1.1.1.1 e 1.0.0.1;

Root name server (root NS):
Questi server sono in cima della gerarchia DNS.
Quando un local NS non può rispondere immediatamente a una richiesta di un host contatta un root name server che indicherà qual è il TLD nameserver corretto.
I root NS (logici) sono circa 13 in tutto il mondo e sono replicati su circa 400 server fisici.
Qui è possibile visualizzarli tutti: http://www.root-servers.org/

​

Top level domain servers (TLD SERVER o server di primo livello):

Un TLD server conserva le informazioni per tutti i nomi di dominio che condividono un'estensione di dominio comune.
Indicano a un local NS quale Authoritative nameserver contattare per risolvere un dominio.
Si occupano dei domini di primo (alto) livello geografici:

• .it
• .uk
• .us
• .de
• .jp
• ecc...

e generici:

• .info
• .com
• .edu
• .org
• .net
• ecc...

Authoritative name server (Authoritative NS):

Name Server capace di risolvere tutti i nomi all'interno di un dominio poichè contiene informazioni dettagliate sul nome di dominio specifico che serve.
Si trovano alla base della gerarchia e sono gli ultimi ad essere contattati.
Memorizzano tutte le informazioni relative al nome di dominio, compreso il suo indirizzo IP che comunicherà al Local NS.
Per esempio un authoritative name server per il dominio inforge.net deve risolvere tutti i nomi tipo xyz.inforge.net

5    Come avviene la risoluzione

La risoluzione avviene tramite richieste (query) dns che possono essere di due tipi:​

• Ricorsive: Tra client e local NS, quest'ultimo se non ha l'ip associato in memoria si assume la "responsabilità" di risolvere l'indirizzo cercandolo in altri server e risponderà al client appena riesce a trovarlo.
• Iterative: tra local NS e gli altri server DNS (Root, TLD, Authoritative)

Riprendiamo l'esempio precedente ma con un altro dominio.
Vogliamo fare una ricerca su wikipedia e scriviamo sulla barra degli indirizzi del nostro browser it.wikipedia.org, vediamo cosa accade:

1. Il nostro browser per prima cosa consulta la propria memoria cache (e il file hosts) per vedere se trova l'indirizzo ip associato al dominio.
2. Il client se non trova l'ip associato esegue una richiesta al local name server tramite una query ricorsiva.
3. Il local nameserver risponderà alla query con l'indirizzo ip se questo è presente in memoria cache altrimenti se l'indirizzo non è presente nella cache del local server questo contatterà uno dei root server effettuando stavolta query di tipo iterative per ottenere l'indirizzo di it.wikipedia.org.
4. Il root server, che non sa come risolvere it.wikipedia.org, risponderà al local NS con la lista degli indirizzi IP dei TLD per il dominio .org e non andando a contattare altri server, per questo la query si dice iterativa. L'uso di query iterative da parte del local NS è preferibile per non sovraccaricare i root name server che gestiscono un gigantesco volume di richieste.
5. Successivamente il local NS contatta quindi uno dei TLD server che restituisce l’indirizzo IP dell' Authoritative NS che risolve wikipedia.org.
6. Il local NS contatta l'authoritative NS autorizzato a risolvere amazon.com che restituisce l’indirizzo IP di it.wikipedia.org e lo invierà al nostro client che ha richiesto di raggiungere it.wikipedia.org
7. Possiamo finalmente raggiungere il dominio desiderato e visualizzare la web page sul browser

​

6    DNS Caching

Mentre avviene il processo di risoluzione, il local name server memorizza le risposte delle query dai vari NS e l'IP in modo da poterlo inviare una seconda volta recuperandolo direttamente dalla propria cache, senza dover ripetere i passaggi precedenti.
Ad esempio se dopo volessimo andare su un altro dominio www.example.org il local server non contatterà il root server per risolvere l'indirizzo ma direttamente uno dei server TLD per il dominio .org dal momento che sono stati salvati nella memoria cache.

Questa operazione di memorizzazione degli IP si chiama caching è ed molto importante per:

• Velocizzare e non congestionare la rete di messaggi DNS riducendone il numero
• Ottimizzare il traffico
• Non sovraccaricare i root server
• Avere elevata scalabilità

7    Record DNS

I NS possono rispondere con uno o più tipi di record, a seconda della risorsa richiesta, i cui valori si riferiscono al dominio interessato dalla query.
Un resource record è fatto così: (name,value,type,TTL)

• name = dominio richiesto
• value = valore contenuto del RR
• type = tipo del record, i principali sono:
  • type=A: IP v4 associato al dominio, esempio di record A (142.251.209.4,www.google.com,A)
  • type=CNAME: Alias canonico, value quindi è l'hostname canonico per l'alias name (sito.com,www.sito.com,CNAME)
  • type=MX: server SMTP (Mail Exchanger), value è quindi riferito a un server di posta (sito.com,mailsrv.mailx.sito.com,MX)
  • type=TXT: informazioni in formato testuale
• TTL: time to live, tempo di validità del record

8    Altri servizi implementati da DNS

DNS fornisce, oltre alla traduzione degli hostname in indirizzi IP, alcuni altri importanti servizi:

Alias degli hostname:
Per esempio, un hostname come server1.italia.azienda.com può avere due alias del tipo azienda.com e www.azienda.com. In questo caso, l'hostname server1.italia.azienda.com è detto hostname canonico.

Alias dei mailserver:
Anche per quanto riguarda gli indirizzi mail è opportuno che siano mnemonici e di immediata lettura.
Ad esempio Bob potrebbe avere un account gmail del tipo [email protected].
L'hostname del server di posta di gmail è più complesso e difficile da ricordare rispetto a gmail.com, avrà un nome del tipo (nome a caso) smtp01.googlemailserver.gmail.com.
Al DNS un'applicazione di posta può richiedere l'hostname canonico e l'IP fornendo un alias dell'hostname.
Infatti il record MX permette che il server di posta e il web server di una società possano essere chiamati entrambi "dominio.xyz"

Distribuzione del carico:
DNS è anche usato per effettuare la distribuzione del carico fra le repliche di un webserver.
Ad esempio siti molto trafficati sono replicati su diversi server, con ciascun server che funziona su terminali differenti e con differenti indirizzi IP.
Per le repliche dei server web, a ciascun hostname canonico (CNAME) è associato un gruppo di indirizzi IP e questi sono contenuti nel database del DNS.
Quando i client fanno una richiesta al DNS di un indirizzo inserito in un gruppo, il sever risponde con l'intero gruppo di indirizzi IP, ma ruota l'ordine degli indirizzi all'interno di ciascuna risposta.
Poiché un client tipicamente invia il suo messaggio di richiesta HTTP all'indirizzo IP che è in cima all'elenco del gruppo, la rotazione impostata dal DNS distribuisce il traffico fra tutte le repliche dei server.​

9    Conclusioni

L'argomento DNS è molto ampio e questo post non è da intedere come esaustivo. Ho voluto spiegare con parole mie il funzionamento di base, ovviamente ci sarebbe molto altro da approfondire ma lo spazio di un thread singolo non basterebbe, spero in ogni caso che questo serva da spunto per stimolare a qualcuno la curiosità di approfondire l'argomento.​

Per approfondire, DNS è definito nelle RFC 1034, 1035, 2181

 

[0xbro]

Guida molto chiara e ben fatta! Grazie

 

[fennek]

Ottima guida! Mi permetto di aggiungere un paio di dettagli:

1. Il load balancing attraverso il DNS si fa, soprattutto per aree geografiche, cosi i tuoi utenti si connetto a un vero load balancer vicino alla loro località. Visto che le risposte sono cachate, non funziona molto per fare del proprio load balancing
2. La cache, cosi come definita dal TTL, va considerata attentamente quando si aggiornano i record: non puoi eliminare subito il vecchio server a cui viene puntato, alcuni client potrebbero ancora provare a connettersi al vecchio server. Ho storie dell'horror, che mi portano al terzo punto:
3. Il TTL va considerato un suggerimento, non un obbligo. Alcuni resolver aziendali cachano per 30 giorni. Poi magari ci sono altri server in mezzo, e ti trovi chiamate a IP che non sono in DNS da mesi perche sono cachati da qualche parte. La propagazione dei DNS avviene sempre molto lentamente...

 

[NioSciax]

Una delle migliori guide mai lette sul DNS bravo!