Come impostare il vostro dominio.
Prima di iniziare veramente con questa sezione vi proporrò un
po' di teoria e un esempio su come il DNS lavora. E voi 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 pronunciato `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
in un albero esso ha la radice e si dirama verso l'esterno. Se avete
qualche conoscenza d'informatica riconoscerete nel DNS un albero di
ricerca, e scoprirete nodi, nodi-foglia e spigoli.
Quando comincia la ricerca di una macchina la richiesta procede
ricorsivamente nella gerarchia, iniziando dall'apice. Se volete trovare
prep.ai.mit.edu il vostro name server dovrà prima scoprire quale
name server gestisce edu. Esso dunque chiede a uno dei .
server (sa già quali sono i server . , è a questo che
serve il file root.hints), e il . fornisce una lista dei
server edu:
$ nslookup
Default Server: localhost
Address: 127.0.0.1
Iniziate a interrogare un name server:
> server c.root-servers.net.
Default Server: c.root-servers.net
Address: 192.33.4.12
Impostate il tipo di interrogazione (query type) su NS (name server records):
> set q=ns
interrogate su edu:
> edu.
Il . finale qui è significativo, dice a nslookup che la nostra
richiesta è relativa a edu è direttamente sotto a . (e non sotto
un altro dominio presente nel search, questo velocizza la ricerca)
edu nameserver = A.ROOT-SERVERS.NET
edu nameserver = H.ROOT-SERVERS.NET
edu nameserver = B.ROOT-SERVERS.NET
edu nameserver = C.ROOT-SERVERS.NET
edu nameserver = D.ROOT-SERVERS.NET
edu nameserver = E.ROOT-SERVERS.NET
edu nameserver = I.ROOT-SERVERS.NET
edu nameserver = F.ROOT-SERVERS.NET
edu nameserver = G.ROOT-SERVERS.NET
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
G.ROOT-SERVERS.NET internet address = 192.112.36.4
Questo significa che tutti i server ROOT-SERVERS.NET risolvono
EDU., così potremo interrogare uno qualunque di essi. Continueremo
a usare il C. Adesso vogliamo sapere chi risolve il prossimo
livello del nostro nome di dominio: mit.edu.:
> mit.edu.
Server: c.root-servers.net
Address: 192.33.4.12
Non-authoritative answer:
mit.edu nameserver = W20NS.mit.edu
mit.edu nameserver = BITSY.mit.edu
mit.edu nameserver = STRAWB.mit.edu
Authoritative answers can be found from:
W20NS.mit.edu internet address = 18.70.0.160
BITSY.mit.edu internet address = 18.72.0.3
STRAWB.mit.edu internet address = 18.71.0.151
steawb, w20ns e bitsy risolvono mit.edu,
ne sceglieremo uno e lo interrogheremo sul prossimo livello ancora:
ai.mit.edu:
> server W20NS.mit.edu.
I nomi di host non sono case sensitive, ma io uso il mouse per tagliare e incollare così come vengono dallo schermo.
Server: W20NS.mit.edu
Address: 18.70.0.160
> ai.mit.edu.
Server: W20NS.mit.edu
Address: 18.70.0.160
Non-authoritative answer:
ai.mit.edu nameserver = ALPHA-BITS.AI.MIT.EDU
ai.mit.edu nameserver = GRAPE-NUTS.AI.MIT.EDU
ai.mit.edu nameserver = TRIX.AI.MIT.EDU
ai.mit.edu nameserver = MUESLI.AI.MIT.EDU
ai.mit.edu nameserver = LIFE.AI.MIT.EDU
ai.mit.edu nameserver = BEET-CHEX.AI.MIT.EDU
ai.mit.edu nameserver = MINI-WHEATS.AI.MIT.EDU
ai.mit.edu nameserver = COUNT-CHOCULA.AI.MIT.EDU
ai.mit.edu nameserver = MINTAKA.LCS.MIT.EDU
Authoritative answers can be found from:
AI.MIT.EDU nameserver = ALPHA-BITS.AI.MIT.EDU
AI.MIT.EDU nameserver = GRAPE-NUTS.AI.MIT.EDU
AI.MIT.EDU nameserver = TRIX.AI.MIT.EDU
AI.MIT.EDU nameserver = MUESLI.AI.MIT.EDU
AI.MIT.EDU nameserver = LIFE.AI.MIT.EDU
AI.MIT.EDU nameserver = BEET-CHEX.AI.MIT.EDU
AI.MIT.EDU nameserver = MINI-WHEATS.AI.MIT.EDU
AI.MIT.EDU nameserver = COUNT-CHOCULA.AI.MIT.EDU
AI.MIT.EDU nameserver = MINTAKA.LCS.MIT.EDU
ALPHA-BITS.AI.MIT.EDU internet address = 128.52.32.5
GRAPE-NUTS.AI.MIT.EDU internet address = 128.52.36.4
TRIX.AI.MIT.EDU internet address = 128.52.37.6
MUESLI.AI.MIT.EDU internet address = 128.52.39.7
LIFE.AI.MIT.EDU internet address = 128.52.32.80
BEET-CHEX.AI.MIT.EDU internet address = 128.52.32.22
MINI-WHEATS.AI.MIT.EDU internet address = 128.52.54.11
COUNT-CHOCULA.AI.MIT.EDU internet address = 128.52.38.22
MINTAKA.LCS.MIT.EDU internet address = 18.26.0.36
Quindi muesli.ai.mit.edu è un nameserver per ai.mit.edu:
> server MUESLI.AI.MIT.EDU
Default Server: MUESLI.AI.MIT.EDU
Address: 128.52.39.7
Adesso cambio il tipo di interrogazione (query): abbiamo trovato il name
server e quindi vogliamo chiedere tutto ciò che muesli sa a proposito di
prep.ai.mit.edu.
> set q=any
> prep.ai.mit.edu.
Server: MUESLI.AI.MIT.EDU
Address: 128.52.39.7
prep.ai.mit.edu CPU = dec/decstation-5000.25 OS = unix
prep.ai.mit.edu
inet address = 18.159.0.42, protocol = tcp
ftp telnet smtp finger
prep.ai.mit.edu preference = 1, mail exchanger = gnu-life.ai.mit.edu
prep.ai.mit.edu internet address = 18.159.0.42
ai.mit.edu nameserver = beet-chex.ai.mit.edu
ai.mit.edu nameserver = alpha-bits.ai.mit.edu
ai.mit.edu nameserver = mini-wheats.ai.mit.edu
ai.mit.edu nameserver = trix.ai.mit.edu
ai.mit.edu nameserver = muesli.ai.mit.edu
ai.mit.edu nameserver = count-chocula.ai.mit.edu
ai.mit.edu nameserver = mintaka.lcs.mit.edu
ai.mit.edu nameserver = life.ai.mit.edu
gnu-life.ai.mit.edu internet address = 128.52.32.60
beet-chex.ai.mit.edu internet address = 128.52.32.22
alpha-bits.ai.mit.edu internet address = 128.52.32.5
mini-wheats.ai.mit.edu internet address = 128.52.54.11
trix.ai.mit.edu internet address = 128.52.37.6
muesli.ai.mit.edu internet address = 128.52.39.7
count-chocula.ai.mit.edu internet address = 128.52.38.22
mintaka.lcs.mit.edu internet address = 18.26.0.36
life.ai.mit.edu internet address = 128.52.32.80
E così partendo da . abbiamo scoperto i name server successivi
per ogni livello nel nome di dominio. Se usavate 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.
Nell'analogo albero ogni ``.'' del nome rappresenta un punto di
diramazione. E le parti che stanno tra i ``.'' sono i nomi dei
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. In
informatica solitamente si dice che prep è una foglia
dell'albero.
Un dominio poco discusso in precedenza è in-addr.arpa.
Anch'esso è gestito 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 qua è che gli indirizzi IP sono scritti
in ordine inverso nel dominio in-addr.arpa. Se avete un indirizzo
di una macchina: 192.128.52.43 named procede come nell'esempio
prep.ai.mit.edu: scopre il server arpa.. Scopre il server
in-addr.arpa., scopre il server 192.in-addr.arpa., scopre
il server 128.192.in-addr.arpa., scopre il server
52.128.192.in-addr.arpa.. Scopre i record richiesti per ricavare
il nome di 43.52.128.192.in-addr.arpa..
Geniale ehh?? (dite `Sì') Tuttavia, a livello teorico, la conversione
dei numeri potrà risultare difficoltosa per anni.
Ho detto una bugia. DNS non funziona precisamente come ho descritto. Ma comunque in maniera simile a questa.
Adesso definiremo il nostro dominio. Stiamo per creare il dominio
linux.bogus e per definire le macchine in esso. Utilizzo nomi di
dominio completamente fasulli per essere sicuro di non disturbare
nessuno. (nessuno Là Fuori.)
Un'ultima cosa prima di iniziare: Non tutti i caratteri sono permessi
nei nomi degli host. Siamo limitati ai caratteri dell'alfabeto inglese:
a-z, numeri: 0-9 e al carattere '-' (dash, 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 linea 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 master server per essa e che
essa è descritta nel file chiamato pz/127.0.0. Abbiamo
già impostato questo file:
@ IN SOA ns.linux.bogus. hostmaster.linux.bogus. (
1 ; Serial
8H ; Refresh
2H ; Retry
1W ; 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 (Inizio dell'Autorità). La `@' è una notazione speciale che indica l'origine, e poiché la colonna `dominio' di questo file dice 0.0.127.in-addr.arpa la prima linea in realtà significa:
0.0.127.in-addr.arpa. IN SOA ...
NS è il RR Name Server. Non c'è la '@' all'inizio di questa linea: è implicita perché l'ultima linea comincia con la '@'. Questo fa risparmiare un po' di battute sulla tastiera. In questo modo la line NS può essere scritta:
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 ai
web server che di solito sono associati a www.qualcosa; il
nome può però essere qualunque.
E alla fine il record PTR dice che l'host all'indirizzo 1 nella
sottorete tt/0.0.127.in-addr.arpa/,i.e., 127.0.0.1 è chiamato
localhost.
Il record SOA è il preambolo di tutti i file di zona, e deve
esisterne esattamente uno in ogni file di zona. 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 e-mail 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.
Adesso fate ripartire named (il comando è ndc restart) e usate
nslookup per esaminare cosa avete fatto:
$ nslookup
Default Server: localhost
Address: 127.0.0.1
> 127.0.0.1
Server: localhost
Address: 127.0.0.1
Name: localhost
Address: 127.0.0.1
si ottiene localhost da 127.0.0.1, bene. Ora per il nostro scopo
principale, il dominio linux.bogus, inserite una nuova 'zona' in
named.conf:
zone "linux.bogus" {
notify no;
type master;
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:
;
; File di zona per linux.bogus
;
; File di zona completo
;
@ IN SOA ns.linux.bogus. hostmaster.linux.bogus. (
199802151 ; numero di serie, data di oggi + # di serie di oggi
8H ; refresh, secondi
2H ; retry, secondi
1W ; expire, secondi
1D ) ; minimum, secondi
;
NS ns ; Indirizzo Inet del name server
MX 10 mail.linux.bogus ; Mail Exchanger Primario
MX 20 mail.friend.bogus. ; Mail Exchanger Secondario
;
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é la/le persona/e che
mantengono il DNS leggano la posta frequentemente.
Ogni mail 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.
Se non funzionasse la posta potrà essere spedita a un server con un
numero più alto, un mail server secondario, i.e. mail.friend.bogus
che appunto ha priorità 20 nel nostro caso.
Fate ripartire named con ndc restart. Esaminate i risultati con
nslookup:
$ nslookup
> set q=any
> linux.bogus
Server: localhost
Address: 127.0.0.1
linux.bogus
origin = ns.linux.bogus
mail addr = hostmaster.linux.bogus
serial = 199802151
refresh = 28800 (8 hours)
retry = 7200 (2 hours)
expire = 604800 (7 days)
minimum ttl = 86400 (1 day)
linux.bogus nameserver = ns.linux.bogus
linux.bogus preference = 10, mail exchanger = mail.linux.bogus.linux.bogus
linux.bogus preference = 20, mail exchanger = mail.friend.bogus
linux.bogus nameserver = ns.linux.bogus
ns.linux.bogus internet address = 192.168.196.2
mail.linux.bogus internet address = 192.168.196.4
Con un accurato esame scoprirete un bug (un errore). La linea
linux.bogus preference = 10, mail exchanger = mail.linux.bogus.linux.bogus
è sbagliata. Dovrebbe essere:
linux.bogus preference = 10, mail exchanger = mail.linux.bogus
Ho deliberatamente fatto quest'errore in modo che impariate da esso :-). Cercando nel file di zona scopriremo che alla linea
MX 10 mail.linux.bogus ; Mail Exchanger Primario
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
o
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 verrebbe sostituito dall'origine.
Devo stressarvi con la storia del 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 delle indiavolate persone.
Dunque ecco qua il nuovo file di zona, con qualche informazione extra messa nel modo giusto:
;
; File di zona per linux.bogus
;
; Il file di zona completo
;
@ IN SOA ns.linux.bogus. hostmaster.linux.bogus. (
199802151 ; # di serie, data di oggi + # di serie di oggi
8H ; refresh, secondi
2H ; retry, secondi
1W ; expire, secondi
1D ) ; minimum, secondi
;
TXT "Linux.Bogus, il proprio consulente DNS"
NS ns ; Indirizzo Inet del name server
NS ns.friend.bogus.
MX 10 mail ; Mail Exchanger Primario
MX 20 mail.friend.bogus. ; Mail Exchanger Secondario
localhost A 127.0.0.1
gw A 192.168.196.1
HINFO "Cisco" "IOS"
TXT "Il router"
ns A 192.168.196.2
MX 10 mail
MX 20 mail.friend.bogus.
HINFO "Pentium" "Linux 2.0"
www CNAME ns
donald A 192.168.196.3
MX 10 mail
MX 20 mail.friend.bogus.
HINFO "i486" "Linux 2.0"
TXT "DEK"
mail A 192.168.196.4
MX 10 mail
MX 20 mail.friend.bogus.
HINFO "386sx" "Linux 1.2"
ftp A 192.168.196.5
MX 10 mail
MX 20 mail.friend.bogus.
HINFO "P6" "Linux 2.1.86"
Ci sono un sacco di nuovi RR qua: HINFO (Host Information) è composto da due parti, è buona cosa dividerle entrambe con le virgolette. La prima parte indica l'hardware o la CPU della macchina, e la seconda parte il software o il S(istema)O(perativo) della macchina. La macchina chiamata `ns' ha una CPU Pentium e Linux 2.0 come SO. CNAME (Canonical Name) è un modo per dare a ogni macchina diversi nomi. 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Ì!
È anche consigliabile assumere che un CNAME non è un nome di host
legale per un indirizzo email: webmaster@www.linux.bogus è un
indirizzo email illegale generato dall'impostazione errata di cui sopra.
Anche se per voi funziona, qualche amministratore di server di posta vi
farà rispettare questa regola.
Il modo per impedire tutto questo è usare un record A (o anche un
record tipo MX):
www A 192.168.196.2
Alcuni maghi-dell'architettura-di-bind raccomandano di non usare CNAME per nulla. Ma la discussione sul perché o sul perché no va oltre questo HOWTO.
Ma coma potrete notare, questo HOWTO e molti siti non seguono questa regola.
Caricate il nuovo database facendo ndc reload, questo imporrà a
named di rileggere i suoi file.
$ nslookup
Default Server: localhost
Address: 127.0.0.1
> ls -d linux.bogus
Questo fa sì che vengano elencati tutti i record, risulta così:
[localhost]
$ORIGIN linux.bogus.
@ 1D IN SOA ns hostmaster (
199802151 ; serial
8H ; refresh
2H ; retry
1W ; expiry
1D ) ; minimum
1D IN NS ns
1D IN NS ns.friend.bogus.
1D IN TXT "Linux.Bogus, your DNS consultants"
1D IN MX 10 mail
1D IN MX 20 mail.friend.bogus.
gw 1D IN A 192.168.196.1
1D IN HINFO "Cisco" "IOS"
1D IN TXT "Il router"
mail 1D IN A 192.168.196.4
1D IN MX 10 mail
1D IN MX 20 mail.friend.bogus.
1D IN HINFO "386sx" "Linux 1.0.9"
localhost 1D IN A 127.0.0.1
www 1D IN CNAME ns
donald 1D IN A 192.168.196.3
1D IN MX 10 mail
1D IN MX 20 mail.friend.bogus.
1D IN HINFO "i486" "Linux 1.2"
1D IN TXT "DEK"
ftp 1D IN A 192.168.196.5
1D IN MX 10 mail
1D IN MX 20 mail.friend.bogus.
1D IN HINFO "P6" "Linux 1.3.59"
ns 1D IN A 192.168.196.2
1D IN MX 10 mail
1D IN MX 20 mail.friend.bogus.
1D IN HINFO "Pentium" "Linux 1.2"
È 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 covertire 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 o meno, e se si, anche quanta priorità dovrà essere assegnata loro. 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" {
notify no;
type master;
file "pz/192.168.196";
};
È esattamente come per 0.0.127.in-addr.arpa, e i contenuti sono
simili:
@ IN SOA ns.linux.bogus. hostmaster.linux.bogus. (
199802151 ; # di serie, data di oggi + # di serie di oggi
8H ; Refresh
2H ; Retry
1W ; 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 (ndc restart) e esaminate ancora
il lavoro con nslookup :
> 192.168.196.4 Server: localhost Address: 127.0.0.1 Name: mail.linux.bogus Address: 192.168.196.4
pare OK, elencate tutto per fare un esame accurato:
> ls -d 196.168.192.in-addr.arpa
[localhost]
$ORIGIN 196.168.192.in-addr.arpa.
@ 1D IN SOA ns.linux.bogus. hostmaster.linux.bogus. (
199802151 ; serial
8H ; refresh
2H ; retry
1W ; expiry
1D ) ; minimum
1D IN NS ns.linux.bogus.
1 1D IN PTR gw.linux.bogus.
2 1D IN PTR ns.linux.bogus.
3 1D IN PTR donald.linux.bogus.
4 1D IN PTR mail.linux.bogus.
5 1D IN PTR ftp.linux.bogus.
@ 1D IN SOA ns.linux.bogus. hostmaster.linux.bogus. (
199802151 ; serial
8H ; refresh
2H ; retry
1W ; expiry
1D ) ; minimum
Sembra buono! Se il vostro output non viene simile a questo guardate i messaggi d'errore nel vostro syslog. Ho spiegato come farlo all'inizio del capitolo.
Ci sono delle cose che a questo punto vorrei aggiungere. I numeri IP
usati negli esempi sono stati presi dai blocchi delle "reti private" ,
i.e., non è permesso usarli esplicitamente su internet. Per questo sono
comodi da usare in un HOWTO. La seconda cosa riguarda la linea
notify no;. Dice a named che non deve notificare al suo server
secondario (slave, schiavo) quando riceve un aggiornamento di uno dei
suoi file di zona. In bind-8 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??
E 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 che andiate avanti c'è bisogno che il lookup inverso funzioni bene sul vostro nameserver. 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 nameserver all'altro come è stato spiegato nella sezione teorica di sopra. L'avete letta vero? Se la zona inversa non vi 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 di servizi, loro dovranno 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 service 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 brillanti persone 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 qualche cosa potrebbe non funzionare. Leggete per favore Ask Mr. DNS at http://www.acmebw.com/askmrdns/00007.htm per una buona spiegazione e per come trattare il problema.
L'avete letto? Non sto per spiegarlo 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 hanno una chiara visione di questa. 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 nslookup.
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 dontorni 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 risolvere inversamente
(reverse-resolving) la vostra macchina. Questo
problema può portare ad assegnare al servizio una scorretta classe di
accesso, all'accesso negato o a qualcosa del genere.
Se inciampaste in un servizio di questo tipo l'unica soluzione (che io
conosca) è 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 via web (Web-based) che permettono di inserire i vostri dati sulla zona inversa , oppure con altri sistemi "automagici".