[successivo] [precedente] [inizio] [fine] [indice generale] [violazione GPL] [translators] [docinfo] [indice analitico] [volume] [parte]
Dopo l'introduzione del capitolo precedente sul DNS, è bene approfondire un po' la configurazione di questo servizio.
Se è appena stato configurato il servizio di risoluzione dei nomi, si può riavviare (o semplicemente avviare) il servizio utilizzando il programma rndc, oppure un altro messo a disposizione dalla propria distribuzione GNU.
# rndc stop[Invio]
# rndc start[Invio]
Il demone named emette alcuni messaggi che vengono annotati nel registro del sistema, generalmente nel file /var/log/messages (oppure un altro collocato sempre sotto /var/log/, a seconda della configurazione del sistema operativo). È utile consultare il suo contenuto per verificare che la configurazione sia corretta. Trattandosi dell'ultima cosa avviata, i messaggi si trovano alla fine del file.
# tail /var/log/messages[Invio]
Il listato seguente si riferisce all'esempio di configurazione già vista nel capitolo precedente.
May 31 15:20:56 dinkel named[2778]: starting BIND 9.2.0 May 31 15:20:56 dinkel named[2778]: using 1 CPU May 31 15:20:56 dinkel named[2780]: loading configuration from (segue) |
Se qualcosa non va, è lo stesso named ad avvisare attraverso questi messaggi. Se è andato tutto bene si può provare a vedere cosa accade avviando l'eseguibile dig senza argomenti:
$ dig[Invio]
Se il servente DNS è appena stato riavviato e non è disponibile una connessione con l'esterno, si ottiene un responso nullo, dal quale si vede comunque chi ha risposto:
; <<>> DiG 9.2.0 <<>> ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 52215 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;. IN NS ;; Query time: 4 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Wed May 22 16:37:30 2002 ;; MSG SIZE rcvd: 17 |
Alla fine c'è l'indicazione di chi ha risposto e in questo caso si tratta dell'indirizzo 127.0.0.1, ovvero l'elaboratore locale.
Se si è connessi alla rete esterna, si può provare a interrogare il servente per la risoluzione di un nome, per esempio master.swlibero.org.(1)
$ dig master.swlibero.org[Invio]
; <<>> DiG 9.2.0 <<>> master.swlibero.org ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 62987 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2 ;; QUESTION SECTION: ;master.swlibero.org. IN A ;; ANSWER SECTION: master.swlibero.org. 86400 IN A 62.152.34.17 ;; AUTHORITY SECTION: swlibero.org. 86400 IN NS geronimo.keycomm.it. swlibero.org. 86400 IN NS serena.keycomm.it. ;; ADDITIONAL SECTION: geronimo.keycomm.it. 86400 IN A 194.184.116.2 serena.keycomm.it. 86400 IN A 194.184.117.3 ;; Query time: 1251 msec ;; SERVER: 194.184.29.6#53(194.184.29.6) ;; WHEN: Wed May 22 16:45:48 2002 ;; MSG SIZE rcvd: 139 |
Dal momento che il servizio di risoluzione dei nomi locale non dispone di tale informazione, per ottenerla ha dovuto interpellare i vari servizi DNS a partire dal dominio principale (.), fino a quando ha potuto ricevere la risposta. Per evitare di appesantire la rete in caso di richieste analoghe, il nome e l'indirizzo corrispondente vengono memorizzati in modo temporaneo, nella memoria cache.
Quando il servizio di risoluzione dei nomi interpellato è competente per la zona richiesta e non deve rivolgersi altrove per ottenere la risposta, si ha una risposta «autorevole»; diversamente, la risposta generata dalle informazioni accumulate in una memoria provvisoria, non è autorevole.
Per controllare se i file di zona di competenza del servizio di risoluzione dei nomi locale sono corretti, conviene cambiare il tipo di interrogazione, facendo riferimento a tutti i tipi di record della zona che interessa (in questo caso brot.dg), attraverso la parola chiave any:
$ dig brot.dg any[Invio]
; <<>> DiG 9.2.0 <<>> brot.dg any ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 60850 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 2 ;; QUESTION SECTION: ;brot.dg. IN ANY ;; ANSWER SECTION: brot.dg. 86400 IN SOA (segue) |
A questo punto è necessario analizzare un po' meglio la sintassi del contenuto dei vari file di configurazione utilizzati da named. Il loro significato può essere apprezzato solo dopo il conforto di alcuni esperimenti riusciti con il sistema di risoluzione dei nomi.
Tutti i file di definizione delle zone hanno in comune il modo di indicare i commenti: il punto e virgola fa sì che venga ignorato tutto ciò che appare da quella posizione fino alla fine della riga. Questo valeva anche per il file /etc/named.boot, mentre per il nuovo /etc/named.conf, o /etc/bind/named.conf, i commenti sono introdotti da una doppia barra obliqua, oppure sono delimitati come si fa nel linguaggio C: /*...*/.
Il file named.conf è già stato visto più volte nel capitolo precedente. Si riprende qui il solito esempio, con la differenza che la directory predefinita per i file è quella comune.
options {
directory "/var/cache/bind";
listen-on-v6 { any; };
};
zone "." {
type hint;
file "/etc/bind/named.root";
};
zone "0.0.127.in-addr.arpa" {
type master;
file "/etc/bind/zone/127.0.0";
};
zone "1.168.192.in-addr.arpa" {
type master;
file "/etc/bind/zone/192.168.1";
};
zone "\[xfec0000000000001/64].ip6.arpa" {
type master;
file "/etc/bind/zone/fec0:0:0:1";
};
zone "dg" {
type master;
file "/etc/bind/zone/dg";
};
zone "brot.dg" {
type master;
file "/etc/bind/zone/brot.dg";
};
|
Segue l'elenco e la descrizione delle direttive e delle opzioni più importanti di questo file.
options
options {
opzione;
...
};
La direttiva options serve a definire una serie di opzioni generali. La più comune è directory, con cui si dichiara la directory predefinita a cui fanno riferimento le direttive sulla definizione dei file di zona.
directory
directory directory_di_partenza
L'opzione directory definisce la collocazione predefinita dei file di zona, in modo da permetterne successivamente l'indicazione in modo relativo a questa directory.
forwarders
forwarders {
indirizzo_numerico;
...
};
L'opzione forwarders dichiara che il servizio di risoluzione dei nomi locale può interpellare a sua volta altri servizi, indicati da indirizzi numerici, per le richieste che non dovesse riuscire a risolvere.
|
È indispensabile utilizzare questa opzione se il proprio elaboratore è difeso da un firewall che impedisce il transito di pacchetti UDP. |
forward only
forward only;
L'opzione forward only serve a specificare che si tratta di un servizio di risoluzione dei nomi slave, che cioè rinvia sistematicamente ogni richiesta agli indirizzi indicati nell'opzione forwarders.
listen-on-v6
listen-on-v6 [port n] { any; | none;};
Consente o esclude l'ascolto per le interrogazioni IPv6 dalla porta indicata. Se la porta non viene indicata, si fa riferimento implicitamente al numero 53.
zone
La direttiva zone serve a fare riferimento a una zona; ma ciò può avvenire in modi diversi, che vengono descritti nelle sezioni seguenti.
|
È importante sottolineare che in questo file non si usa il punto finale per indicare domini assoluti. I domini sono sempre indicati esattamente come sono, senza sottintendere alcunché, pertanto il punto finale sarebbe solo un errore. |
zone "." {
type hint;
file file_di_zona;
};
In questo modo si indica il file contenente le informazioni necessarie a raggiungere i DNS del dominio principale. In tal modo, il DNS locale conserverà una memoria cache delle informazioni ottenute, in modo da non dover interrogare ogni volta tutti i DNS esterni necessari.
Senza una direttiva zone che faccia riferimento al dominio principale, named non ha modo di accedere ad altri servizi di risoluzione dei nomi al di fuori del suo stretto ambito di competenza.
Si fa a meno della specificazione di questa zona quando si gestisce un servizio di risoluzione dei nomi a uso esclusivo di una rete locale chiusa, senza accesso all'esterno. Si può fare a meno di questo record quando si utilizzano serventi di inoltro, ovvero i forwarder.
zone "dominio" {
type master;
file file_di_zona;
};
Quando la direttiva zone serve a indicare una zona su cui si ha autorità, attraverso l'opzione type master si stabilisce che le informazioni su questa devono essere tratte dal file indicato.
La zona può essere riferita a un dominio normale, oppure a domini in-addr.arpa e ip6.arpa (ip6.int è obsoleto). Nel primo caso, le informazioni del file servono a tradurre i nomi di dominio in indirizzi numerici; nel secondo, dal momento che i domini in-addr.arpa e ip6.arpa contengono nel nome l'informazione dell'indirizzo numerico, i file servono a tradurre gli indirizzi numerici in nomi di dominio normale.
Convenzionalmente, è sempre presente una direttiva zone riferita al dominio 0.0.127.in-addr.arpa che indica il file in grado di tradurre gli indirizzi di loopback per IPv4.(2)
zone "dominio" {
type slave;
file file_di_zona;
masters {
indirizzo_ip_master;
...
};
};
Il DNS locale può servire a fornire informazioni per cui è autorevole assieme ad altri, da cui trae periodicamente le informazioni. In pratica, l'opzione type slave definisce che il file specificato deve essere generato automaticamente e aggiornato, in base a quanto fornito per quel dominio da altri DNS elencati nell'opzione masters.
|
In questi casi è bene che il file di zona sia collocato al di sotto di |
Se i servizi di risoluzione dei nomi esterni dovessero risultare inaccessibili per qualche tempo, quello locale può continuare a fornire le informazioni, fino a quando queste raggiungono il periodo di scadenza.
I file di zona costituiscono in pratica la base di dati DNS dell'ambito in cui il sistema è autorevole. Sono costituiti da una serie di record di tipo diverso, detti RR (Resource record) o record di risorsa, ma con una sintassi comune.
[dominio] [durata_vitale] [classe] tipo dati_della_risorsa
I campi sono separati da spazi o caratteri di tabulazione; inoltre, un record può essere suddiviso in più righe reali, come si fa solitamente con il tipo SOA.
Ogni file di zona è associato a un dominio di origine definito all'interno del file named.conf nella direttiva che nomina il file di zona in questione. All'interno dei file di zona, il simbolo @ rappresenta questo dominio di origine. Questo simbolo viene utilizzato comunemente solo nel record SOA.
Segue l'elenco dei vari campi dei record di risorsa contenuti nei file di zona.
Il primo campo indica il dominio a cui gli altri elementi del record fanno riferimento. Se non viene specificato, si intende che si tratti di quello dichiarato nel record precedente. Il dominio può essere indicato in modo assoluto, quando termina con un punto, o relativo al dominio di origine.
Il secondo campo indica il tempo di validità dell'informazione, espressa in secondi. Serve solo per i serventi secondari (slave) che hanno la necessità di sapere per quanto tempo deve essere considerata valida un'informazione, prima di eliminarla in mancanza di riscontri dal servente primario (master). Generalmente, questa informazione non viene indicata, perché così si utilizza implicitamente quanto indicato nel record SOA, nell'ultimo campo numerico (minimum). Questa informazione viene definita TTL (Time to live) e non va confusa con altri tipi di TTL esistenti e riferiti a contesti diversi.(3)
Il terzo campo rappresenta la classe di indirizzamento. Con le reti TCP/IP si usa la sigla IN (Internet). Se non viene indicata la classe, si intende fare riferimento implicitamente alla stessa classe del record precedente. Generalmente si mette solo nel primo: il record SOA.
Il quarto campo rappresenta il tipo di record indicato con le sigle già viste nel capitolo precedente.
Dopo il quarto campo seguono i dati particolari del tipo specifico di record. Questi sono già stati descritti in parte in questo capitolo.
Nei record di risorsa può apparire il simbolo @ che rappresenta il dominio di origine, cioè quello indicato nella direttiva del file named.conf corrispondente alla zona in questione.
Nelle sezioni seguenti vengono descritti i record di risorsa più importanti.
Il primo record di ogni file di zona inizia con la dichiarazione standard dell'origine. Ciò avviene generalmente attraverso il simbolo @ che rappresenta il dominio di origine, come già accennato in precedenza. Per esempio, nel file named.conf, la direttiva seguente fa riferimento al file di zona /etc/bind/zone/brot.dg.
zone "brot.dg" {
type master;
file "/etc/bind/zone/brot.dg";
};
|
In tal caso, il simbolo @ del primo record del file /etc/bind/zone/brot.dg rappresenta precisamente il dominio brot.dg.
@ IN SOA dinkel.brot.dg. root.dinkel.brot.dg. (
1998031800
28800
7200
604800
86400 )
|
Sarebbe quindi come se fosse stato scritto nel modo seguente:
brot.dg. IN SOA ...
Tutti i nomi di dominio che dovessero essere indicati senza il punto finale sono considerati relativi al dominio di origine. Per esempio, nello stesso record appare il nome dinkel.brot.dg. che rappresenta un dominio assoluto. Al suo posto sarebbe stato possibile scrivere solo dinkel, senza punto finale, perché verrebbe completato correttamente dal dominio di origine.(4)
La sintassi completa del record SOA potrebbe essere espressa nel modo seguente:
dominio classe SOA servente_primario contatto (
numero_seriale
refresh
retry
expire
minimum )
Nell'esempio visto, la parola chiave IN rappresenta la classe di indirizzamento, Internet, ed è praticamente obbligatorio il suo utilizzo, almeno nel record SOA.
La parola chiave SOA definisce il tipo di record, Start of authority; inoltre deve trattarsi del primo record di un file di zona. Segue la descrizione dei dati specifici di questo tipo di record, precisamente ciò che segue la parola chiave SOA.
Il nome canonico dell'elaboratore che svolge la funzione di servente DNS primario per il dominio indicato all'inizio del record. Convenzionalmente, si indica un nome di dominio assoluto.
L'indirizzo di posta elettronica della persona responsabile per la gestione del servizio. Dal momento che il simbolo @ ha un significato speciale per questi record, lo si sostituisce con un punto. Il nome root.dinkel.brot.dg. deve essere interpretato come root@dinkel.brot.dg.(5)
Il numero di serie serve ai serventi DNS secondari per sapere quando i dati sono stati modificati. Il numero deve essere progressivo. È consentito l'uso di 10 cifre numeriche, pertanto, generalmente si indica la data (in formato aaaammgg) seguita da due cifre aggiuntive. Ogni volta che si modifica il file di zona, questo numero deve essere incrementato; utilizzando la data come in questo esempio si hanno a disposizione le ultime due cifre per indicare diverse versioni riferite allo stesso giorno.
Il numero definito come refresh rappresenta l'intervallo in secondi tra una verifica e la successiva da parte di un servente DNS secondario per determinare se i dati sono stati modificati. Come già specificato, questa verifica si basa sul confronto del numero di serie: se è aumentato, il servente DNS deve rileggere i dati di questo file.
Il numero definito come retry rappresenta l'intervallo in secondi tra una tentativo fallito di accedere al servente DNS e il successivo. In pratica, quando il servente DNS primario è inattivo, i serventi secondari continuano a funzionare e fornire il loro servizio, tuttavia, a intervalli regolari tentano di contattare il servente primario. Questo intervallo è generalmente più corto del tempo di refresh, ma non troppo breve, per non sovraccaricare inutilmente la rete con richieste inutili.
Il numero definito come expire rappresenta la durata massima di validità dei dati quando il servente DNS secondario non riesce più a raggiungere quello primario. In situazioni normali può trattarsi di un valore molto grande, per esempio un mese, anche se negli esempi mostrati in questo capitolo è stato usato un valore molto inferiore.
Il numero definito come minimum rappresenta il tempo predefinito di validità per gli altri record di risorsa. Anche questo valore, se ciò è conveniente, può essere piuttosto grande.
Il secondo record è generalmente quello che indica il nome del nodo che offre il servizio di risoluzione dei nomi, ovvero il servente DNS, come nell'esempio seguente:
NS dinkel.brot.dg. |
La parola chiave NS sta appunto a indicare di che record si tratta. In un file di zona possono apparire più record NS, quando si vuole demandare parte della risoluzione di quella zona ad altri serventi DNS, oppure quando si vogliono semplicemente affiancare.
Questo record viene usato generalmente senza l'indicazione esplicita del dominio e della classe, dal momento che può fare riferimento a quelli già dichiarati nel record SOA. Sotto questo punto di vista, l'esempio appena mostrato corrisponde alla trasformazione seguente:
@ IN NS dinkel.brot.dg. |
Il nome del servente DNS dovrebbe essere un nome canonico, cioè un nome per il quale esiste un record di tipo A corrispondente.
Nei file di zona utilizzati per tradurre i nomi di dominio in indirizzi numerici, dopo l'indicazione dei record NS, si possono trovare uno o più record che rappresentano i servizi per lo scambio della posta elettronica (serventi SMTP). La sintassi precisa è la seguente:
dominio classe MX precedenza host
Si osservi l'esempio.
MX 10 dinkel.brot.dg.
MX 20 roggen.brot.dg.
|
Qui appaiono due record di questo tipo. La parola chiave MX indica il tipo di record; il numero che segue rappresenta il livello di precedenza; il nome finale rappresenta il nodo che offre il servizio di scambio di posta elettronica. Nell'esempio, si vuole fare in modo che il primo servizio a essere interpellato sia quello dell'elaboratore dinkel.brot.dg e se questo non risponde si presenta l'alternativa data da roggen.brot.dg.
Anche qui sono state omesse le indicazioni del dominio e della classe di indirizzamento, in modo da utilizzare implicitamente quelle della dichiarazione precedente. Anche in questo caso, l'intenzione era quella di fare riferimento al dominio di origine e alla classe IN.
@ IN MX 10 dinkel.brot.dg. @ IN MX 20 roggen.brot.dg. |
I file di zona utilizzati per tradurre i nomi di dominio in indirizzi numerici sono fatti essenzialmente per contenere record di tipo A, AAAA e A6, ovvero record di indirizzo, che permettono di definire le corrispondenze tra nomi e indirizzi numerici.
dinkel.brot.dg. A 192.168.1.1 dinkel.brot.dg. A6 0 fec0:0:0:1:0:0:0:1 roggen.brot.dg. A 192.168.1.2 roggen.brot.dg. A6 0 fec0:0:0:1:0:0:0:2 |
Nell'esempio si mostrano quattro di questi record. Il primo, in particolare, indica che il nome roggen.brot.dg corrisponde all'indirizzo numerico 192.168.1.1, IPv4, mentre il secondo indica che lo stesso nome corrisponde all'indirizzo fec0:0:0:1:0:0:0:1 per IPv6.
Da questo si comprende che i record A riguardano indirizzi IPv4, mentre i record A6 riguardano indirizzi IPv6. I record AAAA sono obsoleti e servivano anche questi per ottenere gli indirizzi IPv6. L'esempio seguente riguarda l'uso di un record AAAA:
dinkel.brot.dg. AAAA fec0:0:0:1:0:0:0:1 |
Come già accennato in precedenza, i nomi possono essere indicati in forma abbreviata, relativi al dominio di origine per cui è stato definito il file di zona; in questo caso si tratta di brot.dg. Per cui, i quattro record appena mostrati avrebbero potuto essere rappresentati nella forma seguente:
dinkel A 192.168.1.1 dinkel A6 0 fec0:0:0:1:0:0:0:1 roggen A 192.168.1.2 roggen A6 0 fec0:0:0:1:0:0:0:2 |
È possibile attribuire nomi diversi allo stesso indirizzo numerico, come nell'esempio seguente. Non si tratta di alias, ma di nomi diversi che vengono tradotti nello stesso indirizzo reale.
dinkel.brot.dg. A 192.168.1.1 roggen.brot.dg. A 192.168.1.2 farro.brot.dg. A 192.168.1.1 segale.brot.dg. A 192.168.1.2
Questo tipo di record prevede anche la possibilità di utilizzare l'indicazione della durata di validità (TTL) e della classe. Come al solito, se la classe non viene utilizzata, si fa riferimento alla classe del record precedente, mentre per quanto riguarda la durata di validità, vale quanto definito come minimum nel record SOA. Dagli esempi già mostrati, i quattro record di questa sezione potrebbero essere scritti nel modo seguente:
dinkel.brot.dg. 86400 IN A 192.168.1.1 dinkel.brot.dg. 86400 IN A6 0 fec0:0:0:1:0:0:0:1 roggen.brot.dg. 86400 IN A 192.168.1.2 roggen.brot.dg. 86400 IN A6 0 fec0:0:0:1:0:0:0:2 |
Nei file di zona utilizzati per tradurre i nomi di dominio che appartengono a .arpa in nomi di dominio normale, cioè quelli che servono a ottenere il nome a partire dall'indirizzo numerico, si utilizzano i record PTR (o record puntatori) con questo scopo.
1 PTR dinkel.brot.dg. 2 PTR roggen.brot.dg. |
L'esempio dei due record che appaiono sopra si riferisce a indirizzi IPv4, con un significato intuitivo, ma non necessariamente chiaro. Il numero che appare all'inizio è un nome di dominio abbreviato, riferito all'origine 1.168.192.in-addr.arpa, per cui, volendo indicare nomi di dominio completi, si dovrebbe fare come nell'esempio seguente:
1.1.168.192.in-addr.arpa. PTR dinkel.brot.dg. 2.1.168.192.in-addr.arpa. PTR roggen.brot.dg. |
Dovrebbe essere più chiaro adesso che i record PTR rappresentano un collegamento tra un nome di dominio e un altro. È comunque solo attraverso questo meccanismo che si può ottenere una traduzione degli indirizzi numerici in nomi di dominio.
È il caso di considerare il fatto che attraverso i record A e A6 possono essere abbinati più nomi di dominio allo stesso indirizzo numerico, ma con i record PTR si può abbinare un indirizzo numerico a un solo nome di dominio. Cioè a dire che quando si chiede il nome corrispondente a un indirizzo numerico se ne ottiene uno solo. Anche per questo, è necessario che il nome di dominio indicato corrisponda a un nome canonico.
Con indirizzi IPv6 si usa una notazione particolare:
\[x0000000000000001/64] PTR dinkel.brot.dg. \[x0000000000000002/64] PTR roggen.brot.dg. |
Qui la stringa \[x0000000000000001/64] fa riferimento esplicito a un numero esadecimale, 000000000000000116, in cui vanno presi in considerazione gli ultimi 64 bit. Questa stringa va attaccata alla stringa corrispondente che rappresenta il dominio di origine, come indicato nel file named.conf:
zone "\[xfec0000000000001/64].ip6.arpa" {
type master;
file "/etc/bind/zone/fec0:0:0:1";
};
|
Pertanto, si intende fare riferimento all'indirizzo fec0000000000001000000000000000116, ovvero fec0:0000:0000:0001:0000:0000:0000:0001, ovvero fec0:0:0:1:0:0:0:1.
In passato è esistito anche un altro modo per rappresentare un indirizzo IPv6, attraverso il dominio obsoleto ip6.int. Anche se si tratta di un sistema superato, vale la pena di annotare il meccanismo. Nel file named.conf si indicava il dominio come:
zone "1.0.0.0.0.0.0.0.0.0.0.0.0.c.e.f.IP6.INT" {
type master;
file "fec0:0:0:1";
};
|
Come si intuisce, si tratta di un dominio ottenuto da tutte le cifre esadecimali che compongono la prima parte dell'indirizzo. Nel file di zona, si continuava il dominio:
1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0 PTR dinkel.brot.dg. 2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0 PTR roggen.brot.dg. |
oppure lo si scriveva per esteso, come già si può fare per in-addr.arpa:
1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.1.0.0.0.0.0.0.0.0.0.0.0.0.c.e.f.IP6.INT (segue) |
|
Nella documentazione originale, questa notazione è nota con il termine nibble (usato come aggettivo), perché questo è il nome che un tempo veniva dato ai gruppetti di 4 bit (mezzo byte), dal momento che i domini |
Naturalmente, anche per il record PTR valgono le considerazioni fatte per il tipo A e A6, riguardo all'indicazione della durata di validità e alla classe di indirizzamento.
Nei file di zona utilizzati per tradurre i nomi di dominio in indirizzi numerici possono apparire dei record CNAME, che permettono di definire degli alias a nomi di dominio già definiti (i nomi canonici).
www.dinkel.brot.dg. CNAME dinkel.brot.dg. ftp.dinkel.brot.dg. CNAME dinkel.brot.dg. |
L'esempio dei due record appena mostrati, indica che i nomi www.dinkel.brot.dg e ftp.dinkel.brot.dg sono alias del nome canonico dinkel.brot.dg.
Teoricamente si può fare la stessa cosa utilizzando record di tipo A e di tipo A6 con la differenza che i nomi vanno abbinati a un indirizzo numerico. L'utilità del record CNAME sta nella facilità con cui possono essere cambiati gli indirizzi: in questo caso, basta modificare l'indirizzo numerico di dinkel.brot.dg e gli alias non hanno bisogno di altre modifiche.
Tuttavia, l'uso di alias definiti attraverso record CNAME è altamente sconsigliabile nella maggior parte delle situazioni. Questo significa che nei record SOA, NS, MX e CNAME, è meglio indicare sempre solo nomi di dominio per cui esiste la definizione di corrispondenza attraverso un record A o A6. In pratica, i record CNAME andrebbero usati solo per mostrare all'esterno nomi alternativi esteticamente più adatti alle varie circostanze, come nell'esempio mostrato in cui si aggiunge il prefisso www e ftp.
|
In particolare, nel record SOA è assolutamente vietato utilizzare nomi definiti come alias. |
Nelle sezioni precedenti sono stati descritti i vari record di risorsa e il loro utilizzo nei file di zona. Il file utilizzato per elencare i serventi DNS principali contiene esclusivamente due tipi di record: NS e A.
I record NS servono a indicare i nomi dei vari serventi DNS competenti per il dominio principale; i record A forniscono la traduzione di questi nomi in indirizzi numerici. Ciò è esattamente quanto serve in questo tipo di file.
. 3600000 IN NS A.ROOT-SERVERS.NET. A.ROOT-SERVERS.NET. 3600000 A 198.41.0.4 |
Un servente DNS secondario, o slave, è quello che riproduce le informazioni di altri serventi, controllando la validità a intervalli regolari, aggiornando i dati quando necessario.
Supponendo di volere realizzare un servente DNS secondario nell'elaboratore roggen.brot.dg, per seguire gli esempi già mostrati, si può semplicemente definire il file named.conf come nell'esempio seguente:
options {
directory "/var/cache/bind";
};
//
zone "." {
type hint;
file "/etc/bind/named.root";
};
//
zone "0.0.127.in-addr.arpa" {
type master;
file "/etc/bind/zone/127.0.0";
};
//
zone "1.168.192.in-addr.arpa" {
type slave;
file "zone/192.168.1";
masters {
192.168.1.1;
};
};
zone "\[xfec0000000000001/64].ip6.arpa" {
type slave;
file "zone/fec0:0:0:1";
masters {
192.168.1.1;
};
};
zone "dg" {
type slave;
file "zone/dg";
masters {
192.168.1.1;
};
};
zone "brot.dg" {
type slave;
file "zone/brot.dg";
masters {
192.168.1.1;
};
};
<listing sep="rule" pos="fixed" split="0">
|
I file /etc/bind/named.root e /etc/bind/zone/127.0.0 sono i soliti già visti per il caso del servente primario. In questo modo, il servente DNS secondario è in grado di risolvere da solo le richieste al di fuori delle zone di competenza.
Le direttive di dichiarazione di zona che contengono l'opzione type slave servono a fare in modo che il DNS locale risponda alle richieste riferite a queste, anche se poi a sua volta deve aggiornare i file relativi in base a quanto ottenuto dai DNS indicati nell'opzione masters.
|
Si osservi che in questo caso, le zone copiate dal DNS primario sono inserite in file collocati al di sotto di |
Un servente DNS di inoltro, o forwarder, è quello che rinvia le richieste a un altro servizio di risoluzione dei nomi.
Supponendo di volere realizzare un servente DNS di inoltro nell'elaboratore roggen.brot.dg, per seguire gli esempi già mostrati, si può semplicemente definire il file named.conf come nell'esempio seguente:
options {
directory "/var/cache/bind";
forward only;
forwarders {
192.168.1.1;
};
};
//
zone "0.0.127.in-addr.arpa" {
type master;
file "/etc/bind/zone/127.0.0";
};
|
Si può osservare l'assenza della dichiarazione della zona del dominio principale. Solo il dominio 0.0.127.in-addr.arpa viene risolto localmente, tutto il resto viene richiesto al DNS corrispondente all'indirizzo 192.168.1.1. L'opzione forward only sottolinea questo fatto.
Tavis Barr, Nicolai Langfeldt, Seth Vidal, NFS HOWTO
<http://www.linux.org/docs/ldp/howto/HOWTO-INDEX/howtos.html>
Olaf Kirch, NAG, The Linux Network Administrators' Guide
BOG, Bind Operations Guide
named(8)
Bind 9 administrator reference manual, 2001, Internet Software Consortium
daniele @ swlibero.org1) L'esempio proposto riguarda la situazione di un certo momento. Se si tenta di ripetere l'esempio, è probabile che il risultato sia differente, soprattutto per ciò che riguarda i numeri IP attribuiti ai vari nodi che si incontrano.
2) Eventualmente, potrebbe essere conveniente anche la presenza di una direttiva zone riferita al dominio \[x00000000000000000000000000000001/128].ip6.arpa, per la traduzione dell'indirizzo ::1 IPv6.
3) Per esempio, si parla di TTL anche a proposito di pacchetti IP, ma in quel caso si intende indicare il numero massimo di salti (attraverso i router) che questi possono fare.
4) Tuttavia, in un record SOA è preferibile indicare solo nomi di dominio assoluti.
5) Di conseguenza, indirizzi di posta elettronica del tipo mario.rossi@brot.dg non si possono usare, perché contengono il punto prima della chiocciola.
Dovrebbe essere possibile fare riferimento a questa pagina anche con il nome dns_dettagli_ulteriori.html
[successivo] [precedente] [inizio] [fine] [indice generale] [violazione GPL] [translators] [docinfo] [indice analitico]