[inizio] [indice generale] [precedente] [successivo] [indice analitico] [contributi]


94. DNS: dettagli ulteriori

Dopo l'introduzione del capitolo precedente sul DNS, è bene approfondire un po' l'argomento attraverso delle prove pratiche e studiando in modo più dettagliato la configurazione di questo servizio.

94.1 Verifiche

Per comprendere il servizio DNS è utile fare qualche esperimento. Per prima cosa ci si deve accertare del funzionamento del servizio di risoluzione dei nomi predefinito, quindi si può esplorare la rete per vedere dove sono collocati i servizi di risoluzione dei nomi competenti per le varie zone.

94.1.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 lo script `ndc'.

ndc stop[Invio]

ndc start[Invio]

Il demone `named' emette alcuni messaggi che vengono annotati nel registro del sistema, generalmente nel file `/var/log/messages'. È 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.

Dec 23 09:41:04 dinkel named[538]: starting.  named 8.1.2
Dec 23 09:41:05 dinkel named[538]: master zone "0.0.127.in-addr.arpa" loaded
Dec 23 09:41:05 dinkel named[538]: master zone "1.168.192.in-addr.arpa" loaded
Dec 23 09:41:05 dinkel named[538]: master zone "brot.dg" loaded
Dec 23 09:41:05 dinkel named[538]: listening on [127.0.0.1].53 (lo)
Dec 23 09:41:05 dinkel named[538]: listening on [192.168.1.1].53 (eth0)
Dec 23 09:41:05 dinkel named[538]: Forwarding source address is [0.0.0.0].1027
Dec 23 09:41:05 dinkel named[539]: Ready to answer queries.

Se qualcosa non va, è lo stesso `named' ad avvisare attraverso questi messaggi. Se è andato tutto bene si può provare a vedere cosa accade avviando `nslookup'.

nslookup[Invio]

Default Server: localhost.localdomain
Address:  127.0.0.1

>

Avviando `nslookup' senza argomenti, si fa in modo che questo interpelli il servizio di risoluzione dei nomi predefinito, cioè quello indicato nel file `/etc/resolv.conf'. Trattandosi del servizio locale, ne viene visualizzato il nome e l'indirizzo; quindi `nslookup' si accinge a ricevere dei comandi.

Se si è connessi alla rete esterna, si può provare a interrogare il servente per la risoluzione di un nome, per esempio `pluto.linux.it'. *1*

pluto.linux.it[Invio]

Server: localhost.localdomain
Address:  127.0.0.1

Name:    pluto.linux.it
Address:  194.184.117.4

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.

Dal momento che tale procedura è abbastanza dispendiosa, il nome e l'indirizzo corrispondente vengono memorizzati in modo temporaneo, nella memoria cache.

pluto.linux.it[Invio]

Server: localhost.localdomain
Address:  127.0.0.1

Non-authoritative answer:
Name:    pluto.linux.it
Address:  194.184.117.4

Quando il servizio di risoluzione dei nomi interpellato è in grado di rispondere da solo, in base a quanto archiviato nella sua memoria transitoria, si ottiene una cosiddetta risposta 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.

set q=any[Invio]

Quindi si interpella la zona di competenza, cioè `brot.dg', seguendo gli esempi già mostrati.

brot.dg[Invio]

brot.dg
        origin = dinkel.brot.dg
        mail addr = root.dinkel.brot.dg
        serial = 1998031800
        refresh = 28800 (8 hours)
        retry   = 7200 (2 hours)
        expire  = 604800 (7 days)
        minimum ttl = 86400 (1 day)
brot.dg		nameserver = dinkel.brot.dg
brot.dg		preference = 10, mail exchanger = dinkel.brot.dg
brot.dg		nameserver = dinkel.brot.dg
dinkel.brot.dg	internet address = 192.168.1.1
>

ls -t any brot.dg[Invio]

[localhost.localdomain]
 brot.dg.			SOA   dinkel.brot.dg root.dinkel.brot.dg.
     (1998031800 28800 7200 604800 86400)
 brot.dg.			NS    dinkel.brot.dg
 brot.dg.			MX    10   dinkel.brot.dg
 roggen.brot.dg			A     192.168.1.2
 dinkel.brot.dg			A     192.168.1.1
 ftp.brot.dg			CNAME dinkel.brot.dg
 www.brot.dg			CNAME dinkel.brot.dg
 brot.dg.			SOA   dinkel.brot.dg root.dinkel.brot.dg.
     (1998031800 28800 7200 604800 86400)

Si conclude l'attività di `nslookup' con il comando `exit'.

