Come impostare il vostro dominio
Prima di tutto: avete letto tutto fin qui? Dovete farlo.
Prima di iniziare veramente 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 named.conf.
DNS è un sistema gerarchico, strutturato ad albero. L'apice è
indicato come "." e si pronuncia "root". Al di sotto di . c'è
un gran numero di Top Level Domains (TLD), i più noti sono ORG,
COM, EDU and NET, 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.
Quando comincia la ricerca di una macchina, l'interrogazione procede
ricorsivamente nella gerarchia. Se volete trovare l'indirizzo numerico di
prep.ai.mit.edu 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 ai.mit.edu., poi di mit.edu., infine di edu. e se niente
risultasse dove per forza conoscere qualcosa a proposito di ., poichè
è descritto nel file root.hints. Allora il vostro name server
andrà ad interrogare uno dei root name server circa prep.ai.mit.edu. 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. +norec 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:
$ ;; 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.
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:
$ 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
Ci indirizza verso uno dei server MIT.EDU. Sempre uno a caso:
$ 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
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 ai.mit.edu, in modo
che la prossima volta potrete rivolgere direttamente loro interrogazioni
sui nomi di ai.mit.edu. Named ha anche raccolto
informazioni su mit.edu, in modo da rispondere più celermente se
venisse richiesto www.mit.edu.
Così partendo da . 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.
Secondo l'analogia dell'albero, ogni "." del nome rappresenta un
punto di diramazione. Le parti che stanno tra i "." sono i nomi di
singoli rami dell'albero.
Abbiamo scalato l'albero scegliendo un nome a piacere
(prep.ai.mit.edu), prima abbiamo scoperto la radice (.) e poi
siamo andati alla ricerca del prossimo ramo da scalare, nel nostro caso
edu. Una volta trovato questo, l'abbiamo scalato passando per il
server che conosceva questa parte di nome. Dopo abbiamo ricercato il
ramo mit sopra il ramo edu (per avere mit.edu) e abbiamo
scalato anch'esso sfruttando il server che conosceva mit.edu.
Ancora, abbiamo cercato ai.mit.edu 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 prep.ai.mit.edu, ma è molto semplice.
Un dominio importante ma poco discusso in precedenza è in-addr.arpa.
Anch'esso è annidato come i domini "normali". in-addr.arpa 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 in-addr.arpa. Se avete un indirizzo
di una macchina, p.e. 198.186.203.77, named procede cercando
77.203.186.198.in-addr.arpa/ proprio come ha fatto con prep.ai.mit.edu.
Esempio: Se non ha trovato niente nella cache, chiede ad un root server,
m.root-servers.net vi riporta ad altri root server.
b.root-servers.net vi riporta direttamente a bitsy.mit.edu/.
Dovreste essere in grado di prendere da qui il nome.
Adesso definiremo il nostro dominio. Stiamo per creare il dominio
linux.bogus 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).
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ì pat.uio.no è
identico a Pat.UiO.No.
Abbiamo già iniziato questa parte con questa riga in
named.conf:
zone "0.0.127.in-addr.arpa" {
type master;
file "pz/127.0.0";
};
Per favore notate in questo file l'assenza del "." alla fine
dei nomi del dominio. Questo significa che ora definiremo la zona
0.0.127.in-addr.arpa, che siamo il server primario ("master server")
per essa e che è descritta nel file chiamato pz/127.0.0.
Abbiamo già impostato questo file:
$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.
Per favore notate in questo file il "." alla fine di tutti
i nomi di dominio completi, in contrasto col file named.conf di
prima. Alcune persone hanno l'abitudine di iniziare ogni file relativo a
una zona con una direttiva $ORIGIN, ma questo è superfluo.
L'origine (che appartiene alla gerarchia del DNS) di un file zona è
specificata nella sezione delle zone nel file named.conf, in
questo caso è 0.0.127.in-addr.arpa.
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:
0.0.127.in-addr.arpa. IN SOA ...
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:
0.0.127.in-addr.arpa. IN NS ns.linux.bogus
Essa dice al DNS quale macchina è il name server per il dominio
0.0.127.in-addr.arpa: è appunto ns.linux.bogus. È
consuetudine associare a "ns" la parola name server, analogamente a
quanto succede ai web server, di solito associati a www.qualcosa.
Il nome potrebbe essere uno qualsiasi.
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
localhost.
Il record SOA è il preambolo di tutti 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 ns.linux.bogus),
chi è responsabile per i suoi contenuti (hostmaster@linux.bogus,
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 $TTL 3D. Mettetela in tutti i vostri file di zona.
Adesso fate ripartire named (il comando è rndc stop;named) e usate
dig per esaminare cosa avete fatto. -x serve per le interrogazioni
inverse:
$ 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
si ottiene localhost da 127.0.0.1, bene. Ora per il nostro scopo
principale, il dominio linux.bogus, inserite una nuova sezione "zone" in
named.conf:
zone "linux.bogus" {
type master;
notify no;
file "pz/linux.bogus";
};
Notate ancora l'assenza del "." finale nel nome del dominio nel
file named.conf.
Nel file di zona linux.bogus metteremo dei dati completamente
fasulli:
;
; 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
Bisogna notare due cose a proposito del record SOA. ns.linux.bogus
deve 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, hostmaster.linux.bogus 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).
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 qualcuno@linux.bogus;
nel nostro caso si tratta di mail.linux.bogus o mail.friend.bogus.
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 mail.friend.bogus
che appunto ha priorità 20 nel nostro caso.
Fate ripartire named con rndc reload. Esaminate i risultati con
dig:
$ 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
Con un accurato esame scoprirete un errore. La riga
linux.bogus. 259200 IN MX 10 mail.linux.bogus.linux.bogus.
è sbagliata. Dovrebbe essere:
linux.bogus. 259200 IN MX 10 mail.linux.bogus.
Ho deliberatamente fatto quest'errore in modo che impariate da esso :-). Cercando nel file di zona scopriremo che alla riga
MX 10 mail.linux.bogus ; Primary Mail Exchanger
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 linux.bogus.linux.bogus.
Dunque sia:
MX 10 mail.linux.bogus. ; Mail Exchanger Primario
oppure
MX 10 mail ; Mail Exchanger Primario
è 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 "." o dovrebbe essere
escluso del tutto, in questo caso verrà sostituito dall'origine.
Devo stressarvi ripetendovi che nel file named.conf non ci devono
essere "." alla fine dei nomi di dominio. Non avete idea di quante
volte un "." di troppo (o la sua assenza) abbia ingarbugliato le
cose e confuso a morte chi ha avuto a che farci.
Dunque ecco qua il nuovo file di zona, con qualche informazione extra messa nel modo giusto:
;
; 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.
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 mai riferirsi a un record CNAME, dovrebbero far rifimento soltanto a qualcosa che abbia un record A, cioè non è auspicabile avere
foobar CNAME www ; NO!
ma è corretto avere
foobar CNAME ns ; SÌ!
Caricate il nuovo database facendo rndc reload, questo imporrà a
named di rileggere i suoi file.
$ 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
È buono. Come potete vedere somiglia un sacco allo stesso file di
zona. Vediamo cosa dice per www da solo:
> 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
In altre parole, il vero nome diwww.linux.bogus è
ns.linux.bogus e vi da qualche informazione a proposito di ns,
abbastanza per connettervi ad esso se voi foste un programma.
Ora siamo a metà strada.
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.
Mettete questo in named.conf:
zone "196.168.192.in-addr.arpa" {
type master;
notify no;
file "pz/192.168.196";
};
È esattamente come per 0.0.127.in-addr.arpa e i contenuti sono
simili:
$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.
Adesso fate ripartire named (rndc reload) e esaminate ancora
il lavoro con dig :
$ 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
pare OK, elencate tutto per fare un esame accurato:
$ 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
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 : Far partire named
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
notify no;. 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??
Naturalmente questo dominio è veramente fasullo e così tutti gli indirizzi in esso. Per un vero esempio tratto dalla vita reale leggete il prossimo capitolo.
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.
Discuterò due problematiche del lookup inverso viste dall'esterno della vostra rete:
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.
Anche la zona inversa deve essere delegata. Se avete ottenuto
la rete 192.168.196 con il dominio linux.bogus dal vostro
provider, esso dovrà mettere un record NS nella
vostra zona inversa così come per la vostra zona di forward.
Se seguirete la catena partendo da in-addr.arpa 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.
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.
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 Ask Mr. DNS per una buona spiegazione e per saper come trattare il problema.
L'avete letto? Non l'andrò a spiegare, quindi leggetelo.
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.
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.
Nei dintorni c'è un'altra trappola in agguato. I vecchi risolutori
non sono abilitati a sfruttare il trucco del CNAME 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).
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".
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.
Un server secondario è semplicemente un name server che copia i file di zona dal server primario. Si imposta così:
zone "linux.bogus" {
type slave;
file "sz/linux.bogus";
masters { 192.168.196.2; };
};
Per copiare i dati si usa un meccanismo chiamato trasferimento di zona ("zone-transfer"). Il trasferimento di zona è controllato dal vostro record SOA:
@ 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
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.