Nel mondo del pinguino, il pacchetto BIND (Berkeley Internet Name Domain) è certamente il punto di riferimento per ciò che concerne la gestione del DNS. Tuttavia, esso non è l’unico software disponibile. Ve ne sono altri, tra cui ad esempio djbdns (http://cr.yp.to/djbdns.html) o MaraDNS (http://www.maradns.org). In questo e negli articoli che seguiranno parleremo di BIND in quanto questo pacchetto software, oltre ad essere quello maggiormente impiegato, è certamente quello per il quale si può disporre del miglior supporto e della documentazione più ampia.

BIND è reperibile all’indirizzo http://www.isc.org/products/BIND/. Esso è disponibile in formato tarball (.tar.gz) o RPM, per le distribuzioni che supportano questo sistema di gestione dei pacchetti, come Mandrake o Red Hat.

Nel caso in cui si desideri effettuare l’installazione dai sorgenti, la procedura da seguire è quella usuale, ovvero, dopo aver decompresso il .tar.gz ed esserci collocati nella directory creata, digitiamo:

                        ./configure

                        make

                        su -c “make install” (tale operazione richiede la password di root)

Invece, per chi preferisce il sistema di gestione dei pacchetti RPM, è possibile installare BIND eseguendo:

                        rpm -ivh <nome-del-pacchetto>.rpm

Poiché BIND gestisce un servizio delicato che, per via della sua natura, è molto spesso collocato nei punti della rete maggiormente esposti agli attacchi esterni, è di fondamentale importanza reperirne una versione aggiornata, per avere la certezza (relativa, peraltro) che non vi siano bugs anche gravi che potrebbero compromettere il normale e corretto funzionamento di tutta la rete. Infatti, alcune versioni poco recenti del software soffrono di vulnerabilità legate a buffer overflows, che possono essere sfruttate da un attacker per realizzare condizioni di Denial Of Service, per redirezionare il traffico di rete o, ancora peggio, ottenere l’accesso al sistema, tramite l’esecuzione remota di codice. Al momento della stesura di questo articolo, la versione corrente di BIND è la numero 9, perciò in queste righe faremo riferimento ad essa.

Cosa comprende BIND 

BIND non è soltanto un server DNS. Esso, come afferma l’ISC (Internet Software Consortium), costituisce “un’implementazione del protocollo DNS” ed è composto da:1)un server DNS, chiamato named (conformemente alle modalità di denominazione utilizzate nel mondo *nix per i processi demoni, named = name daemon);2)una libreria di funzioni finalizzate alla risoluzione dei nomi;3)un’insieme di utilities per la gestione del server DNS e per la risoluzione dei problemi. Tra queste ultime, in particolare, assumono grande importanza le utilities dig e nslookup, le quali consentono di effettuare interrogazioni ai servers DNS, costituendo un utile strumento per la diagnosi e la risoluzione dei problemi. In questo articolo vediamo come realizzare, tramite BIND, un name server di cache. Come abbiamo già spiegato nella parte teorica relativa al funzionamento del Domain Name System, un server di cache è un name server che ha, come scopo principale, quello di migliorare l’efficienza nella risoluzione dei nomi di dominio. Esso, infatti, man mano che riceve delle richieste DNS, memorizza le risposte ottenute da altri servers DNS in una memoria di cache, la quale si popola man mano. Il server di cache, in seguito, utilizza tale memoria per rispondere alle richieste successive senza interpellare altri name servers, riducendo perciò i tempi per la risoluzione.  Configurazione di un server di cache Il file principale, per la configurazione del server named è /etc/named.conf. Questo file viene utilizzato da named all’avvio del servizio e, nella sua forma più semplice, dovrebbe apparire grosso modo così: // File di configurazione “/etc/named.conf”// per un name server con funzioni di cache options {        directory “/var/named”;}; zone “.” {        type hint;        file “root.hints”;}; zone “0.0.127.in-addr.arpa” {        type master;        file “primary_zone/127.0.0″;}; Questo file di configurazione, come si può constatare, si compone di diverse sezioni, ognuna delle quali è riferita ad un particolare aspetto del funzionamento di named. Una descrizione completa di esse può essere ottenuta invocando la pagina del manuale relativa con man named.conf. La sezione options descrive la configurazione globale del server DNS. Nell’esempio riportato sopra, essa contiene l’indicazione della working directory /var/named dove si trovano gli altri files di configurazione. In tale sezione si può stabilire, inoltre, attraverso la clausola listen-on, l’indirizzo e la porta sulla quale mettere in ascolto il server (di default named si pone in ascolto su tutti gli indirizzi, utilizzando la porta 53 UDP e TCP). 