exit[Invio]

94.1.2 Risoluzione distribuita dei nomi

Non si può comprendere il meccanismo con cui si risolvono i nomi a livello della rete globale se non si fanno delle prove. Nelle descrizioni seguenti si vuole raggiungere il nodo `pluto.linux.it' facendo una ricerca a partire da uno dei servizi di risoluzione dei nomi principali, discendendo lentamente fino a raggiungere l'ultimo contenente effettivamente le informazioni relative.

Si inizia avviando il programma `nslookup' in modo da interpellare un servente di quelli del dominio principale, per esempio `i.root-servers.net'. Nel comando che segue, il nome viene indicato con il punto finale, per sottolineare che si tratta di un nome di dominio completo.

nslookup - i.root-servers.net.[Invio]

Server: i.root-servers.net
Address:  192.36.148.17

>

Se tutto va bene, il servente risponde e si può proseguire, altrimenti si può tentare di interpellarne un altro alternativo (`[a-m].root-servers.net').

I servizi di risoluzione dei nomi del dominio principale sono in grado di informare su quali siano i servizi relativi ai domini di primo livello, detti TLD o Top Level Domain. Per esempio, `com', `edu', `net',... `it', sono domini di primo livello.

set q=ns[Invio]

Con questo comando si vuole semplicemente concentrare l'attenzione sui record contenenti le informazioni sui nodi che offrono i servizi di risoluzione dei nomi.

it.[Invio]

Digitando semplicemente il nome del dominio di primo livello `it', si vuole ottenere l'elenco dei nodi in grado di risolvere i nomi che vi appartengono. Il punto finale indicato nella riga di comando, è voluto, e sta a significare che il nome corrisponde esattamente a quello che si vuole, evitando che il sistema possa completarlo con un dominio predefinito.

Server:  i.root-servers.net
Address:  192.36.148.17

Non-authoritative answer:
it      nameserver = SIMON.CS.CORNELL.EDU
it      nameserver = ADMII.ARL.MIL
it      nameserver = NS.EU.NET
it      nameserver = NS2.PSI.NET
it      nameserver = SERVER2.INFN.it
it      nameserver = NAMESERVER.CNR.it
it      nameserver = DNS.NIC.it

Authoritative answers can be found from:
SIMON.CS.CORNELL.EDU    internet address = 128.84.154.10
ADMII.ARL.MIL   internet address = 128.63.31.4
ADMII.ARL.MIL   internet address = 128.63.5.4
NS.EU.NET       internet address = 192.16.202.11
NS2.PSI.NET     internet address = 38.8.50.2
SERVER2.INFN.it internet address = 131.154.1.3
NAMESERVER.CNR.it       internet address = 194.119.192.34
DNS.NIC.it      internet address = 193.205.245.5 

Di questi servizi di risoluzione dei nomi se ne può scegliere uno per continuare l'esplorazione, per esempio quello offerto da `dns.nic.it'. Per indicare a `nslookup' di cambiare servente si deve usare il comando omonimo.

server dns.nic.it[Invio]

> server dns.nic.it
Default Server:  dns.nic.it
Address:  193.205.245.5

>

Da questo servente si desidera conoscere quali altri serventi siano competenti per il dominio `linux.it'.

linux.it.[Invio]

Server:  dns.nic.it
Address:  193.205.245.5

Non-authoritative answer:
linux.it        nameserver = dns2.nic.it
linux.it        nameserver = ns.publinet.it
linux.it        nameserver = soda.com.dist.unige.it

Authoritative answers can be found from:
dns2.nic.it     internet address = 193.205.245.8
ns.publinet.it  internet address = 151.99.137.2
soda.com.dist.unige.it  internet address = 130.251.8.88
>

Si desidera proseguire la ricerca per determinare chi sia competente per il dominio `pluto.linux.it'. Per questo si cambia servente; si prova con `dns2.nic.it'.

server dns2.nic.it[Invio]

> server dns2.nic.it
Default Server:  dns2.nic.it
Address:  193.205.245.8

>

pluto.linux.it.[Invio]

> pluto.linux.it.
Server:  dns2.nic.it
Address:  193.205.245.8

Non-authoritative answer:
pluto.linux.it  nameserver = snoopy.psy.unipd.it
pluto.linux.it  nameserver = ns.publinet.it
pluto.linux.it  nameserver = serena.keycomm.it

Authoritative answers can be found from:
snoopy.psy.unipd.it     internet address = 147.162.126.251
ns.publinet.it  internet address = 151.99.137.2
serena.keycomm.it       internet address = 194.184.117.3
>

Probabilmente, uno di questi serventi è in grado di conoscere direttamente chi sia `pluto.linux.it'. Si prova con `serena.keycomm.it'.

server serena.keycomm.it[Invio]

Default Server:  serena.keycomm.it
Address:  194.184.117.3

>

pluto.linux.it.[Invio]

Server:  serena.keycomm.it
Address:  194.184.117.3

pluto.linux.it  nameserver = snoopy.psy.unipd.it
pluto.linux.it  nameserver = ns.publinet.it
pluto.linux.it  nameserver = serena.keycomm.it
snoopy.psy.unipd.it     internet address = 147.162.126.251
ns.publinet.it  internet address = 151.99.137.2
serena.keycomm.it       internet address = 194.184.117.3

A questo punto si vede che i serventi proposti per risolvere `pluto.linux.it' sono ancora gli stessi di poco prima. Probabilmente si è giunti al termine della catena. Si prova a cambiare tipo di richiesta a `nslookup' abilitando qualunque tipo di informazione sia ottenibile.

set q=any[Invio]

Quindi si prova a chiedere informazioni su `pluto.linux.it'.

pluto.linux.it.[Invio]

Default Server:  serena.keycomm.it
Server:  serena.keycomm.it
Address:  194.184.117.3

pluto.linux.it  text = "PLUTO Linux User Group"
pluto.linux.it  nameserver = snoopy.psy.unipd.it
pluto.linux.it  nameserver = ns.publinet.it
pluto.linux.it  preference = 30, mail exchanger = ilary.keycomm.it
pluto.linux.it  preference = 10, mail exchanger = master.pluto.linux.it
pluto.linux.it
        origin = serena.keycomm.it
        mail addr = dalla.pluto.linux.it
        serial = 1998003020
        refresh = 86400 (1 day)
        retry   = 7200 (2 hours)
        expire  = 2592000 (30 days)
        minimum ttl = 86400 (1 day)
pluto.linux.it  internet address = 194.184.117.4
pluto.linux.it  nameserver = serena.keycomm.it
pluto.linux.it  nameserver = snoopy.psy.unipd.it
pluto.linux.it  nameserver = ns.publinet.it
pluto.linux.it  nameserver = serena.keycomm.it
snoopy.psy.unipd.it     internet address = 147.162.126.251
ns.publinet.it  internet address = 151.99.137.2
ilary.keycomm.it        internet address = 194.184.116.28
master.pluto.linux.it   internet address = 194.184.117.4
serena.keycomm.it       internet address = 194.184.117.3
>

Ormai dovrebbe essere chiaro che `pluto.linux.it' e `serena.keycomm.it' sono la stessa macchina. Per concludere si utilizza il comando `exit'.

exit[Invio]

94.1.3 Risoluzione distribuita del dominio in-addr.arpa

Una delle cose più difficili da capire per un principiante è cosa sia il dominio `in-addr.arpa'. Per questo vale la pena di perdere del tempo a mostrare un esempio che dovrebbe chiarirne il senso. Nella sezione precedente si è visto da un esempio tratto dalla realtà che un solo indirizzo IP può corrispondere a diversi nomi di dominio. In pratica, `pluto.linux.it' e `serena.keycomm.it' hanno in comune solo il dominio di primo livello: `it'. Ciò significa che per tradurre i due nomi, si usano potenzialmente servizi di risoluzione differenti. Questo dovrebbe permettere di capire che teoricamente si possono utilizzare mappe differenti dalle solite per raggiungere gli elaboratori (che sono definiti univocamente solo per mezzo dell'indirizzo IP).

