Документ взят из кэша поисковой машины. Адрес оригинального документа : http://www.arcetri.astro.it/irlab/doc/library/linux/AppLinux/al108.htm
Дата изменения: Tue Sep 21 18:08:42 1999
Дата индексирования: Sat Dec 22 13:23:15 2007
Кодировка:

Appunti Linux: DNS: dettagli ulteriori [inizio] [indice generale] [precedente] [successivo] [indice analitico] [contributi]

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

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

83.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 server 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]

83.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 server 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 server 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 server 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 server si desidera conoscere quali altri server 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 server; 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 server Х 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 server 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]

83.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 unico 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 corrispondente dominio 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 server. 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]

83.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 rispettivi domini in-addr.arpa, per il semplice fatto che questi non esistono.

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

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

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.
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И, e il punto finale sarebbe solo un errore.

83.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 server di inoltro, ovvero i forwarder.

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

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

83.2.2 File di zona

I file di zona costituiscono in pratica il database 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, e 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.

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.
Il secondo campo indica il tempo di validitЮ dell'informazione, espressa in secondi. Serve solo per i server 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 server 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.
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 /etc/named.conf corrispondente alla zona in questione.

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

83.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 si sarebbe potuto 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.

Il nome canonico dell'elaboratore che svolge la funzione di server 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 name server. 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.
Il numero di serie serve ai server DNS secondari per sapere quando i dati sono stati modificati. Il numero deve essere progressivo. х consentito l'uso di dieci cifre numeriche, e 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, e 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 server 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 server 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 server DNS e il successivo. In pratica, quando il server DNS primario Х inattivo, i server secondari continuano a funzionare e fornire il loro servizio, tuttavia, a intervalli regolari tentano di contattare il server 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 server 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.

83.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 server 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 server 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 server DNS dovrebbe essere un nome canonico, cioХ un nome per il quale esiste un record di tipo A corrispondente.

83.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 di scambio di messaggi email. 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.

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

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

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

83.2.9 File dei server 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 server DNS principali contiene esclusivamente due tipi di record: NS e A.

I record NS servono a indicare i nomi dei vari server 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

83.3 Server DNS secondari

Un server DNS secondario, o slave, Х quello che riproduce le informazioni di altri server, controllando la validitЮ a intervalli regolari, aggiornando i dati quando necessario.

Supponendo di volere realizzare un server 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 server primario. In questo modo, il server 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.

83.4 Server DNS di inoltro

Un server DNS di inoltro, o forwarder, Х quello che rinvia le richieste a un altro servizio di risoluzione dei nomi.

Supponendo di volere realizzare un server 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.

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

83.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, e inoltre si nota il fatto che lo stesso nome di dominio puР essere abbinato sia con un indirizzo IPv4 che con 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 ...

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

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

83.7 Riferimenti

Nicolai Langfeldt, DNS HOWTO
Olaf Kirch, NAG, The Linux Network Administrators' Guide
BOG, Bind Operations Guide
http://www.dns.net/dnsrd/
http://www.vix.com/isc/
named(8)
D. Barr, RFC 1912: Common DNS Operational and Configuration Errors, 1996
http://www.cis.ohio-state.edu/htbin/rfc/rfc1912.html
http://www.cis.ohio-state.edu/rfc/rfc1912.txt
S. Thomson, C. Huitema, RFC 1886: DNS Extentions to support IP version 6, 1996
http://www.cis.ohio-state.edu/htbin/rfc/rfc1912.html
http://www.cis.ohio-state.edu/rfc/rfc1912.txt

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

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]