La sezione zone è quella di maggiore interesse. Essa stabilisce come deve funzionare il nostro server DNS in base al nome di dominio da risolvere. Il pacchetto BIND consente la gestione di 5 tipi di zona:

• master: indica che il server è autoritativo per questa zona, ovvero contiene la copia principale delle informazioni relative ad essa;
• slave: stabilisce che il server contiene una copia delle informazioni per questa zona, ottenute contattando un altro name server (indicato all’interno della sezione);
• hint: questo tipo indica dove reperire l’elenco dei root servers (con i relativi indirizzi IP) da utilizzare nella risoluzione dei nomi di dominio, quando questi non siano ancora presenti nella memoria cache;
• stub: questo tipo funziona alla stessa maniera del tipo slave, con l’unica differenza che esso replica soltanto i records di tipo NS;
• forward: stabilisce che ogni richiesta ricevuta relativa alla zona deve essere inoltrata ad un altro name server.

Nell’esempio abbiamo due definizioni di zona. La prima (zone “.”) descrive il comportamento da adottare per tutte le zone. Questo, nel caso di un name server di cache, consiste nel risolvere un nome di dominio attraverso l’interrogazione di qualche altro name server nel mondo, che abbia la competenza per quel nome e che può essere raggiunto grazie a un server radice.Per questo motivo la zona “.” è una zona di tipo hint e indica che l’elenco dei root name servers si trova nel file root.hints (precisamente /var/named/root.hints, come risulta dalla clausola directory della sezione options).L’elenco dei root servers può essere soggetto a variazioni, pertanto consigliamo di reperirne una versione aggiornata da Internet, al link ftp://ftp.internic.net/domain/, oppure attraverso l’utility dig (noi preferiamo quest’ultima soluzione), semplicemente digitando al prompt: dig Inoltre, possiamo aggiornare automaticamente il file contenente l’elenco dei root name servers redirezionando l’output di dig: dig > /var/named/root.hints  Di seguito mostriamo un esempio di file root.hints da noi ottenuto con l’ausilio di dig (l’output risulta abbreviato per ovvi motivi di spazio): ; <<>> DiG 9.2.2-P3 <<>>;; global options:  printcmd;; Got answer:;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 28573;; flags: qr rd ra; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 13 ;; QUESTION SECTION:;.                         IN     NS ;; ANSWER SECTION:.                   185810 IN     NS     K.ROOT-SERVERS.NET..                   185810 IN     NS     L.ROOT-SERVERS.NET..                   185810 IN     NS     M.ROOT-SERVERS.NET..                   185810 IN     NS     I.ROOT-SERVERS.NET.…………………………………………………………………………….…………………………………………………………………………….……………………………………………………………………………. ;; ADDITIONAL SECTION:K.ROOT-SERVERS.NET. 272210 IN     A      193.0.14.129L.ROOT-SERVERS.NET. 272210 IN     A      198.32.64.12M.ROOT-SERVERS.NET. 272210 IN     A      202.12.27.33I.ROOT-SERVERS.NET. 272210 IN     A      192.36.148.17…………………………………………………………………………….…………………………………………………………………………….……………………………………………………………………………. ;; Query time: 312 msec;; SERVER: 192.168.3.10#53(192.168.3.10);; WHEN: Fri Nov 21 10:55:00 2003;; MSG SIZE  rcvd: 436  Come possiamo constatare, questo file contiene dei records di risorsa NS, che indicano i nomi dei root servers utilizzabili e dei records di tipo A, con gli indirizzi IP relativi ad essi. Poiché, come abbiamo già detto, queste informazioni sono soggette a cambiamenti nel corso del tempo, sarebbe opportuno predisporre un apposito script che aggiorni periodicamente questo file. La seconda definizione di zona (“0.0.127.in-addr.arpa”) è inserita nel file named.conf per consentire la risoluzione dell’indirizzo di loopback, cioè 127.0.0.1, nel nome localhost convenzionalmente assegnato ad esso. Le informazioni relative a questa zona sono contenute, come si evince dall’esempio, nel file /var/named/primary_zone/127.0.0 , il quale appare più o meno così: $TTL 3D@               IN      SOA     ns.linux.bogus. hostmaster.linux.bogus. (                                1       ; Serial                                8H      ; Refresh                                2H      ; Retry                                4W      ; Expire                                1D)     ; Minimum TTL                        NS      ns.linux.bogus.1                       PTR     localhost. Non ci soffermiamo sul significato di queste righe, in quanto il contenuto di questo file risulterà più chiaro quando tratteremo la configurazione di un name server primario. Per adesso, basti notare come il nome localhost sia contenuto in un resource record di tipo PTR che, come abbiamo detto nel precedente articolo teorico sul DNS, consente di risalire dall’IP al corrispondente hostname. 