Il dominio `in-addr.arpa' è un dominio alternativo, dal quale si diramano una serie di sottodomini che permettono di raggiungere tutti gli elaboratori della rete che dispongano di un nome di dominio normale. Questi sottodomini sono composti dal numero IP in cui l'ordine degli ottetti appare invertito. Nel caso dell'indirizzo IP 194.184.117.3, il dominio corrispondente `in-addr.arpa' è `3.117.184.194.in-addr.arpa'. Si tratta di un nome di dominio in cui però l'indirizzo IP è implicito perché fa parte del nome, e viene usato per conoscere il nome di dominio normale corrispondente.

La cosa migliore è provare, esattamente come mostrato nella sezione precedente. Si comincia avviando `nslookup'. Anche questa volta si interpella direttamente un servizio di risoluzione dei nomi principale.

nslookup - i.root-servers.net.[Invio]

Server: i.root-servers.net
Address:  192.36.148.17

>

set q=ns[Invio]

Anche questa volta ci si vuole concentrare sui soli record contenenti le informazioni dei nodi che offrono il servizio di risoluzione dei nomi.

in-addr.arpa.[Invio]

Con questa richiesta si vuole conoscere quali nodi siano competenti per la risoluzione del dominio `in-addr.arpa'.

Server:  i.root-servers.net
Address:  192.36.148.17

