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.
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.
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 [Invio]-t any brot.dg
[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]
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. Nel comando che segue, il nome viene indicato con il punto finale, per sottolineare che si tratta di un nome di dominio completo.
-servers.net
$ nslookup [Invio]- i.root-servers.net.
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]
Una delle cose più difficili da capire per un principiante è cosa sia il dominio in. 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, -addr.arpapluto.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 è 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 -addr.arpain è -addr.arpa3.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 [Invio]- i.root-servers.net.
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]
Mentre la scomposizione in domini normali si astrae completamente dalla disposizione degli indirizzi IP, la scomposizione di un dominio in è vincolato in qualche modo alla suddivisione in ottetti dell'indirizzo IP.
-addr.arpa
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, per il semplice fatto che questi non esistono.
-addr.arpa
È 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: /*...*/.
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. |
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.
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. Nel primo caso, le informazioni del file servono a tradurre i nomi di dominio in indirizzi numerici; nel secondo, dal momento che i domini -addr.arpain contengono nel nome l'informazione dell'indirizzo numerico, i file servono a tradurre gli indirizzi numerici in nomi di dominio normale.
-addr.arpa
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.
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.
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.
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.
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.
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. |
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 |
Nei file di zona utilizzati per tradurre i nomi di dominio che appartengono a in in nomi di dominio normale, cioè quelli che servono a ottenere il nome a partire dall'indirizzo numerico, si utilizzano i record -addr.arpaPTR (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, per cui, volendo indicare nomi di dominio completi, si dovrebbe fare come nell'esempio seguente:
-addr.arpa
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.
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 |
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 |
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.
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 viene risolto localmente, tutto il resto viene richiesto al DNS corrispondente all'indirizzo 192.168.1.1. L'opzione -addr.arpaforward only sottolinea questo fatto.
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.
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 ... |
Per la risoluzione inversa, da indirizzo IP a nome di dominio, è stato introdotto il dominio IP6.INT, che funziona in modo simile a in, 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:
-addr.arpa
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 ... |
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
Nicolai Langfeldt, DNS HOWTO
Olaf Kirch, NAG, The Linux Network Administrators' Guide
BOG, Bind Operations Guide
named(8)
D. Barr, RFC 1912: Common DNS Operational and Configuration Errors, 1996
S. Thomson, C. Huitema, RFC 1886: DNS Extentions to support IP version 6, 1996
---------------------------
Appunti Linux 1999.09.21 --- Copyright © 1997-1999 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.