<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
<HTML>
<HEAD>
<META NAME="GENERATOR" CONTENT="SGML-Tools 1.0.9">
<TITLE>DNS HOWTO: Un semplice dominio</TITLE>
<LINK HREF="DNS-HOWTO-6.html" REL=next>
<LINK HREF="DNS-HOWTO-4.html" REL=previous>
<LINK HREF="DNS-HOWTO.html#toc5" REL=contents>
</HEAD>
<BODY>
<A HREF="DNS-HOWTO-6.html">Avanti</A>
<A HREF="DNS-HOWTO-4.html">Indietro</A>
<A HREF="DNS-HOWTO.html#toc5">Indice</A>
<HR>
<H2><A NAME="simple"></A> <A NAME="s5">5. Un <EM>semplice</EM> dominio</A></H2>
<P><B>Come impostare il vostro dominio</B>
<P>
<H2><A NAME="ss5.1">5.1 Ma prima un po' di teoria</A>
</H2>
<P>Prima di tutto: avete letto tutto fin qui? Dovete farlo.
<P>
<P>Prima di iniziare <EM>veramente</EM> questa sezione vi proporrò un
po' di teoria e un esempio su come il DNS lavora. Dovrete leggerlo
perché vi sarà utile. Se non ne avete voglia dovrete almeno dargli uno
sguardo veloce. Fate invece attenzione alle parti che dovrebbero andare
nel vostro file <CODE>named.conf</CODE>.
<P>
<P>DNS è un sistema gerarchico, strutturato ad albero. L'apice è
indicato come "<CODE>.</CODE>" e si pronuncia "root". Al di sotto di <CODE>.</CODE> c'è
un gran numero di Top Level Domains (TLD), i più noti sono <CODE>ORG</CODE>,
<CODE>COM</CODE>, <CODE>EDU</CODE> and <CODE>NET</CODE>, ma ce ne sono molti altri. Proprio come
un albero, esso ha una radice da cui si dirama. Se avete
qualche conoscenza d'informatica riconoscerete nel DNS un albero di
ricerca e scoprirete nodi, nodi foglia e rami.
<P>
<P>Quando comincia la ricerca di una macchina, l'interrogazione procede
ricorsivamente nella gerarchia. Se volete trovare l'indirizzo numerico di
<CODE>prep.ai.mit.edu</CODE> il vostro name server dovrà cominciare a chiedere
da qualche parte. Prima esso guarda nella sua cache. Se conosce la risposta,
avendola precedentemente memorizzata, risponderà correttamente
nella maniera che abbiamo appena visto nell'ultima sezione. Se non la
conosce cerca allora nella sua cache qualche informazione che corrisponda
almeno in parte alla richiesta e ne fa uso.
Nel caso peggiore non c'è nessuna informazione nella cache che corrisponda
alla richiesta che è stata fatta, ma c'è il "." (root) alla fine del nome,
quindi i root name server dovranno essere consultati. Esso rimuoverà le parti
più a sinistra del nome una alla volta, controllando se sa qualcosa a proposito
di <CODE>ai.mit.edu.</CODE>, poi di <CODE>mit.edu.</CODE>, infine di <CODE>edu.</CODE> e se niente
risultasse dove per forza conoscere qualcosa a proposito di <CODE>.</CODE>, poichè
è descritto nel file <CODE>root.hints</CODE>. Allora il vostro name server
andrà ad interrogare uno dei root name server circa <CODE>prep.ai.mit.edu</CODE>. Il
root name server non conoscerà la risposta, ma aiuterà il vostro name server,
dandogli un riferimento e dicendogli dove andare a cercare.
Questi riferimenti condurranno il vostro name server a un name server
che conosce la risposta. Ora illustrerò questo punto. <CODE>+norec</CODE> significa
che dig sta facendo delle richieste non ricorsive, in modo che saremo
noi a dover fare la ricorsione. Le altre opzioni sono per ridurre
l'output di dig, così da non prendere troppe pagine:
<P>
<BLOCKQUOTE><CODE>
<PRE>
$ ;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 980
;; flags: qr ra; QUERY: 1, ANSWER: 0, AUTHORITY: 13, ADDITIONAL: 0
;; AUTHORITY SECTION:
. 518400 IN NS J.ROOT-SERVERS.NET.
. 518400 IN NS K.ROOT-SERVERS.NET.
. 518400 IN NS L.ROOT-SERVERS.NET.
. 518400 IN NS M.ROOT-SERVERS.NET.
. 518400 IN NS A.ROOT-SERVERS.NET.
. 518400 IN NS B.ROOT-SERVERS.NET.
. 518400 IN NS C.ROOT-SERVERS.NET.
. 518400 IN NS D.ROOT-SERVERS.NET.
. 518400 IN NS E.ROOT-SERVERS.NET.
. 518400 IN NS F.ROOT-SERVERS.NET.
. 518400 IN NS G.ROOT-SERVERS.NET.
. 518400 IN NS H.ROOT-SERVERS.NET.
. 518400 IN NS I.ROOT-SERVERS.NET.
</PRE>
</CODE></BLOCKQUOTE>
<P>
<P>Questo è un riferimento. Ci fornisce solo una "Authority section", non
una "Answer section". Il nostro name server farà riferimento ad un'altro.
Prendiamone uno a caso:
<P>
<BLOCKQUOTE><CODE>
<PRE>
$ dig +norec +noques +nostats +nocmd prep.ai.mit.edu. @D.ROOT-SERVERS.NET.
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 58260
;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 3, ADDITIONAL: 3
;; AUTHORITY SECTION:
mit.edu. 172800 IN NS BITSY.mit.edu.
mit.edu. 172800 IN NS STRAWB.mit.edu.
mit.edu. 172800 IN NS W20NS.mit.edu.
;; ADDITIONAL SECTION:
BITSY.mit.edu. 172800 IN A 18.72.0.3
STRAWB.mit.edu. 172800 IN A 18.71.0.151
W20NS.mit.edu. 172800 IN A 18.70.0.160
</PRE>
</CODE></BLOCKQUOTE>
<P>
<P>Ci indirizza verso uno dei server MIT.EDU. Sempre uno a caso:
<P>
<BLOCKQUOTE><CODE>
<PRE>
$ dig +norec +noques +nostats +nocmd prep.ai.mit.edu. @BITSY.mit.edu.
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 29227
;; flags: qr ra; QUERY: 1, ANSWER: 1, AUTHORITY: 4, ADDITIONAL: 4
;; ANSWER SECTION:
prep.ai.mit.edu. 10562 IN A 198.186.203.77
;; AUTHORITY SECTION:
ai.mit.edu. 21600 IN NS FEDEX.ai.mit.edu.
ai.mit.edu. 21600 IN NS LIFE.ai.mit.edu.
ai.mit.edu. 21600 IN NS ALPHA-BITS.ai.mit.edu.
ai.mit.edu. 21600 IN NS BEET-CHEX.ai.mit.edu.
;; ADDITIONAL SECTION:
FEDEX.ai.mit.edu. 21600 IN A 192.148.252.43
LIFE.ai.mit.edu. 21600 IN A 128.52.32.80
ALPHA-BITS.ai.mit.edu. 21600 IN A 128.52.32.5
BEET-CHEX.ai.mit.edu. 21600 IN A 128.52.32.22
</PRE>
</CODE></BLOCKQUOTE>
<P>
<P>
<P>Questa volta abbiamo ottenuto una "ANSWER SECTION" e una risposta
alla nostra interrogazione. La "AUTHORITY SECTION" contiene informazioni
tipo a quali server fare richieste sul dominio <CODE>ai.mit.edu</CODE>, in modo
che la prossima volta potrete rivolgere direttamente loro interrogazioni
sui nomi di <CODE>ai.mit.edu</CODE>. Named ha anche raccolto
informazioni su <CODE>mit.edu</CODE>, in modo da rispondere più celermente se
venisse richiesto <CODE>www.mit.edu</CODE>.
<P>
<P>Così partendo da <CODE>.</CODE> abbiamo scoperto i name server successivi
per ogni livello nel nome di dominio. Se aveste usato il vostro server DNS
invece di tutti questi altri, il vostro named avrebbe naturalmente
messo nella propria cache tutte le informazioni trovate durante la
ricerca e per un bel pezzo non le avrebbe più richieste.
<P>
<P>Secondo l'analogia dell'albero, ogni "<CODE>.</CODE>" del nome rappresenta un
punto di diramazione. Le parti che stanno tra i "<CODE>.</CODE>" sono i nomi di
singoli rami dell'albero.
<P>
<P>Abbiamo scalato l'albero scegliendo un nome a piacere
(<CODE>prep.ai.mit.edu</CODE>), prima abbiamo scoperto la radice (<CODE>.</CODE>) e poi
siamo andati alla ricerca del prossimo ramo da scalare, nel nostro caso
<CODE>edu</CODE>. Una volta trovato questo, l'abbiamo scalato passando per il
server che conosceva questa parte di nome. Dopo abbiamo ricercato il
ramo <CODE>mit</CODE> sopra il ramo <CODE>edu</CODE> (per avere <CODE>mit.edu</CODE>) e abbiamo
scalato anch'esso sfruttando il server che conosceva <CODE>mit.edu</CODE>.
Ancora, abbiamo cercato <CODE>ai.mit.edu</CODE> come prossimo ramo e per
scalarlo abbiamo sfruttato il server che lo conosceva. Adesso siamo
arrivati al giusto server, al giusto punto di diramazione. L'ultimo passo
da fare è scoprire <CODE>prep.ai.mit.edu</CODE>, ma è molto semplice.
<P>
<P>Un dominio importante ma poco discusso in precedenza è <CODE>in-addr.arpa</CODE>.
Anch'esso è annidato come i domini "normali". <CODE>in-addr.arpa</CODE> ci
permette di ricavare il nome dell'host quando abbiamo il suo indirizzo.
Una cosa importante da notare è che gli indirizzi IP sono scritti
in ordine inverso nel dominio <CODE>in-addr.arpa</CODE>. Se avete un indirizzo
di una macchina, p.e. <CODE>198.186.203.77</CODE>, named procede cercando
77.203.186.198.in-addr.arpa/ proprio come ha fatto con <CODE>prep.ai.mit.edu</CODE>.
Esempio: Se non ha trovato niente nella cache, chiede ad un root server,
<CODE>m.root-servers.net</CODE> vi riporta ad altri root server.
<CODE>b.root-servers.net</CODE> vi riporta direttamente a <CODE></CODE>bitsy.mit.edu/.
Dovreste essere in grado di prendere da qui il nome.
<P>
<P>
<H2><A NAME="ss5.2">5.2 Il nostro dominio</A>
</H2>
<P>Adesso definiremo il nostro dominio. Stiamo per creare il dominio
<CODE>linux.bogus</CODE> e per definire le macchine in esso. Utilizzerò nomi di
dominio completamente fasulli per essere sicuro di non disturbare
nessuno là fuori ("bogus" significa appunto fasullo NdT).
<P>
<P>Un'ultima cosa prima di iniziare: non tutti i caratteri sono permessi
nei nomi degli host. Siamo limitati ai caratteri dell'alfabeto inglese, da
"a" a "z", alle cifre da 0 a 9 e al carattere "-" (trattino). Ricordatevelo.
Maiuscole e minuscole hanno lo stesso valore per il DNS, così <CODE>pat.uio.no</CODE> è
identico a <CODE>Pat.UiO.No</CODE>.
<P>
<P>
<P>Abbiamo già iniziato questa parte con questa riga in
<CODE>named.conf</CODE>:
<P>
<HR>
<PRE>
zone "0.0.127.in-addr.arpa" {
type master;
file "pz/127.0.0";
};
</PRE>
<HR>
<P>
<P>Per favore notate in questo file l'assenza del "<CODE>.</CODE>" alla fine
dei nomi del dominio. Questo significa che ora definiremo la zona
<CODE>0.0.127.in-addr.arpa</CODE>, che siamo il server primario ("master server")
per essa e che è descritta nel file chiamato <CODE>pz/127.0.0</CODE>.
Abbiamo già impostato questo file:
<P>
<HR>
<PRE>
$TTL 3D
@ IN SOA ns.linux.bogus. hostmaster.linux.bogus. (
1 ; Serial
8H ; Refresh
2H ; Retry
4W ; Expire
1D) ; Minimum TTL
NS ns.linux.bogus.
1 PTR localhost.
</PRE>
<HR>
<P>
<P>
<P>Per favore notate in questo file il "<CODE>.</CODE>" alla fine di tutti
i nomi di dominio completi, in contrasto col file <CODE>named.conf</CODE> di
prima. Alcune persone hanno l'abitudine di iniziare ogni file relativo a
una zona con una direttiva <CODE>$ORIGIN</CODE>, ma questo è superfluo.
L'origine (che appartiene alla gerarchia del DNS) di un file zona è
specificata nella sezione delle zone nel file <CODE>named.conf</CODE>, in
questo caso è <CODE>0.0.127.in-addr.arpa</CODE>.
<P>
<P>Questo file di zona contiene 3 record di risorse (RR): un RR
SOA, un RR NS e un RR PTR. SOA è l'acronimo di "Start Of Authority".
La "@" è una notazione speciale che indica
l'origine, poiché la colonna "domain" di questo file riporta
0.0.127.in-addr.arpa, la prima riga in realtà significa:
<P>
<BLOCKQUOTE><CODE>
<PRE>
0.0.127.in-addr.arpa. IN SOA ...
</PRE>
</CODE></BLOCKQUOTE>
<P>
<P>
<P>NS è il RR Name Server. Non c'è una "@" all'inizio di questa riga: è
implicita perché la riga precedente comincia con "@". Questo fa
risparmiare un po' di battute sulla tastiera. In questo modo la riga NS
può essere scritta anche come:
<P>
<BLOCKQUOTE><CODE>
<PRE>
0.0.127.in-addr.arpa. IN NS ns.linux.bogus
</PRE>
</CODE></BLOCKQUOTE>
<P>
<P>Essa dice al DNS quale macchina è il name server per il dominio
<CODE>0.0.127.in-addr.arpa</CODE>: è appunto <CODE>ns.linux.bogus</CODE>. È
consuetudine associare a "ns" la parola name server, analogamente a
quanto succede ai web server, di solito associati a <CODE>www.</CODE><EM>qualcosa</EM>.
Il nome potrebbe essere uno qualsiasi.
<P>Infine il record PTR ("Domain Name Pointer") dice che l'host all'indirizzo 1 nella
sottorete tt/0.0.127.in-addr.arpa/, ovvero 127.0.0.1, è chiamato
<CODE>localhost</CODE>.
<P>
<P>Il record SOA è il preambolo di <EM>tutti</EM> i file di zona, deve
esisterne uno ed uno solo in ogni file di zona, al principio (ma dopo
la direttiva $TTL). Questo record descrive
la zona, da dove esso viene (una macchina chiamata <CODE>ns.linux.bogus</CODE>),
chi è responsabile per i suoi contenuti (<CODE>hostmaster@linux.bogus</CODE>,
dovrete inserire il vostro indirizzo email qui), quale è la versione
del file di zona (serial: 1) e altre cose che riguardano il server DNS
secondario o quello che fa da cache. Per il resto dei campi (refresh, retry,
expire e minimum) usate pure i valori indicati in questo HOWTO e sarete
a posto. Prima della riga col recors SOA c'è una riga obbligatoria,
la riga <CODE>$TTL 3D</CODE>. Mettetela in tutti i vostri file di zona.
<P>
<P>Adesso fate ripartire named (il comando è <CODE>rndc stop;named</CODE>) e usate
<CODE>dig</CODE> per esaminare cosa avete fatto. <CODE>-x</CODE> serve per le interrogazioni
inverse:
<P>
<BLOCKQUOTE><CODE>
<PRE>
$ dig -x 127.0.0.1
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 30944
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 0
;; QUESTION SECTION:
;1.0.0.127.in-addr.arpa. IN PTR
;; ANSWER SECTION:
1.0.0.127.in-addr.arpa. 259200 IN PTR localhost.
;; AUTHORITY SECTION:
0.0.127.in-addr.arpa. 259200 IN NS ns.linux.bogus.
;; Query time: 3 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Sun Dec 23 03:02:39 2001
;; MSG SIZE rcvd: 91
</PRE>
</CODE></BLOCKQUOTE>
<P>
<P>si ottiene <CODE>localhost</CODE> da 127.0.0.1, bene. Ora per il nostro scopo
principale, il dominio <CODE>linux.bogus</CODE>, inserite una nuova sezione "zone" in
<CODE>named.conf</CODE>:
<P>
<HR>
<PRE>
zone "linux.bogus" {
type master;
notify no;
file "pz/linux.bogus";
};
</PRE>
<HR>
<P>
<P>Notate ancora l'assenza del "<CODE>.</CODE>" finale nel nome del dominio nel
file <CODE>named.conf</CODE>.
<P>
<P>Nel file di zona <CODE>linux.bogus</CODE> metteremo dei dati completamente
fasulli:
<P>
<HR>
<PRE>
;
; Zone file for linux.bogus
;
; The full zone file
;
$TTL 3D
@ IN SOA ns.linux.bogus. hostmaster.linux.bogus. (
199802151 ; serial, todays date + todays serial #
8H ; refresh, seconds
2H ; retry, seconds
4W ; expire, seconds
1D ) ; minimum, seconds
;
NS ns ; Inet Address of name server
MX 10 mail.linux.bogus ; Primary Mail Exchanger
MX 20 mail.friend.bogus. ; Secondary Mail Exchanger
;
localhost A 127.0.0.1
ns A 192.168.196.2
mail A 192.168.196.4
</PRE>
<HR>
<P>
<P>
<P>Bisogna notare due cose a proposito del record SOA. <CODE>ns.linux.bogus</CODE>
<EM>deve</EM> essere una macchina effettiva con un record A. Non è legale
avere un record CNAME per la macchina indicata nel record SOA. Il suo
nome non deve essere per forza "ns", può essere un qualsiasi nome
legale di host. La seconda cosa, <CODE>hostmaster.linux.bogus</CODE> deve essere
interpretato come hostmaster@linux.bogus, questo dovrà essere un alias
per un indirizzo email vero, o una mailbox, purché i manutentori del
DNS leggano la posta frequentemente.
Ogni email che riguarda il dominio sarà spedita all'indirizzo indicato
in questo record. Il nome non deve essere per forza "hostmaster",
potrà essere un normale indirizzo email, di solito ci si aspetta che
"hostmaster" funzioni a dovere (cioè che la posta indirizzata ad esso
arrivi da qualche parte).
<P>
<P>C'è un nuovo tipo di RR in questo file, MX o RR "Mail eXchanger".
Esso indica ai sistemi adibiti allo smistamento della posta dove
mandarla quando è ad esempio indirizzata a <CODE>qualcuno@linux.bogus</CODE>;
nel nostro caso si tratta di <CODE>mail.linux.bogus</CODE> o <CODE>mail.friend.bogus</CODE>.
Il numero che precede ogni nome di macchina indica la priorità del RR
MX. Il RR con il numero più basso (10) è quello che indica il mail
server al quale, se possibile, deve essere mandata la posta per primo.
Ove non funzionasse la posta potrà essere spedita a un server con un
numero più alto, un server di posta secondario, ovvero <CODE>mail.friend.bogus</CODE>
che appunto ha priorità 20 nel nostro caso.
<P>
<P>Fate ripartire named con <CODE>rndc reload</CODE>. Esaminate i risultati con
<CODE>dig</CODE>:
<P>
<BLOCKQUOTE><CODE>
<PRE>
$ dig any linux.bogus
; <<>> DiG 9.1.3 <<>> any linux.bogus
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 55239
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 1, ADDITIONAL: 1
;; QUESTION SECTION:
;linux.bogus. IN ANY
;; ANSWER SECTION:
linux.bogus. 259200 IN SOA ns.linux.bogus. \
hostmaster.linux.bogus. 199802151 28800 7200 2419200 86400
linux.bogus. 259200 IN NS ns.linux.bogus.
linux.bogus. 259200 IN MX 20 mail.friend.bogus.
linux.bogus. 259200 IN MX 10 mail.linux.bogus.linux.bogus.
;; AUTHORITY SECTION:
linux.bogus. 259200 IN NS ns.linux.bogus.
;; ADDITIONAL SECTION:
ns.linux.bogus. 259200 IN A 192.168.196.2
;; Query time: 4 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Sun Dec 23 03:06:45 2001
;; MSG SIZE rcvd: 184
</PRE>
</CODE></BLOCKQUOTE>
<P>
<P>
<P>Con un accurato esame scoprirete un errore. La riga
<P>
<BLOCKQUOTE><CODE>
<PRE>
linux.bogus. 259200 IN MX 10 mail.linux.bogus.linux.bogus.
</PRE>
</CODE></BLOCKQUOTE>
<P>è sbagliata. Dovrebbe essere:
<P>
<BLOCKQUOTE><CODE>
<PRE>
linux.bogus. 259200 IN MX 10 mail.linux.bogus.
</PRE>
</CODE></BLOCKQUOTE>
<P>
<P>Ho deliberatamente fatto quest'errore in modo che impariate da esso
:-). Cercando nel file di zona scopriremo che alla riga
<P>
<BLOCKQUOTE><CODE>
<PRE>
MX 10 mail.linux.bogus ; Primary Mail Exchanger
</PRE>
</CODE></BLOCKQUOTE>
<P>manca un punto. Oppure che ha un "linux.bogus" di troppo. Se un nome di
macchina non finisce con il punto nel file di zona, l'origine viene
aggiunta alla sua fine causando il doppione <CODE>linux.bogus.linux.bogus</CODE>.
Dunque sia:
<P>
<HR>
<PRE>
MX 10 mail.linux.bogus. ; Mail Exchanger Primario
</PRE>
<HR>
<P>oppure
<P>
<HR>
<PRE>
MX 10 mail ; Mail Exchanger Primario
</PRE>
<HR>
<P>è corretto. Io preferisco il secondo modo perché è più breve da
scrivere. Ci sono alcuni esperti di BIND che non approvano, altri
invece sì. Quindi in un file di zona il dominio dovrebbe essere scritto
per intero e fatto terminare da un "<CODE>.</CODE>" o dovrebbe essere
escluso del tutto, in questo caso verrà sostituito dall'origine.
<P>
<P>Devo stressarvi ripetendovi che nel file named.conf <EM>non</EM> ci devono
essere "<CODE>.</CODE>" alla fine dei nomi di dominio. Non avete idea di quante
volte un "<CODE>.</CODE>" di troppo (o la sua assenza) abbia ingarbugliato le
cose e confuso a morte chi ha avuto a che farci.
<P>
<P>
<P>Dunque ecco qua il nuovo file di zona, con qualche informazione
extra messa nel modo giusto:
<P>
<P>
<HR>
<PRE>
;
; Zone file for linux.bogus
;
; The full zone file
;
$TTL 3D
@ IN SOA ns.linux.bogus. hostmaster.linux.bogus. (
199802151 ; serial, todays date + todays serial #
8H ; refresh, seconds
2H ; retry, seconds
4W ; expire, seconds
1D ) ; minimum, seconds
;
TXT "Linux.Bogus, your DNS consultants"
NS ns ; Inet Address of name server
NS ns.friend.bogus.
MX 10 mail ; Primary Mail Exchanger
MX 20 mail.friend.bogus. ; Secondary Mail Exchanger
localhost A 127.0.0.1
gw A 192.168.196.1
TXT "The router"
ns A 192.168.196.2
MX 10 mail
MX 20 mail.friend.bogus.
www CNAME ns
donald A 192.168.196.3
MX 10 mail
MX 20 mail.friend.bogus.
TXT "DEK"
mail A 192.168.196.4
MX 10 mail
MX 20 mail.friend.bogus.
ftp A 192.168.196.5
MX 10 mail
MX 20 mail.friend.bogus.
</PRE>
<HR>
<P>
<P>
<P>CNAME ("Canonical NAME") è un modo per assegnare a ogni macchina
nomi diversi. Così "www" è un alias per "ns". L'utilizzo del record CNAME
è un po' controverso, ma è bene seguire la regola per cui un record
MX, CNAME o SOA non dovrebbero <EM>mai</EM> riferirsi a un record CNAME,
dovrebbero far rifimento soltanto a qualcosa che abbia un record A,
cioè non è auspicabile avere
<P>
<HR>
<PRE>
foobar CNAME www ; NO!
</PRE>
<HR>
<P>ma è corretto avere
<P>
<HR>
<PRE>
foobar CNAME ns ; SÌ!
</PRE>
<HR>
<P>
<P>Caricate il nuovo database facendo <CODE>rndc reload</CODE>, questo imporrà a
named di rileggere i suoi file.
<P>
<P>
<BLOCKQUOTE><CODE>
<PRE>
$ dig linux.bogus axfr
; <<>> DiG 9.1.3 <<>> linux.bogus axfr
;; global options: printcmd
linux.bogus. 259200 IN SOA ns.linux.bogus. hostmaster.linux.bogus. 199802151 28800 7200 2419200 86400
linux.bogus. 259200 IN NS ns.linux.bogus.
linux.bogus. 259200 IN MX 10 mail.linux.bogus.
linux.bogus. 259200 IN MX 20 mail.friend.bogus.
donald.linux.bogus. 259200 IN A 192.168.196.3
donald.linux.bogus. 259200 IN MX 10 mail.linux.bogus.
donald.linux.bogus. 259200 IN MX 20 mail.friend.bogus.
donald.linux.bogus. 259200 IN TXT "DEK"
ftp.linux.bogus. 259200 IN A 192.168.196.5
ftp.linux.bogus. 259200 IN MX 10 mail.linux.bogus.
ftp.linux.bogus. 259200 IN MX 20 mail.friend.bogus.
gw.linux.bogus. 259200 IN A 192.168.196.1
gw.linux.bogus. 259200 IN TXT "The router"
localhost.linux.bogus. 259200 IN A 127.0.0.1
mail.linux.bogus. 259200 IN A 192.168.196.4
mail.linux.bogus. 259200 IN MX 10 mail.linux.bogus.
mail.linux.bogus. 259200 IN MX 20 mail.friend.bogus.
ns.linux.bogus. 259200 IN MX 10 mail.linux.bogus.
ns.linux.bogus. 259200 IN MX 20 mail.friend.bogus.
ns.linux.bogus. 259200 IN A 192.168.196.2
www.linux.bogus. 259200 IN CNAME ns.linux.bogus.
linux.bogus. 259200 IN SOA ns.linux.bogus. hostmaster.linux.bogus. 199802151 28800 7200 2419200 86400
;; Query time: 41 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Sun Dec 23 03:12:31 2001
;; XFR size: 23 records
</PRE>
</CODE></BLOCKQUOTE>
<P>
<P>È buono. Come potete vedere somiglia un sacco allo stesso file di
zona. Vediamo cosa dice per <CODE>www</CODE> da solo:
<P>
<BLOCKQUOTE><CODE>
<PRE>
> set q=any
> www.linux.bogus.
Server: localhost
Address: 127.0.0.1
www.linux.bogus canonical name = ns.linux.bogus
linux.bogus nameserver = ns.linux.bogus
linux.bogus nameserver = ns.friend.bogus
ns.linux.bogus internet address = 192.168.196.2
</PRE>
</CODE></BLOCKQUOTE>
<P>
<P>In altre parole, il vero nome di<CODE>www.linux.bogus</CODE> è
<CODE>ns.linux.bogus</CODE> e vi da qualche informazione a proposito di ns,
abbastanza per connettervi ad esso se voi foste un programma.
<P>
<P>Ora siamo a metà strada.
<P>
<H2><A NAME="ss5.3">5.3 La zona inversa ("reverse zone")</A>
</H2>
<P>Adesso i programmi possono convertire i nomi di linux.bogus negli
indirizzi a cui vorrebbero connettersi. Ma c'è bisogno anche della zona
inversa, un DNS tale da poter convertire un indirizzo in un nome. Questo
nome è utile a un sacco di server di diversi tipi (FTP, IRC, WWW e
altri) per decidere se colloquiare con voi e l'eventuale priorità.
Per un pieno accesso a tutti i servizi su Internet è richiesta
una zona inversa.
<P>
<P>Mettete questo in <CODE>named.conf</CODE>:
<P>
<HR>
<PRE>
zone "196.168.192.in-addr.arpa" {
type master;
notify no;
file "pz/192.168.196";
};
</PRE>
<HR>
<P>
<P>È esattamente come per <CODE>0.0.127.in-addr.arpa</CODE> e i contenuti sono
simili:
<P>
<HR>
<PRE>
$TTL 3D
@ IN SOA ns.linux.bogus. hostmaster.linux.bogus. (
199802151 ; Serial, todays date + todays serial
8H ; Refresh
2H ; Retry
4W ; Expire
1D) ; Minimum TTL
NS ns.linux.bogus.
1 PTR gw.linux.bogus.
2 PTR ns.linux.bogus.
3 PTR donald.linux.bogus.
4 PTR mail.linux.bogus.
5 PTR ftp.linux.bogus.
</PRE>
<HR>
<P>
<P>Adesso fate ripartire named (<CODE>rndc reload</CODE>) e esaminate ancora
il lavoro con <CODE>dig</CODE> :
<P>
<HR>
<PRE>
$ dig -x 192.168.196.4
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 58451
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1
;; QUESTION SECTION:
;4.196.168.192.in-addr.arpa. IN PTR
;; ANSWER SECTION:
4.196.168.192.in-addr.arpa. 259200 IN PTR mail.linux.bogus.
;; AUTHORITY SECTION:
196.168.192.in-addr.arpa. 259200 IN NS ns.linux.bogus.
;; ADDITIONAL SECTION:
ns.linux.bogus. 259200 IN A 192.168.196.2
;; Query time: 4 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Sun Dec 23 03:16:05 2001
;; MSG SIZE rcvd: 107
</PRE>
<HR>
<P>
<P>
<P>pare OK, elencate tutto per fare un esame accurato:
<P>
<HR>
<PRE>
$ dig 196.168.192.in-addr.arpa. AXFR
; <<>> DiG 9.1.3 <<>> 196.168.192.in-addr.arpa. AXFR
;; global options: printcmd
196.168.192.in-addr.arpa. 259200 IN SOA ns.linux.bogus. \
hostmaster.linux.bogus. 199802151 28800 7200 2419200 86400
196.168.192.in-addr.arpa. 259200 IN NS ns.linux.bogus.
1.196.168.192.in-addr.arpa. 259200 IN PTR gw.linux.bogus.
2.196.168.192.in-addr.arpa. 259200 IN PTR ns.linux.bogus.
3.196.168.192.in-addr.arpa. 259200 IN PTR donald.linux.bogus.
4.196.168.192.in-addr.arpa. 259200 IN PTR mail.linux.bogus.
5.196.168.192.in-addr.arpa. 259200 IN PTR ftp.linux.bogus.
196.168.192.in-addr.arpa. 259200 IN SOA ns.linux.bogus. \
hostmaster.linux.bogus. 199802151 28800 7200 2419200 86400
;; Query time: 6 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Sun Dec 23 03:16:58 2001
;; XFR size: 9 records
</PRE>
<HR>
<P>
<P>Sembra buono! Se ottenete output un po' diversi guardate
i messaggi d'errore nel vostro syslog. Ho spiegato come farlo
all'inizio del primo capitolo :
<A HREF="DNS-HOWTO-3.html#starting">Far partire named</A><P>
<H2><A NAME="ss5.4">5.4 Qualche parola di avvertimento</A>
</H2>
<P>Ci sono delle cose che a questo punto vorrei aggiungere. I numeri IP
usati negli esempi sono stati presi dai blocchi delle reti private,
cioè non è permesso usarli esplicitamente su Internet. Per questo sono
comodi da usare in un HOWTO. La seconda cosa riguarda la riga
<CODE>notify no;</CODE>. Dice a named che non deve notificare al suo server
secondario ("slave") quando riceve un aggiornamento di uno dei
suoi file di zona. In BIND 8 e successivi named può notificare agli altri
server quando riceve un aggiornamento dei file di zona. Questo è utile
nell'uso comune, ma per gli esperimenti privati con le zone questa
possibilità deve essere esclusa, non vogliamo che i nostri
esperimenti inquinino Internet vero??
<P>
<P>Naturalmente questo dominio è veramente fasullo e così tutti
gli indirizzi in esso. Per un vero esempio tratto dalla vita reale
leggete il prossimo capitolo.
<P>
<H2><A NAME="ss5.5">5.5 Perché non funziona il lookup inverso ("reverse lookup")</A>
</H2>
<P>Ci sono un paio di grattacapi che possono essere normalmente
evitati quando si fa il lookup sempre degli stessi nomi (o dei nomi per
cui lo si fa più spesso) quando si imposta la zona inversa. Prima di
andare avanti c'è bisogno che il lookup inverso funzioni bene sul
vostro name server. Se così non fosse, tornate indietro e mettetelo
a posto prima di continuare.
<P>
<P>Discuterò due problematiche del lookup inverso viste dall'esterno
della vostra rete:
<P>
<H3>La zona inversa non è delegata</H3>
<P>Quando chiedete a un provider di servizi un dominio e un intervallo
di indirizzi di rete, il dominio è normalmente delegato di conseguenza.
Una delega è quel record NS che tiene assieme il tutto, che vi permette
di passare da un name server all'altro come è stato spiegato nella
sezione teorica di sopra. L'avete letta vero? Se la zona inversa non
funziona tornate indietro e leggetela. Ora.
<P>
<P>Anche la zona inversa deve essere delegata. Se avete ottenuto
la rete <CODE>192.168.196</CODE> con il dominio <CODE>linux.bogus</CODE> dal vostro
provider, esso dovrà mettere un record <CODE>NS</CODE> nella
vostra zona inversa così come per la vostra zona di forward.
Se seguirete la catena partendo da <CODE>in-addr.arpa</CODE> fino alla vostra rete,
probabilmente troverete un'interruzione nella catena.
Molto probabilmente a livello del vostro provider.
Una volta scoperta l'interruzione contattate il provider e chiedetegli
di correggere l'errore.
<P>
<H3>Vi hanno dato una sottorete classless</H3>
<P>Questo sarebbe un argomento un po' avanzato, ma le sottoreti classless
(senza classe) ormai sono molto comuni e probabilmente ne avete una a
meno che non siate un'azienda di media grandezza.
<P>
<P>Una sottorete classless è ciò che oggi manda avanti Internet.
Qualche anno fa si è fatto molto rumore a causa della scarsità di
numeri IP. Le menti brillanti che lavorano al IETF (l'Internet
Engineering Task Force, sono loro che mantengono la funzionalità di
Internet)
unirono le loro menti e risolsero il problema. Ma bisogna pagare un
prezzo. Il prezzo è che avrete meno che una sottorete di classe "C" e che
qualcosa potrebbe non funzionare. Leggete per favore
<A HREF="http://www.acmebw.com/askmrdns/00007.htm">Ask Mr. DNS</A> per una buona
spiegazione e per saper come trattare il problema.
<P>
<P>L'avete letto? Non l'andrò a spiegare, quindi leggetelo.
<P>
<P>La prima parte del problema è costituita dal fatto che il vostro ISP
deve capire la tecnica descritta da Mr. DNS. Non tutti i piccoli ISP
ne hanno una chiara visione. Se sarà il caso dovrete spiegar
loro come fare ed essere insistenti. Ma anche voi assicuratevi di aver
capito bene prima ;-). A questo punto loro imposteranno una buona zona
inversa sui loro server e voi potrete esaminarla correttamente con
dig.
<P>
<P>La seconda e ultima parte del problema è costituita dal fatto che
voi dovete comprendere la tecnica. Se non siete sicuri rileggetela
ancora. Dopo potrete impostare le zone inverse della vostra sottorete
classless come descritto da Mr. DNS.
<P>
<P>Nei dintorni c'è un'altra trappola in agguato. I vecchi risolutori
<EM>non</EM> sono abilitati a sfruttare il trucco del <CODE>CNAME</CODE> nella catena
della risoluzione e falliranno nel tentativo di risoluzione inversa
sulla vostra macchina. Questo problema può portare
ad assegnare al servizio una classe di accesso scorretta , all'accesso
negato o a qualcosa del genere.
Ove inciampaste in un servizio di questo tipo, l'unica soluzione (che io
conosco) è che il vostro ISP inserisca direttamente nel suo file di zona
truccato (il file relativo alla vostra zona classless) il vostro record PTR
anziché il record CNAME truccato (è un modo per ingannare il DNS e per
fargli accettare qualcosa per cui non è preparato).
<P>
<P>Altri ISP offriranno diversi modi per risolvere questo problema, come
dei form che permettono di inserire via web i vostri dati
sulla zona inversa, oppure con altri sistemi "automagici".
<P>
<H2><A NAME="ss5.6">5.6 Server secondari ("slave server")</A>
</H2>
<P>Dopo aver impostato correttamente le zone sul server primario, avrete
bisogno di impostare almeno un server secondario. I server secondari sono
necessari per garantire robustezza. Se il server primario smettesse di
funzionare per qualche motivo, gli esterni avrebbero modo di ottenere
informazioni sul vostro dominio dal server secondario. I server primario
e secondario dovrebbero condividere il minor numero di queste poche cose:
sorgente energetica, LAN, ISP, città e nazione. Se tutte queste cose sono
differenti per il primario e il secondario allora avrete configurato un
ottimo server secondario.
<P>
<P>Un server secondario è semplicemente un name server che copia
i file di zona dal server primario. Si imposta così:
<P>
<HR>
<PRE>
zone "linux.bogus" {
type slave;
file "sz/linux.bogus";
masters { 192.168.196.2; };
};
</PRE>
<HR>
<P>
<P>Per copiare i dati si usa un meccanismo chiamato trasferimento di zona
("zone-transfer"). Il trasferimento di zona è controllato dal vostro record
SOA:
<P>
<HR>
<PRE>
@ IN SOA ns.linux.bogus. hostmaster.linux.bogus. (
199802151 ; serial, todays date + todays serial #
8H ; refresh, seconds
2H ; retry, seconds
4W ; expire, seconds
1D ) ; minimum, seconds
</PRE>
<HR>
<P>
<P>Una zona è trasferita solo se il numero di serie sul server primario è
maggiore di quello nel secondario. Ad ogni intervallo specificato in refresh
il secondario controllerà se il primario è stato aggiornato o meno. Se il
controllo fallisce (perchè il primario è indisponibile) esso cercherà di
rifare il controllo secondo l'intervallo specificato in retry. Se (il master)
continuasse a fallire per un tempo maggiore a quello dell'intervallo specificato
in expire, il server secondario rimuoverà la zona dal suo file system e non
sarà più tale per esso, cioè non sarà più un server secondario per quel server
primario.
<P>
<HR>
<A HREF="DNS-HOWTO-6.html">Avanti</A>
<A HREF="DNS-HOWTO-4.html">Indietro</A>
<A HREF="DNS-HOWTO.html#toc5">Indice</A>
</BODY>
</HTML>