in-addr.arpa    nameserver = G.ROOT-SERVERS.NET
in-addr.arpa    nameserver = A.ROOT-SERVERS.NET
in-addr.arpa    nameserver = H.ROOT-SERVERS.NET
in-addr.arpa    nameserver = B.ROOT-SERVERS.NET
in-addr.arpa    nameserver = C.ROOT-SERVERS.NET
in-addr.arpa    nameserver = D.ROOT-SERVERS.NET
in-addr.arpa    nameserver = E.ROOT-SERVERS.NET
in-addr.arpa    nameserver = I.ROOT-SERVERS.NET
in-addr.arpa    nameserver = F.ROOT-SERVERS.NET
G.ROOT-SERVERS.NET      internet address = 192.112.36.4
A.ROOT-SERVERS.NET      internet address = 198.41.0.4
H.ROOT-SERVERS.NET      internet address = 128.63.2.53
B.ROOT-SERVERS.NET      internet address = 128.9.0.107
C.ROOT-SERVERS.NET      internet address = 192.33.4.12
D.ROOT-SERVERS.NET      internet address = 128.8.10.90
E.ROOT-SERVERS.NET      internet address = 192.203.230.10
I.ROOT-SERVERS.NET      internet address = 192.36.148.17
F.ROOT-SERVERS.NET      internet address = 192.5.5.241
>

In pratica sono gli stessi servizi di risoluzione dei nomi del dominio principale (quasi tutti). Si prova ad aggiungere il primo ottetto dell'indirizzo IP.

194.in-addr.arpa.[Invio]

Server:  i.root-servers.net
Address:  192.36.148.17

Non-authoritative answer:
194.in-addr.arpa        nameserver = NS.EU.NET
194.in-addr.arpa        nameserver = AUTH03.NS.UU.NET
194.in-addr.arpa        nameserver = NS2.NIC.FR
194.in-addr.arpa        nameserver = SUNIC.SUNET.SE
194.in-addr.arpa        nameserver = MUNNARI.OZ.AU
194.in-addr.arpa        nameserver = TECKLA.APNIC.NET
194.in-addr.arpa        nameserver = NS.RIPE.NET

