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.