[successivo] [precedente] [inizio] [fine] [indice generale] [indice ridotto] [indice analitico] [volume] [parte]


Capitolo 273.   DNS: dettagli ulteriori

Dopo l'introduzione del capitolo precedente sul DNS, è bene approfondire un po' la configurazione di questo servizio.

273.1   Verificare il funzionamento del 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 \
  \'/etc/bind/named.conf' May 31 15:20:56 dinkel named[2780]: listening on IPv6 interfaces, port 53 May 31 15:20:56 dinkel named[2780]: binding TCP socket: address in use May 31 15:20:56 dinkel named[2780]: listening on IPv4 interface lo, 127.0.0.1#53 May 31 15:20:56 dinkel named[2780]: binding TCP socket: address in use May 31 15:20:56 dinkel named[2780]: listening on IPv4 interface eth0, \
  \192.168.1.1#53 May 31 15:20:56 dinkel named[2780]: binding TCP socket: address in use May 31 15:20:56 dinkel named[2780]: zone 127.0.0.in-addr.arpa/IN: loaded \
  \serial 1 May 31 15:20:56 dinkel named[2780]: 192.168.1:1: no TTL specified; using SOA \
  \MINTTL instead May 31 15:20:56 dinkel named[2780]: zone 1.168.192.in-addr.arpa/IN: loaded \
  \serial 1998031800 May 31 15:20:56 dinkel named[2780]: 192.168.2:1: no TTL specified; using SOA \
  \MINTTL instead May 31 15:20:56 dinkel named[2780]: zone 2.168.192.in-addr.arpa/IN: loaded \
  \serial 1998031800 May 31 15:20:56 dinkel named[2780]: fec0:0:0:1:1: no TTL specified; using SOA \
  \MINTTL instead May 31 15:20:56 dinkel named[2780]: zone \[xFEC0000000000001/64].ip6.arpa/IN: \
  \loaded serial 1998031800 May 31 15:20:56 dinkel named[2780]: dg:1: no TTL specified; using SOA MINTTL \
  \instead May 31 15:20:56 dinkel named[2780]: zone dg/IN: loaded serial 1998031800 May 31 15:20:56 dinkel named[2780]: brot.dg:1: no TTL specified; using SOA \
  \MINTTL instead May 31 15:20:56 dinkel named[2780]: zone brot.dg/IN: loaded serial 1998031800 May 31 15:20:56 dinkel named[2780]: zone localhost/IN: loaded serial 1 May 31 15:20:56 dinkel named[2780]: running

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 felix.swlibero.org.(1)

dig felix.swlibero.org[Invio]

; <<>> DiG 9.2.0 <<>> felix.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:
;felix.swlibero.org.           IN      A

;; ANSWER SECTION:
felix.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     \
  \dinkel.brot.dg. root.dinkel.brot.dg. 1998031800 28800 7200 604800 86400 brot.dg. 86400 IN NS dinkel.brot.dg. brot.dg. 86400 IN MX 10 dinkel.brot.dg. ;; ADDITIONAL SECTION: dinkel.brot.dg. 86400 IN A 192.168.1.1 ;; Query time: 4 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Wed May 22 17:05:12 2002 ;; MSG SIZE rcvd: 147

273.2   File di configurazione più in dettaglio

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: /*...*/.

273.2.1   File «/etc/named.conf» o «/etc/bind/named.conf»

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.

Tabella 273.6. Alcune direttive e opzioni. Si osservi che le parentesi graffe fanno parte delle direttive e sono da intendersi in senso letterale.

Opzione Descrizione
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.
options {
...
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.
options {
...
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.
Si osservi che è indispensabile utilizzare questa opzione se il proprio elaboratore è difeso da un firewall che impedisce il transito di pacchetti UDP.
options {
...
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.
options {
...
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 "dominio" {
...
};
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.

273.2.2   Memoria cache del dominio principale

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. Il DNS locale conserva 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.

273.2.3   Gestione delle zone su cui si ha autorità

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)

273.2.4   Riproduzione delle informazioni di un altro DNS

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 /var/cache/bind/, proprio per la sua dinamicità. Diversamente, è conveniente che i file di zona sui quali si ha il controllo si trovino a partire dalla directory /etc/bind/.

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.

273.2.5   File di zona

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.

  1. 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.

  2. 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)

  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.

  4. Il quarto campo rappresenta il tipo di record indicato con le sigle già viste nel capitolo precedente.

  5. 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.

273.2.6   SOA -- Start of authority

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.

273.2.7   NS -- Name Server

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.

273.2.8   MX -- Mail Exchanger

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 nodo

Si osservi l'esempio seguente:

                        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 è quella di fare riferimento al dominio di origine e alla classe IN.

@               IN      MX      10      dinkel.brot.dg.
@               IN      MX      20      roggen.brot.dg.

273.2.9   A, AAAA, A6 -- Address

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

273.2.10   PTR -- Pointer

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 \
  \PTR dinkel.brot.dg. 2.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 \
  \PTR roggen.brot.dg.

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 ip6.int si scompongono seguendo le cifre esadecimali, ognuna delle quali occupa 4 bit.

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.

273.2.11   CNAME -- Canonical Name

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.

273.2.12   File dei serventi principali

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

273.3   Serventi DNS secondari

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;
        };
};

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 /var/cache/bind/, dal momento che sono stati usati percorsi relativi. Per esempio, il file /var/cache/bind/zone/192.168.1 serve a contenere la zona relativa agli indirizzi 192.168.1.*.

273.4   Servente DNS di inoltro

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.

273.5   Riferimenti

Appunti di informatica libera 2007.02 --- Copyright © 2000-2007 Daniele Giacomini -- <daniele (ad) swlibero·org>


1) 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.htm

[successivo] [precedente] [inizio] [fine] [indice generale] [indice ridotto] [indice analitico]

Valid ISO-HTML!

CSS validator!