Authoritative answers can be found from:
NS.EU.NET       internet address = 192.16.202.11
AUTH03.NS.UU.NET        internet address = 198.6.1.83
NS2.NIC.FR      internet address = 192.93.0.4
SUNIC.SUNET.SE  internet address = 192.36.125.2
MUNNARI.OZ.AU   internet address = 128.250.1.21
TECKLA.APNIC.NET        internet address = 202.12.28.129
NS.RIPE.NET     internet address = 193.0.0.193
>

Ecco che i nomi restituiti cambiano. Si decide di interpellare il servizio di risoluzione dei nomi offerto da `ns.eu.net' per continuare la ricerca.

server ns.eu.net[Invio]

Default Server:  ns.eu.net
Address:  192.16.202.11

>

Quindi si chiedono informazioni su `184.194.in-addr.arpa'.

184.194.in-addr.arpa.[Invio]

Server:  ns.eu.net
Address:  192.16.202.11

Non-authoritative answer:
184.194.in-addr.arpa    nameserver = server-b.cs.interbusiness.it
184.194.in-addr.arpa    nameserver = dns.interbusiness.it
184.194.in-addr.arpa    nameserver = ns.ripe.net

Authoritative answers can be found from:
server-b.cs.interbusiness.it    internet address = 151.99.250.2
dns.interbusiness.it    internet address = 151.99.125.2
ns.ripe.net     internet address = 193.0.0.193
>

Per proseguire occorre ancora cambiare servente. Si decide di utilizzare `server-b.cs.interbusiness.it'.

server-b.cs.interbusiness.it[Invio]

Default Server:  server-b.cs.interbusiness.it
Address:  151.99.250.2

>

Quindi si chiedono informazioni su `117.184.194.in-addr.arpa'.

117.184.194.in-addr.arpa.[Invio]

Server:  server-b.cs.interbusiness.it
Address:  151.99.250.2

Non-authoritative answer:
117.184.194.in-addr.arpa        nameserver = dns.interbusiness.it
117.184.194.in-addr.arpa        nameserver = dns.nis.garr.it
117.184.194.in-addr.arpa        nameserver = geronimo.keycomm.it

Authoritative answers can be found from:
dns.interbusiness.it    internet address = 151.99.125.2
dns.nis.garr.it internet address = 193.205.245.8
geronimo.keycomm.it     internet address = 194.184.116.2
>

Ancora un passo prima della fine.

server dns.interbusiness.it[Invio]

Default Server:  dns.interbusiness.it
Address:  151.99.125.2

>

3.117.184.194.in-addr.arpa.[Invio]

Server:  dns.interbusiness.it
Address:  151.99.125.2

117.184.194.in-addr.arpa
        origin = geronimo.keycomm.it
        mail addr = hostmaster.geronimo.keycomm.it
        serial = 98022001
        refresh = 86400 (1 day)
        retry   = 7200 (2 hours)
        expire  = 2592000 (30 days)
        minimum ttl = 86400 (1 day)

A quanto pare la ricerca è finita; si prova a modificare il tipo di richiesta in modo da ottenere tutti i tipi di notizie disponibili.

set q=any[Invio]

3.117.184.194.in-addr.arpa.[Invio]

Server:  dns.interbusiness.it
Address:  151.99.125.2

3.117.184.194.in-addr.arpa      name = serena.keycomm.it
117.184.194.in-addr.arpa        nameserver = geronimo.keycomm.it
117.184.194.in-addr.arpa        nameserver = dns.interbusiness.it
117.184.194.in-addr.arpa        nameserver = dns.nis.garr.it
geronimo.keycomm.it     internet address = 194.184.116.2
dns.interbusiness.it    internet address = 151.99.125.2
dns.nis.garr.it internet address = 193.205.245.8
>

Ecco che 3.117.184.184 corrisponde a `serena.keycomm.it'. Per concludere si utilizza il comando `exit'.

