Capitolo 11. Il Domain Name System
- Sommario
- 11.1. Che cos'è il DNS?
- 11.2. Impostare un caching server
- 11.3. Un name server per il dominio locale
- 11.4. I file di configurazione di named
- 11.5. Avviare il name server
In questo capitolo ci occuperemo del DNS (Domain Name System). Utilizzando come esempio la rete descritta nel Capitolo 10 verrà configurato un name server locale.
Nel Capitolo 10 abbiamo visto come impostare i file di configurazione di una semplice rete locale. Uno dei problemi da affrontare era la traduzione dei nomi degli host della rete in indirizzi IP e viceversa. Nel contesto del capitolo in questione il problema veniva risolto utilizzando il file /etc/hosts, nel quale erano indicate le corrispondenze tra host e indirizzi IP e che doveva essere presente (e aggiornato) su ognuno degli host della rete stessa. Per esempio:
192.168.1.1 ape.insetti.net ape 192.168.1.2 vespa.insetti.net vespa
Un ulteriore file, /etc/nsswitch.conf, indicava al sistema l'ordine in cui consultare le risorse per risolvere i nomi degli host.
hosts: files dns
Con questo sistema il file /etc/hosts veniva consultato per primo e solo in caso di fallimento veniva fatto ricorso al DNS. Poiché la rete non aveva un proprio name server, venivano utilizzati quelli forniti dal provider, specificandoli nel file /etc/resolv.conf con la direttiva "nameserver". In pratica il file /etc/hosts veniva usato per la risoluzione dei nomi della rete locale (non visibili all'esterno) e i server DNS del provider consentivano di risolvere i nomi appartenenti a Internet.
Nota: col il termine risolvere si indica la conversione da nome a indirizzo IP e viceversa.
La situazione è illustrata nella Figura 11-1: ape è il gateway della rete e la direttiva nameserver dei file /etc/resolv.conf di entrambi gli host punta al name server del provider. Tutte le interrogazioni DNS vengono indirizzate a quest'ultimo. I nomi degli host locali sono risolti esaminando il file /etc/hosts.
In questo capitolo si vedrà come impostare un server DNS in locale, senza bisogno di ricorrere ai server del provider, che consenta di risolvere ogni tipo di nome, sia interno sia esterno e di evitare il ricorso al file hosts. Verranno descritti due tipi di approcci, il cui significato sarà chiarito nel seguito: un caching server e un server vero e proprio. L'ambiente in cui verrà configurato il name server sarà lo stesso di quello descritto nel Capitolo 10.
La situazione che si vuole ottenere è illustrata dalla Figura 11-2. Il name server si trova sull'host ape e viene utilizzato per risolvere sia i nomi interni sia quelli esterni. Il file /etc/resolv.conf di ape punta a se stesso mentre quello di vespa punta a ape. Il name server del provider non viene utilizzato (a meno di non usare la direttiva forwarders illustrata nel seguito).
Nota: ci si può chiedere quando è opportuno seguire l'approccio descritto nel Capitolo 10 e quando conviene utilizzare un proprio server DNS. Come in molti altri casi, non esiste una risposta univoca. In generale, per computer isolati o per casi di reti locali molto semplici, come quella descritta in precedenza, che si appoggiano sui server DNS di un provider conviene seguire l'approccio già descritto, riservando l'uso di un proprio server DNS per situazioni più complesse. Al termine della lettura del capitolo dovrebbe essere abbastanza chiaro quand'è che l'uso di un server locale può essere più comodo.
11.1. Che cos'è il DNS?
Quando si fa riferimento a un host è decisamente più comodo utilizzare un nome del tipo www.netbsd.org che un indirizzo IP numerico quale 110.111.112.113. Al livello di comunicazione più basso, però, non vengono usati i nomi bensì gli indirizzi in forma numerica; appare quindi evidente l'esigenza di un servizio di traduzione dei nomi in indirizzi numerici e viceversa. Il DNS (Domain Name System) è precisamente questo (e anche di più). Si tratta di un database gerarchico e distribuito; gerarchico significa che lo spazio dei nomi degli host non è "piatto" ma che esiste una gerarchia di nomi. Ciò rende possibile l'esistenza di due host con lo stesso nome purché appartengano a domini diversi; se così non fosse, potrebbe esserci un solo host di nome www collegato a Internet mentre, con una struttura gerarchica, www.netbsd.org e www.mydomain.org sono due host diversi. Distribuito significa che il database DNS non è concentrato tutto in un punto (ossia non esiste un host che conosce i nomi e gli indirizzi di tutti gli altri host) ma è "spezzettato": ogni server possiede le informazioni relative al proprio dominio. Pertanto, per poter svolgere il loro compito è necessario che i server possano mettersi in contatto tra loro per scambiarsi informazioni.
L'applicativo di riferimento per quando riguarda la gestione del DNS è BIND (Berkeley Internet Name Domain System), un software liberamente distribuito dall'ISC (Internet Software Consortium) che implementa il protocollo DNS. BIND fa parte della distribuzione base di NetBSD e pertanto non è necessario installare alcun software aggiuntivo. La distribuzione di BIND comprende vari componenti, tra i quali il server DNS, rappresentato dal demone named, e alcuni programmi di utilità quali host, dig, nslookup e dnsquery. Inoltre fanno parte della distribuzione di BIND anche le funzioni di libreria per la risoluzione delle query DNS.
Nota: nella collezione dei package è generalmente compresa una versione di BIND più recente di quella installata sul sistema. L'uso di questa versione non è solitamente necessario a meno di esigenze specifiche.
11.1.1. Come funziona un'interrogazione DNS?
Per effettuare un'interrogazione DNS un applicativo contatta un server DNS il quale provvede a sua volta a contattare i server responsabili per il dominio al quale si riferisce il nome da risolvere. In realtà l'interrogazione segue un percorso di tipo gerarchico, partendo dai server di livello più alto, i cosiddetti root servers, fino a arrivare al livello di dettaglio desiderato. Per esempio, supponiamo di voler trovare l'indirizzo IP di www.netbsd.org. Per prima cosa il nostro name server contatta un root server, il quale gli fornisce gli indirizzi dei server per il dominio "org" (org è uno dei cosiddetti TLD, ossia Top Level Domain, che sono i domini di livello più alto, quali "edu", "org", "com", ecc.). Il nostro server quindi contatta uno dei server per il dominio org, il quale a sua volta gli fornisce gli indirizzi dei server per il dominio netbsd.org. Infine il nostro server contatta uno dei server di netbsd.org per sapere l'indirizzo di www, e qui si conclude il giro di domande e risposte.
Questo esempio dovrebbe aver chiarito cosa si intende con "gerarchico e distribuito": il nome dell'host è stato analizzato secondo una precisa gerarchia e le interrogazioni sono state effettuate rivolgendosi di volta in volta ai server che erano a conoscenza delle varie parti.
Nota: si noti che per il DNS l'ordine gerarchico dei nomi procede da destra a sinistra, ossia in www.netbsd.org, org è il livello più alto (il TLD, quello immediatamente sotto ai root server), netbsd appartiene al dominio org e www appartiene al dominio netbsd.org.
11.2. Impostare un caching server
Con il termine caching server si intende un server che non gestisce in proprio la conversione di nomi di host in indirizzi IP, ma fa sempre riferimento a altri server. La particolarità di questo tipo di server è che memorizza le risposte che gli giungono ed è quindi in grado di effettuare le interrogazioni successive più velocemente. Poiché un server di questo tipo non gestisce i nomi interni della nostra rete, per ricavare gli indirizzi di quei nomi sarà ancora necessario fare riferimento al solito file /etc/hosts.
Poiché NetBSD fornisce già una serie di file di configurazione predefiniti, l'impostazione di un server di questo tipo è a dir poco elementare, come si vedrà tra breve.
Nota: il contenuto e il numero dei file di configurazione può variare a seconda della versione di NetBSD.
Il server vero e proprio è costituito dal demone named, il quale fa riferimento a un file di configurazione che, di default è /etc/named.conf. Il file di configurazione d'esempio di NetBSD si trova nella directory /etc/namedb e, pertanto, come prima cosa creiamo un link al file:
# ln -s /etc/namedb/named.conf /etc/named.conf
Il nostro name server è pronto per l'uso; il passo seguente sarà di effettuare dei test per verificarne il corretto funzionamento, ma prima dobbiamo indicare al sistema di usare il nostro server, inserendo nel file /etc/resolv.conf una riga del tipo:
nameserver 127.0.0.1
A questo punto tutto è pronto per avviare named.
# named
Nota: il name server è stato qui avviato manualmente. Una volta verificato il corretto funzionamento è possibile riavviarlo automaticamente al boot agendo sull'apposita opzione del file /etc/rc.conf.
11.2.1. Test del server
Avviamo nslookup per esaminare la situazione e verificare il buon funzionamento del server.
# nslookup Default server: localhost Address: 127.0.0.1 >
Adesso effettuiamo un'interrogazione su (a titolo di esempio) www.mclink.it.
> www.mclink.it Server: localhost Address: 127.0.0.1 Name: www.mclink.it Address: 195.110.128.8
Ripetendo l'interrogazione una seconda volta si ottiene un risultato leggermente diverso:
> www.mclink.it Server: localhost Address: 127.0.0.1 Non-authoritative answer: Name: www.mclink.it Address: 195.110.128.8
Come si vede i dati sono gli stessi ma ora è comparsa la scritta "Non-authoritative answer", che indica che il server non è uscito sulla rete per reperire l'indirizzo ma ha utilizzato i dati che aveva nella cache dopo la prima interrogazione. La risposta non proviene quindi dal server master del dominio mclink.it, come nel caso precedente, bensì dalla cache del nostro server.
Questi primi risultati ci confortano del buon funzionamento del server.
Può essere una buona occasione per provare anche il comando host.
# host www.mclink.it www.mclink.it has address 195.110.128.8
11.3. Un name server per il dominio locale
Ne la Sezione 11.2 si è visto come impostare un caching server, il che è risultato essere piuttosto semplice. Proviamo ora a chiedere al server qualche informazione su un host della nostra rete locale.
# nslookup Default server: localhost Address: 127.0.0.1 > ape.insetti.net Server: localhost Address: 127.0.0.1 *** localhost can't find ape.insetti.net: Non-existent host/domain
Il server non sa nulla del nostro host locale. Infatti i dati relativi sono ancora confinati nel file /etc/hosts, che non viene consultato dal server. Pertanto il name server effettua il solito giro di interrogazioni partendo dai root server ma naturalmente non viene a capo di nulla. Ciò non significa che l'impostazione del server è sbagliata ma indica soltanto che la risoluzione dei nomi locali potrà essere effettuata solo tramite il file /etc/hosts.
Nel seguito del capitolo si vedrà come far gestire al name server il nostro dominio locale; per far ciò occorrerà sia modificare named.conf sia aggiungere i file di zona, cioè i file che contengono i record DNS che descrivono gli host (e altre caratteristiche) della rete locale. In realtà nella configurazione attuale sono già presenti dei file di zona, che si trovano nella directory /etc/namedb, ma su questo torneremo in un secondo tempo.
11.4. I file di configurazione di named
Il demone named legge due tipi di file di configurazione; il primo è il già citato named.conf, contenente le opzioni di configurazione del programma. Il secondo tipo di file è costituito dai cosidetti file di zona, che contengono i record DNS per gli host della rete locale. I record DNS consentono di trasformare i nomi degli host in indirizzi IP e viceversa, di definire i server di posta e di specificare molte altre informazioni. In questo capitolo non veranno descritti in dettaglio né il file di configurazione né i file di zona, ma ci si limiterà a presentare e commentare degli esempi che dovrebbero essere facili da modificare e da adattare.
Nota: è possibile che nel file named.conf fornito con NetBSD siano presenti anche altre sezioni, per esempio per IPv6.
11.4.1. Named.conf
L'esempio seguente mostra una configurazione minima per il file named.conf. Gran parte del contenuto era già presente nel file di default di NetBSD; solo le righe dalla 17 alla 25 sono state aggiunte per gestire il dominio locale.
Nota: i numeri di riga e il carattere "|" all'inizio della riga non fanno parte del file e sono presenti solo come riferimento.
Già a una prima occhiata si nota che il file è diviso in sezioni (o più precisamente statement) distinte, con i corpi delle varie sezioni racchiusi tra parentesi graffe. Vediamo ora in dettaglio il significato delle varie parti del file (per una descrizione completa si rimanda alla pagina di manuale named.conf(5)).
- Linea 1
Le linee che iniziano con il carattere "#" sono considerate dei commenti e vengono ignorate, al pari delle linee vuote. Vengono riconosciuti anche i comenti in stile C e C++.
- Linee 3-5
La sezione options controlla le opzioni di configurazione globale del server e i default che verranno usati nelle altre sezioni del file. La direttiva directory definisce la directory di lavoro del server; tutti i percorsi non assoluti presenti nelle altre sezioni del file di configurazione verranno interpretati come relativi a questa directory. Per esempio, il file root.chache (linea 7) verrà cercato in /etc/namedb/root.cache.
- Linee 7-10
Questa sezione definisce una zona. Si tratta di una zona speciale, predefinita, contenente i già citati root server, quelli dalle quali partono le ricerche. La direttiva hint indica che questa zona è proprio quella dei root server e la linea 7 specifica il nome del file in cui si trovano i dati della zona (il file è già cortesemente fornito da NetBSD).
- Linee 12-15
Questa sezione definisce la zona inversa locale per l'indirizzo di loopback (127.0.0.1). Vedere la spiegazione delle righe 22-25.
- Linee 17-20
Definizione della zona relativa al dominio locale. L'opzione "type master" indica che il server è il master server per questa zona, cioè è quello che ha la copia master del file di zona (nel file indicato alla linea 19). Il file di zona contiene i record DNS per effettuare la conversione da nome host a indirizzo IP nonché altre informazioni che saranno esaminate nel seguito.
Si noti che il nome della zona deve corrispondere al nome del dominio mentre il nome del file contenente i record DNS è libero anche se, normalmente, conviene attenersi a qualche convenzione.
- Linee 22-25
Queste linee definiscono la zona inversa per il dominio locale, cioè il file che contiene i record DNS per effettuare la conversione da indirizzo IP a nome host. Anche in questo caso il server è di tipo master. La linea 24 indica il nome del file contenente i record DNS.
Il nome della zona merita una spiegazione. La prima parte è l'indirizzo IP della rete scritto al contrario (192.168.1 diventa 1.168.192), mentre la seconda si riferisce al dominio predefinito "in-addr.arpa" che serve per la risoluzione inversa, cioè la trasformazione degli indirizzi IP in nomi.
Server master e server slave: nell'esempio precedente il nostro server era di tipo master per tutte le zone, cioè era il server che possedeva la copia master dei file di zona. Un server di tipo slave, invece, possiede una copia (replica) dei file di zona del relativo master (che non viene scritta a mano dall'amministratore di sistema come la copia master). Tra server master e slave esistono dei metodi di sincronizzazione automatica la cui descrizione esula dagli scopi di questa breve introduzione.
La configurazione di named.conf è terminata; nelle sezioni seguenti esamineremo il contenuto dei file di zona, descrivendo i record DNS. I file per le zone "." e "127" sono predefiniti e non richiedono modifiche e non verranno pertanto esaminati. La loro struttura è comunque la stessa dei file per il dominio locale.
Prima di passare all'esame dei file di zona vediamo un'ulteriore direttiva che può essere inserita nella sezione options, e cioè forwarders. Per esempio:
options {
directory "/etc/namedb";
forwarders {
1.2.3.4;
1.2.3.5;
};
}; Nell'esempio precedente si supponga che 1.2.3.4 e 1.2.3.5 siano i name server del provider. L'effetto di questa impostazione è che il nostro server effettuerà le interrogazioni servendosi dei name server del provider; in questo modo saranno loro a farsi carico del caching delle informazioni anziché il server locale. Nel caso in cui i forwarders non riescano a rispondere a un'interrogazione, allora il server cercherà di trovare la risposta per conto proprio. Questa impostazione riduce il carico di lavoro del server locale, che si limita a gestire in proprio solo le zone per cui è master (in definitiva il dominio locale).
11.4.2. Il file per la zona insetti.net
Per come è stato definito in named.conf, il file per la zona insetti.net si chiama /etc/namedb/insetti.net. Il suo contenuto è il seguente:
1| ; Local hosts 2| 3| @ IN SOA ape.insetti.net. hostmaster.ape.insetti.net. ( 4| 2000120301 ; Serial 5| 3600 ; Refresh 6| 300 ; Retry 7| 3600000 ; Expire 8| 3600 ) ; Minimum 9| IN NS ape.insetti.net. 10| IN MX 10 ape 11| ape IN A 192.168.1.1 12| vespa IN A 192.168.1.2
Il file precedente è il vero e proprio database DNS, contenente i record DNS. Nel seguito di questa sezione esaminiamo i record presenti nel file.
- Linea 1
Questa linea è un commento.
- Linee 3-8
Questo gruppo di linee definisce il record SOA (Start Of Authority) che delimita l'inizio di una zona di autorità. Ogni zona ha un solo record SOA.
Il carattere @ all'inizio della riga è un sinonimo per il nome del dominio specificato nella direttiva "zone" del file named.conf e quindi in questo caso equivale a "insetti.net".
Il successivo "IN" indica sta per Internet e definisce il tipo di rete.
Dopo SOA vengono, nell'ordine, il name server e l'indirizzo e-mail del responsabile per la zona (nell'indirizzo e-mail il carattere @, che per il DNS ha un significato particolare, deve essere sostituito con un punto).
Nota: si noti che entrambi gli indirizzi precedenti sono terminati da un punto. Tutti i nomi non terminati da un punto sono considerati relativi al dominio corrente e il server li completa aggiungendo il dominio (@) alla fine. Pertanto, nei file di zona bisogna fare attenzione a come si scrivono i nomi: se, per esempio, si scrive "ape.insetti.net" (anziché "ape.insetti.net.") il server internamente tramuta il nome in "ape.insetti.net.insetti.net", che non è certo quel che si vuole ottenere.
Il record SOA continua, racchiuso tra parentesi tonde, fino alla linea 8. La riga 4 definisce il numero di serie del file. Il numero può essere scelto a piacere a condizione che venga incrementato ogni volta che si modifica il file di zona. In questo caso è stato scelta una codifica che si basa sulla data di ultima modifica del file espressa nel formato anno-mese-giorno seguita a un numero seriale. Per esempio, se il file verrà nuovamente modificato il 03/12/2000 il numero diventerà 2000120302, mentre se verrà modificato due giorni dopo diventerà 2000120501. È molto importante ricordarsi di incrementare questo numero di serie quando si modifica il file.
Le linee dalla 5 alla 8 contengono dei tempi in secondi che si riferiscono all'interazione tra il master e i suoi slave. Ai fini di questa introduzione non interessa esaminarle in dettaglio e prenderemo per buoni i valori di default dell'esempio.
- Linea 9
La riga 9 è un record di tipo NS, che indica qual'è il name server autoritario per la zona. Può esserci più di una riga di tipo NS. Si noti che il nome è terminato da un punto.
- Linea 10
Questa linea contiene un record di tipo MX, che contribuisce a velocizzare il trasferimento della posta indicando qual'è (o quali sono) il server di posta della zona. Il numero "10" che compare dopo NS esprime una preferenza: minore è il numero, maggiore è la preferenza data al server; in caso di presenza di più record MX viene utilizzato per primo quello con il numero più basso. Non importa il valore del numero: conta solo il rapporto maggiore-minore con i numeri degli altri record MX. Nell'esempio seguente il mail hub ape verrà provato prima di vespa.
IN MX 10 ape IN MX 20 vespa
Si noti che poiché dopo il nome dell'host non compare il punto, al nome stesso sarà concatenato il dominio.
- Linee 11-12
Finalmente siamo arrivati ai record che vengono usati per trasformare i nomi degli host in indirizzi IP (ma non viceversa: quello è il compito del file per la zona 1.168.192). I due record di tipo A associano gli indirizzi ai nomi dei due host della nostra rete. Se fossero presenti altri host andrebbero aggiunti altri record A. Si noti che i nomi degli host non sono seguiti dal punto.
11.4.3. Il file per la zona 1.168.192.in-addr.arpa
Per come è stato definito in named.conf, il file per la zona 1.168.192.in-addr.arpa si chiama /etc/namedb/1.168.192. Il suo contenuto è il seguente:
1| @ IN SOA ape.insetti.net. hostmaster.ape.insetti.net. ( 2| 2000120301 ; Serial 3| 3600 ; Refresh 4| 300 ; Retry 5| 3600000 ; Expire 6| 3600 ) ; Minimum 7| IN NS ape.insetti.net. 8| 1 IN PTR ape.insetti.net. 9| 2 IN PTR vespa.insetti.net.
La prima parte di questo file è del tutto equivalente a quella del file per la zona insetti.net e quindi non la esamineremo di nuovo. Le uniche novità sono le righe 8 e 9, che hanno la funzione inversa ai record A. Si tratta dei record PTR, che permettono di trasformare gli indirizzi IP in nomi di host. Alla luce di quanto detto fin qui il loro significato dovrebbe essere abbastanza chiaro. Si noti che i nomi degli host sono terminati dal punto.
All'inizio della riga 8 compare il numero "1". Poiché non è seguito da un punto, il DNS gli concatena il nome della zona (1.168.192.IN-ADDR.ARPA), ottenendo 1.1.168.192.IN-ADDR.ARPA, che è l'indirizzo completo da risolvere. Stesso discorso vale per la riga 9, dove si ottiene 2.1.168.192.IN-ADDR.ARPA.
In-addr.arpa: Il dominio predefinito (si tratta di un TLD) in-addr.arpa serve per trasformare gli indirizzi IP in nomi di host. All'interno di questo dominio gli indirizzi IP devono essere scritti con le stesse convenzioni dei nomi degli host, e cioè con la parte più significativa a destra. Per questo motivo 192.168.1.2 diventa 2.1.168.192.IN-ADDR.ARPA. In tal modo BIND può analizzare questo nome esattamente come fa per i nomi degli host, procedendo da destra verso sinistra.
11.4.4. Altri tipi di record per i file di zona
Negli esempi precedenti nei file di zona sono stati inseriti solo i record strettamente necessari per il funzionamento della configurazione che ci eravamo proposti. In realtà esistono molti altri tipi di record che permettono di specificare in maggiore dettaglio e con più flessibilità la struttura della nostra rete. Nel seguito di questa sezione vediamo alcuni altri tipi di record ma, per una descrizione più completa e approfondita, si rimanda alla letteratura specializzata.
I record CNAME servono per creare alias di nomi esistenti, ossia per assegnare ulteriori nomi a un host. Per esempio:
www IN CNAME ape ftp IN CNAME ape
In questo modo abbiamo indicato a BIND che i nomi www e ftp fanno entrambi riferimento all'host ape.
I record TXT servono per aggiungere testo descrittivo ai record DNS. Per esempio:
IN TXT "La mia rete locale"
11.5. Avviare il name server
Il server si avvia come già spiegato per il caching server. Se il server fosse già attivo, ora che i dati di configurazione sono stati modificati occorre riavviarlo, cosa che si effettua con il comando ndc (name daemon control program).
# ndc reload
Ora che il name server è attivo, non è più necessario inserire i nomi degli host nel file /etc/hosts perché ci pensa named a risolvere i nomi. Naturalmente tutti gli host della rete devono "puntare" al name server usando il file /etc/resolv.conf. In particolare su ape avremo:
nameserver 127.0.0.1
mentre su vespa avremo:
nameserver 192.168.1.1