Avanti Indietro Indice

5. Un semplice dominio

Come impostare il vostro dominio

5.1 Ma prima un po' di teoria

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.

5.2 Il nostro dominio

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.

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

5.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, 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.

5.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 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:

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

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

5.6 Server secondari ("slave server")

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.


Avanti Indietro Indice

Hosting by: hurra.com
Generated: 2007-01-26 17:56:19