exit[Invio]

94.1.3.1 Osservazioni

Mentre la scomposizione in domini normali si astrae completamente dalla disposizione degli indirizzi IP, la scomposizione di un dominio `in-addr.arpa' è vincolato in qualche modo alla suddivisione in ottetti dell'indirizzo IP.

In pratica, si può predisporre un file di configurazione di `named' per la risoluzione di un ottetto di indirizzi IP, come negli esempi visti in precedenza, quando si volevano risolvere gli indirizzi IP della sottorete 192.168.1.0, indicando il dominio `1.168.192.in-addr.arpa'. Ma se invece si dispone di due sottoreti che spezzano a metà l'ultimo ottetto, non si può demandare all'interno di queste sottoreti il compito di risolvere i domini `in-addr.arpa' rispettivi, per il semplice fatto che questi non esistono.

94.2 File di configurazione più in dettaglio

È giunto finalmente il momento di 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' i commenti sono introdotti da una doppia barra obliqua, oppure sono delimitati come si fa nel linguaggio C: `/*...*/'.

94.2.1 /etc/named.conf

Il file `/etc/named.conf' è già stato visto più volte nel capitolo precedente. Si riprende qui il solito esempio.

options {
	directory "/var/named";
};
//
zone "." {
	type hint;
	file "named.root";
};
// 
zone "0.0.127.in-addr.arpa" {
	type master;
	file "zone/127.0.0";
};
zone "1.168.192.in-addr.arpa" {
	type master;
	file "zone/192.168.1";
};
zone "brot.dg" {
	type master;
	file "zone/brot.dg";
};

Segue l'elenco e la descrizione delle direttive e delle opzioni più importanti di questo file.

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

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

94.2.1.2 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 un dominio `in-addr.arpa'. 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' 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'.

94.2.1.3 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'.

Se i servizi di risoluzione dei nomi esterni dovessero risultare inaccessibili per qualche tempo, quello locale può continuare a fornire queste informazioni, fino a quando queste raggiungono il periodo di scadenza.

94.2.2 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 `/etc/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 indicato, 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. 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 `/etc/named.conf' corrispondente alla zona in questione.

Nelle sezioni seguenti vengono descritti i record di risorsa più importanti.

94.2.3 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 `/etc/named.conf', la direttiva seguente fa riferimento al file di zona `zone/brot.dg'.

zone "brot.dg" {
	type master;
	file "zone/brot.dg";
};

In tal caso, il simbolo `@' del primo record del file `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. *2*

La sintassi completa del record `SOA' potrebbe essere espressa nel modo seguente:

<dominio> <classe> SOA <server-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, e 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'.

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

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

94.2.6 A -- Address

I file di zona utilizzati per tradurre i nomi di dominio in indirizzi numerici sono fatti essenzialmente per contenere record di tipo `A', ovvero di indirizzo, che permettono di definire le corrispondenze tra nomi e indirizzi numerici.

dinkel.brot.dg.		A	192.168.1.1
roggen.brot.dg.		A	192.168.1.2

Nell'esempio si mostrano due di questi record. Il primo, in particolare, indica che il nome `roggen.brot.dg' corrisponde all'indirizzo numerico 192.168.1.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 due record appena mostrati avrebbero potuto essere rappresentati nella forma seguente:

dinkel			A	192.168.1.1
roggen			A	192.168.1.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 due record di questa sezione potrebbero essere scritti nel modo seguente:

dinkel.brot.dg.		86400	IN	A	192.168.1.1
roggen.brot.dg.		86400	IN	A	192.168.1.2

94.2.7 PTR -- Pointer

Nei file di zona utilizzati per tradurre i nomi di dominio che appartengono a `in-addr.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 è intuitivo, ma non necessariamente chiaro. Il numero che appare all'inizio è un nome di dominio abbreviato. Il dominio di origine di questo file (visti gli esempi mostrati in precedenza) è `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' 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.

