Avanti Indietro Indice

4. Un semplice dominio.

Come impostare il vostro dominio.

4.1 Ma prima un po' di asciutta teoria

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.

4.2 Il nostro dominio.

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.

4.3 La zona inversa (reverse zone)

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.

4.4 Qualche parola di avvertimento.

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.

4.5 Perché non funziona il lookup inverso (reverse lookup).

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:

La zona inversa non è delegata.

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.

Vi hanno dato una sottorete classless.

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


Avanti Indietro Indice