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