Anche per questo tipo di record valgono le considerazioni fatte per quello di tipo `A', riguardo all'indicazione della durata di validità e alla classe di indirizzamento.

94.2.8 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' 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'. 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.

94.2.9 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. Questo è esattamente ciò che serve in questo tipo di file.

.                        3600000  IN  NS    A.ROOT-SERVERS.NET.
A.ROOT-SERVERS.NET.      3600000      A     198.41.0.4

94.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 `/etc/named.conf' come nell'esempio seguente:

options {
	directory "/var/named";
};
//
zone "." {
	type hint;
	file "named.root";
};
// 
zone "0.0.127.in-addr.arpa" {
	type master;
	file "zone/127.0.0";
};
//
zone "1.168.192.in-addr.arpa" {
	type slave;
	file "zone/192.168.1";
	masters {
		192.168.1.1;
	};
};
zone "brot.dg" {
	type slave;
	file "zone/brot.dg";
	masters {
		192.168.1.1;
	};
};

I file `/var/named/named.root' e `/var/named/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'.

94.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 `/etc/named.conf' come nell'esempio seguente:

options {
	directory "/var/named";
	forward only;
	forwarders {
	        192.168.1.1;
	};
};
//
zone "0.0.127.in-addr.arpa" {
	type master;
	file "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.

94.5 Particolarità per IPv6

La gestione di IPv6 implica delle novità per la configurazione di un DNS. Si introducono due cose importanti: i record `AAAA' per tradurre i nomi in indirizzi IPv6 e il dominio `IP6.INT' per la risoluzione degli indirizzi nei nomi corrispondenti.

94.5.1 Record AAAA

La forma di un record `AAAA' è la stessa di quella corrispondente per gli indirizzi IPv4; intuitivamente, quattro «A» indicano che l'indirizzo IPv6 è quattro volte più lungo di quello IPv4. Evidentemente, al posto di indicare un indirizzo IPv4 si mette quello IPv6. Una cosa importante è invece la possibilità di indicare diverse corrispondenze per lo stesso nome di dominio. Per riprendere gli esempi già fatti per IPv4, il file `/var/named/zone/brot.dg' potrebbe essere esteso nel modo seguente:

@  IN             SOA    dinkel.brot.dg. root.dinkel.brot.dg. (
                               1998031800 ; Serial
                               28800      ; Refresh
                               7200       ; Retry
                               604800     ; Expire
                               86400 )    ; Minimum
                  NS     dinkel.brot.dg.

                  MX     10 dinkel.brot.dg.

www.brot.dg.      CNAME  dinkel.brot.dg.
ftp.brot.dg.      CNAME  dinkel.brot.dg.

dinkel.brot.dg.    A     192.168.1.1
roggen.brot.dg.    A     192.168.1.2

dinkel.brot.dg.    AAAA  fec0::1:2a0:24ff:fe77:4997
dinkel.brot.dg.    AAAA  fe80::2a0:24ff:fe77:4997

roggen.brot.dg.    AAAA  fec0::1:280:adff:fec8:a981
roggen.brot.dg.    AAAA  fe80::280:adff:fec8:a981

In questo esempio sono stati indicati anche indirizzi link-local, solo a scopo didattico, ma nella realtà è improbabile che questi siano annotati in un DNS.

Si può osservare che in questo caso i record `A' possono convivere con quelli di tipo `AAAA', inoltre si nota il fatto che lo stesso nome di dominio può essere abbinato sia a un indirizzo IPv4 che a più indirizzi IPv6. Per verificare questa nuova configurazione, dopo aver riavviato il servizio, si può usare `nslookup' avendo cura di specificare che si vogliono ottenere tutte le informazioni.

nslookup[Invio]

set q=any[Invio]

dinkel.brot.dg.[Invio]

Server:  dinkel.brot.dg
Address:  192.168.1.1

dinkel.brot.dg	internet address = 192.168.1.1
dinkel.brot.dg	IPv6 address = fec0::1:2a0:24ff:fe77:4997
dinkel.brot.dg	IPv6 address = fe80::2a0:24ff:fe77:4997
brot.dg		nameserver = dinkel.brot.dg
...