A questo punto, possiamo provare a far partire il nostro server con la configurazione mostrata. Naturalmente si tratta di una configurazione “essenziale”, finalizzata esclusivamente alla comprensione del funzionamento di un cache server e che non dovrebbe essere utilizzata, così com’è, su macchine in produzione. Essa non contiene, ad esempio, nessuna opzione relativa al logging e alla sicurezza, come pure al controllo remoto attraverso l’utility rndc (a tal proposito vedi l’apposito articolo riservato a tale utility, all’indirizzo http://www.space4tutorial.com/?p=22). Inoltre, in questo articolo non affrontiamo le problematiche riguardanti l’esecuzione di named come utente non privilegiato e l’esecuzione di questo demone in un “chrooted environment“. Chi fosse interessato a far girare BIND in un’ambiente sicuro può contattarmi, senza problemi. Appena possibile conto di scrivere un apposito articolo sulle “chroot jail” ovvero le “prigioni” per i processi, sui vantaggi che comportano e sulle problematiche connesse ad esse. Inoltre, su Internet è disponibile un HOWTO sull’argomento che tratta proprio il pacchetto BIND, reperibile al link http://www.tldp.org/HOWTO/Chroot-BIND-HOWTO.html, oppure al link http://ildp.pluto.it/HOWTO/Chroot-BIND-HOWTO.html (per la traduzione italiana).

Possiamo avviare named attraverso uno script costruito ad hoc, con /etc/init.d/named start oppure, invocandolo direttamente con /usr/sbin/named. Inoltre, possiamo verificarne la corretta esecuzione analizzando il contenuto del file /var/log/messages, con il comando tail -f /var/log/messages.  Adesso il nostro server di cache dovrebbe essere in esecuzione. Lo possiamo constatare attraverso l’utilizzo del comando netstat -antu che, tra le altre righe, dovrebbe mostrare le seguenti: tcp        0      0    0.0.0.0:53            0.0.0.0:*               LISTENudp        0      0    0.0.0.0:53            0.0.0.0:*                              LISTENEsse indicano che il server è attivo ed è in ascolto sulla porta 53, sia UDP che TCP. Per utilizzare questo server, è necessario configurare i client DNS (resolver) in modo da puntare ad esso, modificando il file /etc/resolv.conf . Se per le nostre prove vogliamo utilizzare come resolver la stessa macchina sulla quale gira il name server, allora esso dovrà contenere come prima riga: nameserver 127.0.0.1 che stabilisce il primo name server a cui fare riferimento. Nel caso in cui il resolver sia un computer diverso da quello su cui è eseguito il server DNS è necessario sostituire l’indirizzo 127.0.0.1 con l’indirizzo effettivo del name server. È importante notare che questo file non è utilizzato da named, bensì dalle funzioni di resolving che si occupano di convertire nomi di dominio in indirizzi e viceversa e che, perciò, necessitano di sapere quale server DNS interpellare.  Adesso che il name server di cache è in funzione e tutto è stato predisposto per il suo utilizzo, verifichiamone il corretto funzionamento attraverso l’invio di qualche interrogazione.A tale scopo, possiamo utilizzare le utilities dig e nslookup, tenendo presente, però, che l’uso di dig è consigliato, rispetto a nslookup, in quanto quest’ultimo tool sarà rimosso dalle versioni future di BIND.Con dig, ad esempio, digitiamo: dig www.space4tutorial.com 

La risposta che otterremo sarà molto simile alla seguente:

; <<>> DiG 9.3.4 <<>> www.space4tutorial.com
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4247
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 2, ADDITIONAL: 0

;; QUESTION SECTION:
;www.space4tutorial.com.                IN      A

;; ANSWER SECTION:
www.space4tutorial.com. 172800  IN      CNAME   w-04.th.seeweb.it.
w-04.th.seeweb.it.      600     IN      A       217.64.195.226

;; AUTHORITY SECTION:
th.seeweb.it.           600     IN      NS      ns1.th.seeweb.it.
th.seeweb.it.           600     IN      NS      ns2.th.seeweb.it.

;; Query time: 383 msec
;; SERVER: 213.26.137.90#53(213.26.137.90)
;; WHEN: Tue Jul 31 20:15:08 2007
;; MSG SIZE  rcvd: 123

Bisogna notare come l’output di dig sia suddiviso in diverse sezioni, che riguardano i diversi aspetti dell’interrogazione DNS. Infatti, dig mostra sia le informazioni fondamentali come nome di dominio e indirizzo IP, sia le informazioni relative ai name servers autoritativi per il nome di dominio indicato.

Nei successivi articoli tratteremo l’uso avanzato di questo tool, mentre qui ci soffermiamo su un’informazione in particolare: il Query time, ovvero, l’intervallo di tempo intercorso tra il momento in cui abbiamo sottoposto la richiesta al server DNS e l’istante in cui esso ha restituito la risposta. Nell’esempio riportato sopra, dig ci dice che il nostro server di cache ha risolto il nome di dominio www.space4tutorial.com in 383 msec.

Cosa succede se eseguiamo un’altra volta lo stesso comando, interrogando il nostro server DNS sullo stesso nome di dominio?

Mostriamo l’output (ridotto, questa volta, alla parte che ci interessa) relativo alla seconda interrogazione: ;; Query time: 1 msec;; SERVER: 192.168.3.10#53(192.168.3.10);; WHEN: Fri Nov 21 12:36:08 2003;; MSG SIZE  rcvd: 87 Ma come è possibile che questa volta abbiamo ottenuto un tempo così basso, addirittura di 1 msec?La spiegazione sta nel fatto che il nostro name server la prima volta ha dovuto interrogare a sua volta altri server DNS per ottenere l’indirizzo IP, mentre adesso, avendo memorizzato nella memoria cache le informazioni ottenute precedentemente, ha fatto ricorso ad essa per fornirci la risposta in tempi assolutamente brevi! Come si può constatare, l’utilizzo di un name server con funzioni di cache ci permette di migliorare non di poco le performances della risoluzione DNS. Inoltre, se impiegati in una rete intranet, i caching name servers consentono di risolvere i nomi di dominio internamente alla rete stessa. Quindi, in questo modo è possibile ridurre progressivamente, fino alla quasi totale eliminazione, il traffico relativo al DNS sulla rete esterna, ottenendo un miglioramento complessivo delle prestazioni.  Bisogna precisare che la cache di cui si parla risiede nella memoria RAM ed è mantenuta da named finché esso è in esecuzione. Pertanto un riavvio di named comporta la perdita del contenuto della cache e quindi delle informazioni memorizzate nel corso del tempo. Inoltre, è importante ricordare che un server di cache offre le prestazioni migliori dopo un certo tempo di utilizzo, perché la cache si riempie di informazioni sui nomi di dominio e c’è sempre meno bisogno di interrogare altri name servers. Prima di concludere questo articolo sulla configurazione di un name server di cache, affrontiamo un altro aspetto del meccanismo di risoluzione dei nomi di dominio, strettamente collegato al problema del bilanciamento del carico di lavoro tra più servers DNS: il forwarding. Il DNS forwarding consente di realizzare una gerarchia di impiego dei servers DNS e, a volte, può essere utilizzato per permettere, a servers che non hanno accesso diretto a Internet, di risolvere comunque i nomi di dominio esterni. Configurando il DNS forwarding possiamo fare in modo che, quando il nostro name server riceve query relative a nomi di dominio non ancora memorizzati nella propria cache, esso risolva le queries ricevute interrogando il server DNS del nostro provider. Quest’ultimo, nella maggior parte dei casi, sarà in grado di risolvere le queries ricorrendo alla propria cache (contenente molti più nomi di quella del nostro server), producendo perciò delle risposte in un tempo molto più breve. Inoltre, il forwarding allegerirà il nostro name server, il quale non sarà costretto a ricorrere alla risoluzione attraverso i root-servers. Quando si parla di forwarding si deve fare attenzione a non confondere la gerarchia dei nomi di dominio con la gerarchia di impiego dei servers DNS, in quanto quest’ultimo concetto riguarda le modalità di utilizzo dei servers DNS e non la struttura dei nomi. La configurazione di un server per il forwarding è molto semplice. Supponendo che il nostro provider abbia due name servers con gli indirizzi IP 11.22.33.44 e 55.66.77.88, l’unica cosa da fare è aggiungere al file named.conf le seguenti righe, all’interno della sezione options: options {        …………..        …………..          forward first;        forwarders {             11.22.33.44;             55.66.77.88;        };}; Come si può facilmente intuire, la prima riga indica che named dovrà ricorrere ai forwarders indicati successivamente e, se essi non rispondono, di provvedere autonomamente alla risoluzione dei nomi. Gli indirizzi indicati nella sezione “forwarders”, invece, sono gli indirizzi IP dei name servers del nostro provider. Concludendo… Come si può vedere in queste pagine, la configurazione di un name server di cache è un’operazione piuttosto semplice, una volta che si è compreso il funzionamento logico del Domain Name System. Cionondimeno l’utilizzo di uno o di più server di cache all’interno di una rete è di grande importanza, soprattutto in virtù del fatto che, generalmente, la percentuale di traffico DNS di una rete si attesta tra il 4% e il 16% del traffico complessivo. 

In questo articolo, oltre a descrivere le caratteristiche principali di named quale cache server, abbiamo introdotto alcuni tools utili per l’interrogazione e la verifica del corretto funzionamento di un server DNS. Nei prossimi articoli, che scriverò appena possibile per Space4Tutorial, vedremo, invece, come si configura named per svolgere funzioni di server primario e secondario e tratteremo l’uso avanzato di dig e nslookup.

Fornendo al nostro server DNS un nome in questa forma, otterremo, se il nome esiste, il corrispondente indirizzo IP, che successivamente potremo utilizzare per attuare la comunicazione con l’host di destinazione.

Organizzazione delle informazioni gestite dal DNS 

Prima di descrivere il funzionamento del Domain Name System, bisogna notare che esso è un sistema statico, vale a dire che l’aggiunta, la modifica, o la rimozione delle informazioni non avviene in maniera automatica, ma deve essere effettuata manualmente dall’amministratore del server DNS responsabile per quelle informazioni.

Si tratta, inoltre, di un sistema che realizza una struttura gerarchica distribuita. Questo significa che non esiste un unico server DNS che conserva tutte le corrispondenze dei nomi Internet, ma che il suo funzionamento complessivo dipende da migliaia di server DNS presenti sulla rete. Pertanto, se uno di essi subisce un’interruzione per guasto o per altri motivi, il servizio continua a funzionare senza impedimenti.

Infine, il DNS si basa su un’architettura di tipo client-server (come molti altri servizi Internet), vale a dire che abbiamo sempre una macchina che effettua una richiesta di risoluzione di un nome detta appunto “resolver” e un’altra che fornisce il servizio di risoluzione (server). Naturalmente, come avviene per qualsiasi altro servizio basato sulla suite di protocolli TCP/IP, client e server possono risiedere sullo stesso computer.

I nomi di dominio sono organizzati secondo una struttura ad albero capovolto, che costituisce il “name space”. La radice dell’albero è detta “radice non denominata” o più semplicemente dominio “root” ed è rappresentata da un punto “.”. I nodi interni descrivono i “domini”. Un dominio consiste in un’insieme di nomi che discendono da uno stesso nodo. Trattandosi di un’albero, inoltre, un dominio può essere suddiviso ulteriormente in più sotto-domini. Le foglie, infine, rappresentano i nomi degli hosts.

 Fig. 1: L’organizzazione del name space per i nomi di dominio.

Attraverso quest’albero è possibile ottenere il nome FQDN di una macchina presente su Internet.

Un nome FQDN è un nome di dominio che include tutti i domini di livello superiore e, per questo, è detto anche nome di dominio completo. Esso è composto da una sequenza di più etichette separate tra loro da punti. Nomi di dominio validi, possono essere www.ietf.org, setiathome.ssl.berkeley.edu, ecc.

Come si evince dallo schema in Fig. 1, per esempio, il nome FQDN www.space4tutorial.com., relativo al sito web di questo blog, rappresenta l’host www appartenente al dominio space4tutorial. A sua volta, il dominio space4tutorial è contenuto nel dominio com, il quale discende dal dominio radice (“.”).

A questo punto è necessario fare una precisazione: i nomi “www.space4tutorial.com” e “www.space4tutorial.com.” (seguito dal punto finale) sono perfettamente identici, agli occhi del DNS. Questo perché il punto è suffisso implicito di ogni nome di dominio e può essere omesso (come d’altronde avviene nella maggior parte dei casi). Inoltre, il DNS considera lettere maiuscole e minuscole allo stesso modo (in altre parole, non è case-sensitive), pertanto “WHOIS.RIPE.NET” è perfettamente identico a “whois.ripe.net”.

Nella gerarchia dei nomi DNS, immediatamente al di sotto del dominio radice, si trovano i nomi dei domini di primo livello (Top Level Domain o TLD). Alcuni di questi domini indicano una collocazione geografica e sono chiamati ccTLD (country code TLD), mentre altri, indicati a volte come gTLD (generic TLD), possono indicare una tipologia giuridica o delle finalità specifiche (in Tabella 1 sono riportati degli esempi).

Tabella 1: Esempi di domini Top Level. Alcuni domini ccTLD sono ulteriormente suddivisi in sotto-domini che rappresentano specifiche regioni geografiche di un determinato Paese (es: .wv.us – West Virginia – United States).

Per quanto riguarda il dominio radice, bisogna dire che su Internet esistono circa una dozzina di server DNS radice, contenenti le medesime informazioni, utilizzati per garantire, in caso di indisponibilità di uno di essi, il corretto funzionamento del servizio.

Al di sotto dei domini TLD, ritroviamo i diversi domini (eventualmente suddivisi in ulteriori sotto-domini) e i nomi delle singole macchine. 

Come funziona il DNS? 

Detto questo, analizziamo nel dettaglio il meccanismo di interrogazione del DNS, attraverso un esempio pratico (Vedi Fig. 2).

Se digitiamo l’indirizzo www.kernel.org nella barra degli indirizzi del nostro browser preferito, il nostro computer chiede ad un server DNS di risolvere il nome fornito (1), restituendoci il corrispondente indirizzo IP, che successivamente sarà utilizzato per stabilire la connessione con la macchina remota che ospita il server Web capace di restituire contenuti html.

Il server DNS da noi interpellato, generalmente è il server del nostro provider Internet, ma potrebbe anche essere un server diverso (ad esempio, se il computer fa parte di una rete connessa ad Internet, potrebbe trattarsi di un server DNS interno alla rete stessa). Comunque, il funzionamento non cambia.

Il server DNS verifica prima di tutto se possiede l’indirizzo IP corrispondente al nome da risolvere. Potrebbe, infatti, essere in grado di risolvere autonomamente quel nome, perché contiene le informazioni relative ad esso oppure perché tale nome è già stato risolto in precedenza. In caso contrario, esso interroga uno dei root servers (2), dando inizio al processo di ricerca delle informazioni da noi richieste all’interno della gerarchia dei nomi di dominio.

 Fig. 2: Il meccanismo di querying (interrogazione) del DNS

Come si può vedere dalla Fig. 2, il root server interrogato, fornisce al nostro server DNS l’indicazione del server responsabile per lo spazio dei nomi .org (3). Successivamente, il nostro server inoltra la stessa richiesta a quest’ultimo (4), che non è in grado di risolvere completamente il nome www.kernel.org, ma che è in grado di indicarci il server che può farlo (5), cioè il server responsabile per la zona kernel.org. Il processo di risoluzione si conclude inoltrando la richiesta a questo server (6), il quale riconosce il nome www come facente parte della zona kernel.org e restituisce l’indirizzo IP corrispondente (7 e 8).

Prima di andare avanti è necessario chiarire il concetto di zona. Una zona consiste in un dominio, o un insieme di domini che ricadono sotto la responsabilità di un server DNS. In altre parole, una zona è un sottoinsieme del name space, contenente uno o più domini gestiti dallo stesso name server. Quest’ultimo è detto “server autoritativo” per quella zona.

È interessante notare come lo stesso server DNS possa gestire zone diverse, diventando server autoritativo per esse.

A volte, i concetti di dominio e di zona sono considerati intercambiabili. Tuttavia, si tratta di due entità distinte. Infatti, il dominio rappresenta un insieme di nomi raggruppati in base ad un determinato criterio (es: i nomi delle macchine che riguardano un’azienda, un Paese, ecc.), mentre una zona comprende le informazioni su un dominio o su parte di esso mantenute da un server specifico.

Detto questo, esaminiamo i diversi tipi di server DNS. In particolare abbiamo:

• Servers primari: sono servers principali, responsabili della gestione delle informazioni relative ad una determinata zona (di autorità).
• Servers secondari: servers utilizzati per realizzare la ridondanza delle informazioni conservate dai server primari. Un server secondario conserva una copia delle informazioni presenti sul name server primario, informazioni ottenenute attraverso una operazione denominata “trasferimento di zona” o “zone transfer”. I servers secondari sono utilizzati, quindi, principalmente come server di backup da utilizzare nel caso in cui il server primario sia non disponibile e svolgono anche una funzione di bilanciamento del carico nel caso in cui si debba far fronte ad un numero eccessivo di richieste. A fronte di un server primario, è possibile avere diversi servers secondari.
• Servers di cache: sono servers la cui funzione principale è migliorare l’efficienza nella risoluzione dei nomi di dominio. Essi sono molto utilizzati all’interno di reti LAN e memorizzano le risposte ottenute da altri servers DNS in un’apposita cache, per il successivo utilizzo. Questa cache, si riempie progressivamente, sicché, dopo un certo tempo di utilizzo, il maggior numero di nomi di dominio sia risolvibile senza far capo ad altri server DNS, abbreviando progressivamente i tempi di attesa per la risoluzione.

Bisogna fare una considerazione di carattere strategico: dato che dalla velocità di risoluzione dei nomi di dominio dipende l’efficienza dell’intera rete, il servizio di DNS è stato progettato per utilizzare principalmente il protocollo UDP (porta 53), caratterizzato da una semplicità intrinseca, tipica dei protocolli connection-less. Tuttavia, per i trasferimenti di zona, esso si appoggia al protocollo TCP, più affidabile. In questi casi, infatti, è necessaria la garanzia che i dati trasferiti non vengano alterati durante la copia presso i name server secondari.

Tra le informazioni contenute in un messaggio DNS, assume particolare importanza il “Resource Record” o record di risorsa (RR), il quale descrive il contenuto del messaggio stesso. Un name server può infatti inviare messaggi di diverso tipo, a seconda delle interrogazioni che esso riceve. Di seguito indichiamo i RR principali, con il relativo significato:

A = (Address) indirizzo IP corrispondente al nome di dominio richiesto al DNS;

SOA = (Start Of Authority) informazioni sull’autorità per il dominio richiesto;

MX = (Mail eXchange) Host utilizzato come centrale postale per il dominio;

CNAME = (Canonical NAME) definisce un alias da utilizzare nell’ambito del dominio;

NS = (Name Server) nome del server di autorità per il dominio;

TXT = (TeXT) Testo arbitrario, utilizzato per fornire ulteriori informazioni;

PTR = (PoinTeR) puntatore utilizzato nella risoluzione inversa, che permette di ottenere, da un indirizzo IP, il nome di dominio corrispondente.

I Resource Records sono un elemento molto importante, nell’ambito del funzionamento del DNS. Essi permettono, ad esempio, di distinguere se un server ha restituito una risposta contenente l’indirizzo di un nome risolto (tipo A) oppure se tale risposta contiene il nome di un altro server responsabile di una specifica zona (tipo NS), al quale va inoltrata la richiesta. Inoltre, offrono all’amministratore la possibilità di creare più alias di uno stesso nome o di fornire informazioni supplementari che non riguardano direttamente la risoluzione degli indirizzi (es: il tipo TXT).

Due parole, in particolare, vanno spese per il tipo PTR: il DNS, oltre a consentirci di risalire, partendo dal nome di dominio, ad uno specifico indirizzo IP, ci permette di effettuare l’operazione inversa, cioè, conoscendo l’indirizzo IP, possiamo ottenere il relativo nome di dominio. A tal fine, il Domain Name System prevede un dominio speciale, denominato “.in-addr.arpa” (in-addr come internet address, arpa come ARPANet, la rete dalla quale è nata Internet), il quale può essere utilizzato, in abbinamento con un indirizzo IP o con parte di esso, per ottenerne il nome di dominio corrispondente. Ad esempio, se vogliamo ottenere il nome corrispondente all’indirizzo 192.0.34.161, possiamo interrogare il nostro name server (tramite utility di querying DNS come dig o nslookup) chiedendo di risolvere “161.34.0.192.in-addr.arpa“ e ottenendo il nome di dominio “www.internic.net”. Notiamo come l’indirizzo IP debba essere indicato nella forma inversa, ovvero dall’ottetto meno significativo al più significativo (allo stesso modo dei nomi di dominio, che vanno dal nome più specifico al più generico).

Voglio anche io il mio nome di dominio!!! 

Dopo esserci soffermati sugli aspetti teorici dell’argomento, concludiamo vedendo come si ottiene un nome di dominio, ad esempio, per il nostro nuovo portale web, oppure perché vogliamo proiettare la parte pubblica della nostra rete su Internet e vogliamo che essa sia raggiungibile dall’esterno.

Possiamo utilizzare i DNS del nostro provider, delegando ad esso l’onere delle pratiche burocratiche necessarie alla registrazione del nuovo nome di dominio, oppure possiamo decidere di gestire il nostro server DNS in autonomia. Se optiamo per quest’ultima scelta, allora dobbiamo rivolgerci direttamente alla Registration Autority (RA) competente, a seconda del dominio TLD sotto il quale vogliamo inserire il nostro nome. Le Registration Autorities sono coordinate da un’istituzione “super-partes” che è l’I.A.N.A. (Internet Assigned Numbers Authority). Dalla pagina http://www.iana.org/cctld/cctld-whois.htm è possibile raggiungere i links delle diverse RAs, relative ai domini TLD di tutto il mondo.

Per il dominio .it, ad esempio, è responsabile la Registration Autority Italiana raggiungibile all’indirizzo http://www.nic.it/RA/. Se desideriamo un dominio nel TLD .it, dobbiamo effettuare la registrazione del nome presso la RA Vedremo, nei successivi articoli quali sono i pre-requisiti tecnici per ottenere la registrazione del proprio nome di dominio.

Concludendo… 

L’amministrazione del DNS non è cosa semplice, a volte può risultare piuttosto insidiosa. Tuttavia, dopo aver compreso i concetti che stanno alla base del suo funzionamento, non si dovrebbero avere grosse difficoltà a soddisfare anche esigenze di una certa portata.

Naturalmente, una trattazione su uno dei servizi più “anziani” di Internet non può certamente esaurirsi in queste righe, che tuttavia possono essere il punto di partenza per un’analisi più approfondita dell’argomento (vedi alla fine del tutorial).

Nel corso dei successivi articoli, vedremo insieme come implementare il servizio di DNS con GNU/Linux, esaminando gli aspetti della configurazione di un name server di cache, primario e secondario, attraverso l’impiego del pacchetto BIND ed affrontando problematiche specifiche come, ad esempio, la sicurezza.

Per ulteriori approfondimenti sugli argomenti trattati in queste pagine, consigliamo la lettura delle principali RFCs (Requests For Comment): 

·        819 “The Domain Convention for Internet User Applications”

·        1034 “Domain Names — Concepts and Facilities”

·        1035 “Domain Names — Implementation and Specification”

·        1591 “Domain Name System Structure and Delegation”

Inoltre, di seguito segnaliamo alcuni links di interesse:

 ·         http://www.dns.net/dnsrd/

·         http://www.noc.garr.it/docum/corsi/CorsoDNS.pdf 

Per chi, invece, desiderasse dedicarsi alla lettura di un buon libro, affrontando anche altre tematiche riguardanti le reti, consigliamo:

 ·        “Internetworking con TCP/IP” vol.1 – Douglas Comer – Ed. Addison-Wesley – 2002

Questo articolo è stato realizzato insieme ad un mio grandissimo amico nonché appassionato di software Open-Sources e di Linux in particolare, che ora vedo un pò meno, perché si è maritato e vive lontanuccio, ma che vorrei salutare e ringraziare in queste pagine.

Grazie, Claudio!