roggen.brot.dg.[Invio]

Server:  dinkel.brot.dg
Address:  192.168.1.1

roggen.brot.dg	internet address = 192.168.1.1
roggen.brot.dg	IPv6 address = fec0::2:280:adff:fec8:a981
roggen.brot.dg	IPv6 address = fe80::280:adff:fec8:a981
brot.dg		nameserver = dinkel.brot.dg
...

94.5.2 Risoluzione inversa

Per la risoluzione inversa, da indirizzo IP a nome di dominio, è stato introdotto il dominio `IP6.INT', che funziona in modo simile a `in-addr.arpa', con la differenza che ogni cifra esadecimale che compone l'indirizzo IPv6 viene separata in un sottodominio. Tanto per rendere l'idea, l'indirizzo fec0::1:2a0:24ff:fe77:4997 (ovvero fec0:0000:0000:0001:02a0:24ff:fe77:4997) si traduce nel nome di dominio seguente:

7.9.9.4.7.7.e.f.f.f.4.2.0.a.2.0.1.0.0.0.0.0.0.0.0.0.0.0.0.c.e.f.IP6.INT

Se per ipotesi, seguendo la logica degli esempi già visti, si volesse gestire la risoluzione degli indirizzi della sottorete fec0:0:0:1::/64 (in pratica una sottorete di indirizzi site-local), si potrebbe creare il file `/var/named/zone/fec0:0:0:1', dichiarandolo opportunamente nel file `/etc/named.conf':

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

In questo modo, nel file `/var/named/zone/fec0:0:0:1' si può fare riferimento alla parte restante del dominio `IP6.INT':

@  IN  SOA   dinkel.brot.dg. root.dinkel.brot.dg.  (
	                     1998031800 ; Serial
        		     28800      ; Refresh
		             7200       ; Retry
    		             604800     ; Expire
	                     86400 )    ; Minimum

					NS    dinkel.brot.dg.

7.9.9.4.7.7.e.f.f.f.4.2.0.a.2.0		PTR	dinkel.brot.dg.
1.8.9.a.8.c.e.f.f.f.d.a.0.8.2.0		PTR	roggen.brot.dg.

Per verificare il funzionamento della conversione da indirizzo IPv6 a nome di dominio, occorre indicare espressamente il dominio `IP6.INT':

nslookup[Invio]

set q=any[Invio]

7.9.9.4.7.7.e.f.f.f.4.2.0.a.2.0.1.0.0.0.0.0.0.0.0.0.0.0.0.c.e.f.IP6.INT.[Invio]

Server:  dinkel.brot.dg
Address:  192.168.1.1
7.9.9.4.7.7.e.f.f.f.4.2.0.a.2.0.1.0.0.0.0.0.0.0.0.0.0.0.0.c.e.f.IP6.INT
name = dinkel.brot.dg
1.0.0.0.0.0.0.0.0.0.0.0.0.c.e.f.IP6.INT	nameserver = dinkel.brot.dg
...

94.6 Considerazioni finali

Perché il proprio servizio di risoluzione dei nomi continui a funzionare correttamente, è necessario che il file per la risoluzione del dominio principale (`named.root' in questi esempi) venga aggiornato quando necessario. Se tutti gli amministratori dei DNS esistenti utilizzassero il protocollo FTP per scaricarlo dall'indirizzo mostrato precedentemente, si creerebbe un carico di rete inaccettabile. Per questo dovrebbe essere utilizzato il programma `dig', nel modo seguente, che richiede meno risorse di rete.

dig @rs.internic.net . ns > named.root

94.7 Riferimenti

---------------------------

Appunti Linux 2000.04.12 --- Copyright © 1997-2000 Daniele Giacomini --  daniele @ pluto.linux.it


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.) Tuttavia, in un record `SOA' è preferibile indicare solo nomi di dominio assoluti.


[inizio] [indice generale] [precedente] [successivo] [indice analitico] [contributi]