DNS HOWTO Nicolai Langfeldt (dns-howto(at)langfeldt.net), Jamie Norrish e altri. V9.0, 20 Dicembre 2001 Come diventare un amministratore DNS da strapazzo. Traduzione di Federico Cossu (federicocossu(at)libero.it). 1. Preambolo Parole chiave: DNS, BIND, BIND-4, BIND-8, BIND-9, named, dialup, PPP, slip, ISDN, Internet, domain, name, hosts, resolution, caching. Questo documento fa parte del Linux Documentation Project. 1.1. Note legali (C)opyright 1995-2001 Nicolai Langfeldt, Jamie Norrish & Co. Do not modify without amending copyright, distribute freely but retain copyright message. (C)opyright 1995-1999 Nicolai Langfeldt, Jamie Norrish & Co. Non modificare senza emendare il copyright, si può distribuire liberamente ma includendo il messaggio di copyright. 1.2. Crediti e richieste di aiuto Voglio ringraziare tutte le persone che ho disturbato con la lettura di questo HOWTO (voi sapete di chi parlo) e le numerose persone che mi hanno mandato in email suggerimenti e note. Questo non sarà mai un documento finito. Vi prego di mandarmi delle email se avete incontrato problemi o successi, questo contribuirà a migliorare l'HOWTO. Così vi prego di mandare commenti, domande o soldi a janl(at)math.uio.no. Oppure comprate il mio libro sul DNS (è intitolato "The Concise Guide to DNS and BIND" , nella bibliografia il codice ISBN). In caso mandiate delle email per le quali vi attendete delle risposte, per favore assicuratevi che l'indirizzo cui inviare la risposta sia corretto e operativo. Inoltre, per favore leggete la sezione ``Domande e risposte'' prima di scrivermi. Un'altra cosa: comprendo solo il norvegese e l'inglese. Questo è un HOWTO. L'ho mantenuto come parte del progetto LDP dal 1995. Durante il 2000 ho scritto un libro sullo stesso soggetto. Mi sento in dovere di dire che questo HOWTO, pur essendo molto simile al libro, non è una brutta copia messa lì per lanciare il libro sul mercato. I lettori di questo HOWTO mi hanno aiutato a capire quali sono le parti del DNS più difficili da capire. E ciò ha aiutato la stesura del libro, ma il libro ha aiutato a capire di cosa l'HOWTO aveva bisogno. L'HOWTO integra il libro. Il libro integra la versione 3 di questo HOWTO. I miei sentiti ringraziamenti all'editore del libro, Que, che ha creduto in me :-) 1.3. Dediche Questo HOWTO è dedicato a Anne Line Norheim Langfeldt. Anche se lei non lo leggerà mai poiché non è quel tipo di ragazza. 1.4. Versioni Aggiornate Dovrebbe essere possibile trovare versioni aggiornate di questo HOWTO all'indirizzo e anche . Recatevi lì se la versione del documento in vostro possesso è più vecchia di 9 mesi. 2. Introduzione Cos'è e cosa non è. DNS è il Domain Name System. DNS converte i nomi delle macchine negli indirizzi IP che queste macchine hanno nella rete. In pratica fa corrispondere ("mappa", come dice lo jargon) i nomi agli indirizzi e viceversa e in più fa qualche altra cosa. Questo HOWTO spiega come definire questa corrispondenza, o mappatura, usando un sistema Unix, con alcune cose specifiche per Linux. Una corrispondenza è semplicemente un'associazione tra due cose, in questo caso si tratta del nome di una macchina, come ftp.linux.org, e del numero IP (o indirizzo) della stessa macchina 199.249.150.4. Il DNS è in grado anche di mappare nell'altro senso, dal numero IP al nome della macchina; questo è detto mappatura inversa ("reverse mapping"). DNS è, per i non iniziati (voi ;-), una delle aree più opache dell'amministrazione di rete. Fortunatamente non è così dura. Questo HOWTO cercherà di rendere più chiare alcune cose. Esso descrive come impostare un semplice name server DNS. Partendo da un server cache ("caching only") per poi passare all'impostazione di un server DNS primario per un dominio. Per configurazioni più complesse date uno sguardo alla sezione ``Domande e Risposte'' di questo documento. Se non fosse descritto qui avrete bisogno di leggere la Vera Documentazione. Tornerò più tardi su in che cosa consista questa Vera Documentazione nell'``ultimo capitolo'' Prima di cominciare dovrete configurare la vostra macchina in modo da potervi connettere con telnet alla macchina e da essa verso l'esterno e che possa connettersi con successo alla rete. In particolar modo dovreste poter fare telnet 127.0.0.1 e ottenere la vostra stessa macchina (provate subito!). Avrete anche bisogno di un buon /etc/nsswitch.conf (oppure /etc/host.conf) e dei file /etc/resolv.conf e /etc/hosts come punto di partenza, finché non spiegherò la loro funzione. Se non avete già tutto questo impostato e funzionante il Networking-HOWTO o il Networking-Overview-HOWTO spiegano come farlo. Leggeteli. Quando dico "la vostra macchina" intendo la macchina sulla quale state cercando di impostare il DNS. Nessun'altra macchina che potreste avere è coinvolta nel vostro lavoro. Assumerò che non siate dietro un qualche tipo di firewall che blocca le interrogazioni dei nomi. Se invece lo siete, avrete bisogno di una speciale configurazione. Guardate la sezione ``Domande e Risposte''. Il servizio di risoluzione dei nomi su Unix è svolto da un programma chiamato named. Questo fa parte del pacchetto "BIND" che è coordinato da Paul Vixie del Internet Software Consortium. Named è incluso in molte distribuzioni Linux e di solito è installato come /usr/sbin/named da un pacchetto chiamato BIND, maiuscolo o minuscolo a seconda di chi ha creato il pacchetto. Se avete named probabilmente potrete usarlo, se non l'avete potrete prendere i binari da un qualunque sito ftp su Linux, altrimenti prenderete i più recenti e grandiosi sorgenti da . Questo HOWTO si riferisce alla versione 9 di BIND. Le vecchie versioni dell'HOWTO, che fanno riferimento a bind 4 e 8, sono ancora disponibili presso . Se la pagina di man di named fa riferimento (per precisione alla fine, nella sezione FILES) a named.conf avete bind 8, se fa riferimento a named.boot avete bind 4. Se avete il 4 e siete coscienti del problema sicurezza dovreste aggiornare alla versione 8. Adesso. DNS è un database distribuito sulla rete. Fate attenzione a cosa ci metterete dentro. Se ci metterete spazzatura, voi e gli altri ne ricaverete solo quella. Mantenete il vostro DNS snello e coerente, così otterrete un buon servizio da esso. Imparate ad usarlo, ad amministrarlo, a risolverne eventuali problemi e diventerete un altro buon amministratore che impedisce alla rete di cadere sulle ginocchia a causa della cattiva manutenzione. Suggerimento: Fate una copia di backup di tutti i file che vi chiederò di modificare e che già avete, affinché possiate tornare presto operativi in caso non funzioni. 2.1. Altre implementazioni di Name Server. Questa sezione è stata scritta da Joost van Baal. Esistono diversi software per fare della vostra macchina un DNS server. C'è BIND ( ), che è l'implementazione trattata da questo HOWTO. È il più popolare name server in circolazione ed è usato nella stragrande maggioranza delle macchine name server che ci sono su Internet. È stato sviluppato a partire dagli anni '80. È disponibile sotto licenza BSD. A causa del fatto che è il più popolare esiste un sacco di documentazione su esso. Comunque, ci sono stati problemi relativi alla sicurezza di BIND. Poi c'è djbdns ( ), un pacchetto DNS relativamente nuovo, scritto da Daniel J. Bernstein, l'autore di qmail. È una suite modulare: tanti piccoli programmi che si occupano di tutte quelle funzioni che un name server deve saper svolgere. È stato progettato tenendo bene in mente la sicurezza. Utilizza un formato di file di zona particolarmente semplice ed è generalmente facile da configurare. Però, a causa del fatto che è poco conosciuto, il vostro esperto locale potrebbe non essere in grado di aiutarvi con esso. Sfortunatamente, questo software non è Open Source. L'annuncio dell'autore è su . Se tale software sia davvero un miglioramento rispetto alle alternative più datate è soggetto di molte discussioni. Un dibattito (o piuttosto una flame-war?) su BIND contro djbdns, cui hanno partecipato quelli di ISC, si trova presso . 3. Un name server cache Un primo approccio alla configurazione del DNS, molto utile per gli utenti con collegamento telefonico, cable modem, ADSL e simili Sulla Red Hat e sulle distribuzioni da essa derivate potrete fare le cose descritte in questa prima sezione dell'HOWTO installando i pacchetti bind, bind-utils e caching-nameserver. Se siete utenti Debian installerete semplicemente bind (o bind9, pur non essendo BIND 9 supportato dall'attuale distribuzione stabile di Debian, potato) e bind-doc. Naturalmente il solo installare questi pacchetti non vi insegnerà tanto quanto leggere l'HOWTO. Quindi installate pure i pacchetti e poi verificate i file che essi hanno installato. Un name server che fa solo da cache troverà le risposte alle interrogazioni e ricorderà le risposte la prossima volta che ne avrete bisogno. Questo abbrevierà significativamente il tempo di attesa per le interrogazioni successive, specialmente se avete una connessione lenta. Prima di tutto vi occorre un file chiamato /etc/named.conf (Debian: /etc/bind/named.conf). Questo viene letto quando named parte. Per adesso dovrebbe contenere semplicemente: ______________________________________________________________________ // Config file for caching only name server // // The version of the HOWTO you read may contain leading spaces // (spaces in front of the characters on these lines ) in this and // other files. You must remove them for things to work. // // Note that the filenames and directory names may differ, the // ultimate contents of should be quite similar though. options { directory "/var/named"; // Uncommenting this might help if you have to go through a // firewall and things are not working out. But you probably // need to talk to your firewall admin. // query-source port 53; }; controls { inet 127.0.0.1 allow { localhost; } keys { rndc_key; }; }; key "rndc_key" { algorithm hmac-md5; secret "c3Ryb25nIGVub3VnaCBmb3IgYSBtYW4gYnV0IG1hZGUgZm9yIGEgd29tYW4K"; }; zone "." { type hint; file "root.hints"; }; zone "0.0.127.in-addr.arpa" { type master; file "pz/127.0.0"; }; ______________________________________________________________________ I pacchetti presenti nelle distribuzioni Linux potrebbero usare nomi di file differenti da quelli menzionati; conterranno comunque le stesse cose. La riga "directory" dice a named dove andare a cercare i file. Tutti i file nominati in seguito saranno relativi a questa directory. Perciò pz è una directory sotto /var/named, ovvero /var/named/pz. /var/named è la giusta directory in accordo con il Linux File system Standard. Vi è citato il file chiamato /var/named/root.hints, che dovrebbe contenere quanto segue: ______________________________________________________________________ ; ; There might be opening comments here if you already have this file. ; If not don't worry. ; ; About any leading spaces in front of the lines here: remove them! ; Lines should start in a ;, . or character, not blanks. ; . 6D IN NS A.ROOT-SERVERS.NET. . 6D IN NS B.ROOT-SERVERS.NET. . 6D IN NS C.ROOT-SERVERS.NET. . 6D IN NS D.ROOT-SERVERS.NET. . 6D IN NS E.ROOT-SERVERS.NET. . 6D IN NS F.ROOT-SERVERS.NET. . 6D IN NS G.ROOT-SERVERS.NET. . 6D IN NS H.ROOT-SERVERS.NET. . 6D IN NS I.ROOT-SERVERS.NET. . 6D IN NS J.ROOT-SERVERS.NET. . 6D IN NS K.ROOT-SERVERS.NET. . 6D IN NS L.ROOT-SERVERS.NET. . 6D IN NS M.ROOT-SERVERS.NET. A.ROOT-SERVERS.NET. 6D IN A 198.41.0.4 B.ROOT-SERVERS.NET. 6D IN A 128.9.0.107 C.ROOT-SERVERS.NET. 6D IN A 192.33.4.12 D.ROOT-SERVERS.NET. 6D IN A 128.8.10.90 E.ROOT-SERVERS.NET. 6D IN A 192.203.230.10 F.ROOT-SERVERS.NET. 6D IN A 192.5.5.241 G.ROOT-SERVERS.NET. 6D IN A 192.112.36.4 H.ROOT-SERVERS.NET. 6D IN A 128.63.2.53 I.ROOT-SERVERS.NET. 6D IN A 192.36.148.17 J.ROOT-SERVERS.NET. 6D IN A 198.41.0.10 K.ROOT-SERVERS.NET. 6D IN A 193.0.14.129 L.ROOT-SERVERS.NET. 6D IN A 198.32.64.12 M.ROOT-SERVERS.NET. 6D IN A 202.12.27.33 ______________________________________________________________________ Questo file descrive i root name server nel mondo. Esso cambia col tempo e deve essere aggiornato se necessario. Leggete la sezione ``Manutenzione'' per sapere come fare. La sezione successiva in named.conf è l'ultima zone. Spiegherò il suo utilizzo nell'ultimo capitolo, per adesso create solo un file chiamato 127.0.0 nella sottodirectory pz: (Nuovamente, se fate copia e incolla rimuovete gli spazi iniziali) ______________________________________________________________________ $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. ______________________________________________________________________ Le sezioni chiamate key e controls insieme significano che il vostro named potrà essere controllato in remoto da un programma chiamato rndc se esso si connette dall'host locale e identifica se stesso con la chiave segreta codificata. Questa chiave è come una password. Per far sì che rndc funzioni avrete bisogno di un file /etc/rndc.conf come questo : ______________________________________________________________________ key rndc_key { algorithm "hmac-md5"; secret "c3Ryb25nIGVub3VnaCBmb3IgYSBtYW4gYnV0IG1hZGUgZm9yIGEgd29tYW4K"; }; options { default-server localhost; default-key rndc_key; }; ______________________________________________________________________ Come potete vedere il segreto è identico a quello di named.conf. Se volete usare rndc da altre macchine esse devono avere tempi non più distanti di 5 minuti una dall'altra. Raccomando di usare il software ntp (xntpd e ntpdate) per fare ciò. Poi avrete bisogno di un /etc/resolv.conf che somigli vagamente a questo: (togliete gli spazi!) ______________________________________________________________________ search sottodominio.proprio-dominio.edu proprio-dominio.edu nameserver 127.0.0.1 ______________________________________________________________________ La riga "search" specifica su quali domini deve avvenire la ricerca per ogni nome di host al quale volete collegarvi. La riga nameserver specifica l'indirizzo del vostro name server, in questo caso la vostra stessa macchina, poiché è qui che named lavora (127.0.0.1 è corretto, non importa se la macchina ha già un altro indirizzo). Se volete inserire più name server mettete una riga "nameserver" per ognuno di essi. (Nota: named non legge mai questo file, il risolutore che usa named invece sì. Nota 2: in alcuni resolv.conf troverete una riga dove è scritto "domain". È corretto, ma non usate insieme "search" e "domain", funzionerà solo una delle due). Vediamo cosa fa questo file: se un client cerca la macchina pippo, allora il primo tentativo che verrà fatto sarà pippo.sottodominio.vostro-dominio.edu, poi pippo.vostro-dominio.edu e infine pippo. Se un client cerca sunsite.unc.edu, il primo tentativo sarà sunsite.unc.edu.sottodominio.vostro-dominio.edu, poi sunsite.unc.edu.vostro-dominio.edu e infine sunsite.unc.edu. Vi potrebbe convenire non mettere troppi domini nella riga di ricerca, si impiega del tempo a provarli tutti. L'esempio assume che voi facciate parte del dominio sottodominio.vostro-dominio.edu, quindi probabilmente la vostra macchina sarà vostra-macchina.sottodominio.vostro-dominio.edu. La riga di ricerca non dovrebbe contenere il vostro TLD (Top Level Domain, "edu" in questo caso). Se avete spesso bisogno di collegarvi a host in un altro dominio, potrete aggiungerlo in una riga di ricerca come questa: (Ricordate di togliere gli spazi iniziali, se presenti) ______________________________________________________________________ search sottodominio.vostro-dominio.edu vostro-dominio.edu altro-dominio.com ______________________________________________________________________ e così via. Ovviamente dovrete metterci domini reali. Notate l'assenza del punto alla fine dei nomi di dominio. Questo è importante. 3.1. Far partire named Adesso è ora di far partire named. Se state usando una connessione telefonica, per prima cosa collegatevi. Adesso fate partire named, o lanciando lo script /etc/init.d/named start o named direttamente con /usr/sbin/named. Se avete provato prima d'ora qualche versione di named avrete usato ndc. In BIND 9 è stato rimpiazzato da rndc, che può controllare il vostro named da remoto, ma non può far ripartire named un'altra volta. Se andate a leggere il file che contiene il log di sistema (usualmente chiamato /var/log/messages, in Debian è /var/log/daemon, controllate anche la directory /var/log e un altro file da controllare in questa è syslog) quando named parte (fate tail -f /var/log/messages) dovreste leggere qualcosa di simile a: (le righe che terminano per "\" continuano sulla riga successiva) Dec 23 02:21:12 lookfar named[11031]: starting BIND 9.1.3 Dec 23 02:21:12 lookfar named[11031]: using 1 CPU Dec 23 02:21:12 lookfar named[11034]: loading configuration from \ '/etc/named.conf' Dec 23 02:21:12 lookfar named[11034]: the default for the \ 'auth-nxdomain' option is now 'no' Dec 23 02:21:12 lookfar named[11034]: no IPv6 interfaces found Dec 23 02:21:12 lookfar named[11034]: listening on IPv4 interface lo, \ 127.0.0.1#53 Dec 23 02:21:12 lookfar named[11034]: listening on IPv4 interface eth0, \ 10.0.0.129#53 Dec 23 02:21:12 lookfar named[11034]: command channel listening on \ 127.0.0.1#953 Dec 23 02:21:13 lookfar named[11034]: running Se ci sono messaggi d'errore significa che c'è un problema. Named dirà il nome del file in cui si cela. Tornate indietro per controllare quel file e fate ripartire named una volta sistemato. Adesso potete testare la vostra configurazione. Per fare ciò si usava tradizionalmente un programma chiamato nslookup. Oggi si raccomanda di usare dig: $ dig -x 127.0.0.1 ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 26669 ;; 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 02:26:17 2001 ;; MSG SIZE rcvd: 91 Se corrisponde a quello che vedete significa che sta funzionando. Lo spero. Altrimenti tornate indietro e ricontrollate tutto. Ogni volta che cambiate un file dovete far ripartire named con il comando rndc reload. Adesso potete immettere un'interrogazione ("query"). Cercate di fare il lookup di macchine vicine a voi. pat.uio.no è vicina a me, all'università di Oslo: $ dig pat.uio.no ; <<>> DiG 9.1.3 <<>> pat.uio.no ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 15574 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 0 ;; QUESTION SECTION: ;pat.uio.no. IN A ;; ANSWER SECTION: pat.uio.no. 86400 IN A 129.240.130.16 ;; AUTHORITY SECTION: uio.no. 86400 IN NS nissen.uio.no. uio.no. 86400 IN NS nn.uninett.no. uio.no. 86400 IN NS ifi.uio.no. ;; Query time: 651 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Sun Dec 23 02:28:35 2001 ;; MSG SIZE rcvd: 108 dig adesso ha chiesto al vostro named di cercare la macchina pat.uio.no. Poi contatta una delle macchine name server indicate nel file root.hints e chiede loro la strada per arrivarci. Potrebbe essere necessario un po' di tempo prima che sia disponibile il risultato, come potrebbe essere necessario cercare in tutti i domini elencati in /etc/resolv.conf. Se lo chiederete nuovamente, otterrete questo: $ dig pat.uio.no ; <<>> DiG 8.2 <<>> pat.uio.no ;; res options: init recurs defnam dnsrch ;; got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 3 ;; QUERY SECTION: ;; pat.uio.no, type = A, class = IN ;; ANSWER SECTION: pat.uio.no. 23h59m58s IN A 129.240.130.16 ;; AUTHORITY SECTION: UIO.NO. 23h59m58s IN NS nissen.UIO.NO. UIO.NO. 23h59m58s IN NS ifi.UIO.NO. UIO.NO. 23h59m58s IN NS nn.uninett.NO. ;; ADDITIONAL SECTION: nissen.UIO.NO. 23h59m58s IN A 129.240.2.3 ifi.UIO.NO. 1d23h59m58s IN A 129.240.64.2 nn.uninett.NO. 1d23h59m58s IN A 158.38.0.181 ;; Total query time: 4 msec ;; FROM: lookfar to SERVER: default -- 127.0.0.1 ;; WHEN: Sat Dec 16 00:23:09 2000 ;; MSG SIZE sent: 28 rcvd: 162 Come potete notare chiaramente questa volta è stato molto più veloce, 4 ms rispetto a più di mezzo secondo. La risposta era in cache. Con le risposte in cache c'è la possibilità che siano scadute, ma i server di origine possono controllare da quanto tempo quelle risposte stanno nella cache e se possono essere considerate valide, così c'è un'alta probabilità che la risposta ottenuta sia valida. 3.2. Risolutori Tutti i sistemi operativi che implementano lo standard C API hanno le chiamate gethostbyname e gethostbyaddr. Queste possono prelevare informazioni da diverse fonti. Le fonti da cui prelevare informazioni sono configurate in /etc/nsswitch.conf su Linux (e anche su altri Unix). Questo è un lungo file che specifica da quali file o database andare a prelevare diversi tipi di dati. Solitamente all'inizio è ricco di utili indicazioni che è bene leggere. Dopo di ché cercate la riga che comincia per "hosts:"; dovreste leggervi: ______________________________________________________________________ hosts: files dns ______________________________________________________________________ (Vi ricordate degli spazi iniziali, vero? Non ve lo ricorderò mai più.) Se non ci fosse la riga "hosts:", mettetela in una di quelle sopra. Essa significa che i programmi dovrebbero prima cercare nel file /etc/hosts, poi andare a chiedere al DNS in accordo con resolv.conf. 3.3. Congratulazioni Adesso sapete come impostare una versione con cache di named. Prendetevi una birra, del latte o qualunque cosa vi piaccia per celebrare l'evento. 4. Forwarding Nelle reti grosse, ben organizzate, di istituzioni accademiche o ISP (Internet Service Provider), scoprirete che a volte le persone che lavorano sulla rete mettono a punto una gerarchia di impiego dei server DNS, che aiuta ad alleggerire il carico sulla rete interna e sui server esterni. Non è facile capire se vi trovate dentro o fuori una rete. Comunque non è importante e usando il server DNS del vostro provider come "forwarder" farete in modo che le risposte alle vostre richieste siano più veloci e meno pesanti per la vostra rete. Questo si ottiene facendo in modo che il vostro name server inoltri le richieste al name server del vostro provider. Ogni volta che ciò accade è come se voi andaste a prelevare direttamente dall'ampia cache del name server del vostro provider, incrementando la velocità delle richieste e alleggerendo il carico sul vostro name server. Se usate un modem questa può essere una piccola vittoria. Tanto per fare un esempio assumeremo che il vostro provider di rete interna abbia due name server, con numeri IP 10.0.0.1 e 10.1.0.1, e che voglia farveli usare. In questo caso nel vostro file named.conf, all'interno della sezione d'apertura chiamata "options", inserite queste righe: ______________________________________________________________________ forward first; forwarders { 10.0.0.1; 10.1.0.1; }; ______________________________________________________________________ C'è anche un trucco carino per le macchine con collegamento telefonico che usano i forwarder, è descritto nella sezione ``Domande e Risposte''. Fate ripartire il vostro name server e testatelo con nslookup. Dovrebbe funzionare bene. 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: 5.5.1. 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. 5.5.2. 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. 6. Opzioni di sicurezza di base Di Jamie Norrish Impostare le opzioni di configurazione in modo da ridurre i possibili problemi. Ci sono pochi semplici passaggi che vi permetteranno di ridurre contemporaneamente problemi e carico sul vostro server. Il materiale qui presente non è molto più che un punto di partenza; se siete particolarmente interessati agli aspetti relativi alla sicurezza (e dovreste esserlo), consultate altre risorse in Internet (vedi ``l'ultimo capitolo''). Le seguenti direttive di configurazione appaiono in named.conf. Se una direttiva appare nella sezione options del file, si applica a tutte le zone elencate nel file. Se invece appare all'interno di una voce di zone, si applica solo a quella zona. Una voce di zone esclude automaticamente quella nella sezione options. 6.1. Restringere i trasferimenti di zona Per fare in modo che un vostro server secondario possa rispondere alle richieste sul vostro dominio, esso dovrà essere in grado di trasferire le informazioni di zona dal vostro server primario. Pochissimi altri devono poterlo fare. Quindi è necessario usare l'opzione allow- transfer per restringere solo agli autorizzati i trasferimenti di zona, assumiamo ad esempio che 192.168.1.4 sia l'indirizzo IP di ns.friend.bogus e aggiungete voi stessi questa opzione a solo scopo di debug: ______________________________________________________________________ zone "linux.bogus" { allow-transfer { 192.168.1.4; localhost; }; }; ______________________________________________________________________ Restringendo così i trasferimenti di zona vi assicurerete che agli esterni saranno disponibili solo le informazioni necessarie a identificare il vostro dominio e nulla di più; nessuno potrà avere ulteriori informazioni sulla vostra configurazione. 6.2. Proteggersi contro lo spoofing Prima di tutto, disabilitate le interrogazioni dai domini che non sono vostri, lasciando questa possibilità solo alle macchine della vostra rete locale. Questo non solo previene un uso malizioso del DNS server, ma riduce anche l'uso non necessario del vostro server. ______________________________________________________________________ options { allow-query { 192.168.196.0/24; localhost; }; }; zone "linux.bogus" { allow-query { any; }; }; zone "196.168.192.in-addr.arpa" { allow-query { any; }; }; ______________________________________________________________________ Inoltre, disabilitate le interrogazioni ricorsive, eccetto che dalle macchine locali. Questo riduce la possibilità di attacchi di "cache poisoning", con cui vengono inviati dati falsi al vostro server. ______________________________________________________________________ options { allow-recursion { 192.168.196.0/24; localhost; }; }; ______________________________________________________________________ 6.3. Far partire named con utente non-root Sarebbe una buona idea far partire named con un utente diverso da root, così un eventuale attacco riuscito potrebbe fare danni molto limitati. Prima dovrete creare un utente sotto cui far girare named, poi modificare tutti gli script che usate per farlo partire di conseguenza. Passate i nuovi nomi di utente e gruppo a named usando i flag -u e -g . Ad esempio, nella Debian GNU/Linux 2.2 modificherete lo script /etc/init.d/bind in modo da avere la seguente riga (quando l'utente named è stato creato): ______________________________________________________________________ start-stop-daemon --start --quiet --exec /usr/sbin/named -- -u named ______________________________________________________________________ La stessa cosa può essere fatta con Red Hat e altre distribuzioni. Dave Lugo ha descritto una configurazione sicura "dual chroot" che potreste trovare interessante, rende il vostro named ancora più sicuro. 7. Esempio di un vero dominio Dove si elencano alcuni veri file di zona Gli utenti mi hanno suggerito di includere un esempio reale di un dominio funzionante come tutorial. Utilizzo questo esempio col permesso concessomi da David Bullock di LAND-5. Questi file risalgono al 24 Settembre 1996, successivamente vennero da me modificati perché si adattassero alle restrizioni di bind 8 e perché comprendessero delle estensioni. Questo implica che quello che leggerete qui differisce un po' da quello che otterreste facendo un'interrogazione sul name server di LAND-5. 7.1. /etc/named.conf (o /var/named/named.conf) Qui troveremo le sezioni relative alle due zone inverse richieste: la rete 127.0.0, e la sottorete LAND-5 206.6.177. Poi c'è la riga relativa alla zona di forward per land-5, land-5.com. Si noti come i file siano stati sistemati nella directory chiamata zone anziché in pz come ho fatto in questo HOWTO. ______________________________________________________________________ // Boot file for LAND-5 name server options { directory "/var/named"; }; controls { inet 127.0.0.1 allow { localhost; } keys { rndc_key; }; }; key "rndc_key" { algorithm hmac-md5; secret "c3Ryb25nIGVub3VnaCBmb3IgYSBtYW4gYnV0IG1hZGUgZm9yIGEgd29tYW4K"; }; zone "." { type hint; file "root.hints"; }; zone "0.0.127.in-addr.arpa" { type master; file "zone/127.0.0"; }; zone "land-5.com" { type master; file "zone/land-5.com"; }; zone "177.6.206.in-addr.arpa" { type master; file "zone/206.6.177"; }; ______________________________________________________________________ Se aveste intenzione di usare queste righe nel vostro named.conf (ma solo per gioco) PER FAVORE mettete "notify no;" nelle sezioni relative alle due zone land-5 così da evitare incidenti. 7.2. /var/named/root.hints Tenete a mente che questo è un file dinamico, quello che trovate qui è sorpassato. È meglio che ve ne procuriate uno recente, con dig, come verrà presto spiegato. ______________________________________________________________________ ; <<>> DiG 8.1 <<>> @A.ROOT-SERVERS.NET. ; (1 server found) ;; res options: init recurs defnam dnsrch ;; got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 10 ;; flags: qr aa rd; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 13 ;; QUERY SECTION: ;; ., type = NS, class = IN ;; ANSWER SECTION: . 6D IN NS G.ROOT-SERVERS.NET. . 6D IN NS J.ROOT-SERVERS.NET. . 6D IN NS K.ROOT-SERVERS.NET. . 6D IN NS L.ROOT-SERVERS.NET. . 6D IN NS M.ROOT-SERVERS.NET. . 6D IN NS A.ROOT-SERVERS.NET. . 6D IN NS H.ROOT-SERVERS.NET. . 6D IN NS B.ROOT-SERVERS.NET. . 6D IN NS C.ROOT-SERVERS.NET. . 6D IN NS D.ROOT-SERVERS.NET. . 6D IN NS E.ROOT-SERVERS.NET. . 6D IN NS I.ROOT-SERVERS.NET. . 6D IN NS F.ROOT-SERVERS.NET. ;; ADDITIONAL SECTION: G.ROOT-SERVERS.NET. 5w6d16h IN A 192.112.36.4 J.ROOT-SERVERS.NET. 5w6d16h IN A 198.41.0.10 K.ROOT-SERVERS.NET. 5w6d16h IN A 193.0.14.129 L.ROOT-SERVERS.NET. 5w6d16h IN A 198.32.64.12 M.ROOT-SERVERS.NET. 5w6d16h IN A 202.12.27.33 A.ROOT-SERVERS.NET. 5w6d16h IN A 198.41.0.4 H.ROOT-SERVERS.NET. 5w6d16h IN A 128.63.2.53 B.ROOT-SERVERS.NET. 5w6d16h IN A 128.9.0.107 C.ROOT-SERVERS.NET. 5w6d16h IN A 192.33.4.12 D.ROOT-SERVERS.NET. 5w6d16h IN A 128.8.10.90 E.ROOT-SERVERS.NET. 5w6d16h IN A 192.203.230.10 I.ROOT-SERVERS.NET. 5w6d16h IN A 192.36.148.17 F.ROOT-SERVERS.NET. 5w6d16h IN A 192.5.5.241 ;; Total query time: 215 msec ;; FROM: roke.uio.no to SERVER: A.ROOT-SERVERS.NET. 198.41.0.4 ;; WHEN: Sun Feb 15 01:22:51 1998 ;; MSG SIZE sent: 17 rcvd: 436 ______________________________________________________________________ 7.3. /var/named/zone/127.0.0 Solo lo stretto necessario, il record obbligatorio SOA e un record che mette in corrispondenza 127.0.0.1 con localhost. Entrambi sono richiesti. Non deve esserci nient'altro in questo file. Probabilmente non ci sarà mai bisogno di aggiornare questo file, a meno che non cambino gli indirizzi del name server o del responsabile. ______________________________________________________________________ @ IN SOA land-5.com. root.land-5.com. ( 199609203 ; Serial 28800 ; Refresh 7200 ; Retry 604800 ; Expire 86400) ; Minimum TTL NS land-5.com. 1 PTR localhost. ______________________________________________________________________ Se date uno sguardo a diverse installazioni di BIND noterete che la riga $TTL è assente a volte, come in questo caso. Prima non veniva utilizzata, solo dalla versione 8.2 BIND ha iniziato ad emettere un avviso in caso di sua assenza. BIND 9 richiede la riga $TTL. 7.4. /var/named/zone/land-5.com Qui possiamo vedere il record obbligatorio SOA e i record NS richiesti. Si può vedere che è presente un name server secondario in ns2.psi.net. Questo è come dovrebbe essere, è bene avere sempre un server secondario fuori dalla vostra rete che faccia da backup. Si può notare anche la presenza di un host principale chiamato land-5 che si prende cura della maggior parte dei servizi Internet, questo è fatto tramite i record CNAME (alternativamente si possono usare i record A). Come si può vedere dal record SOA, il file di zona comincia con land-5.com, la persona da contattare è root@land-5.com. Anche hostmaster è spesso utilizzato per il responsabile di zona. Il numero di serie è nel formato standard aaaammgg con il numero di versione giornaliera a seguire, perciò si tratta forse della sesta versione del file di zona del 20 settembre 1996. Ricordate che il numero di serie deve essere incrementato in maniera monotonica, qui viene usata una sola cifra per il numero di versione giornaliera, così dopo 9 volte che si è modificato il file bisogna aspettare il giorno successivo prima di poterlo modificare di nuovo. Comunque considerate che si possono usare 2 cifre. ______________________________________________________________________ $TTL 3D @ IN SOA land-5.com. root.land-5.com. ( 199609206 ; serial, todays date + todays serial # 8H ; refresh, seconds 2H ; retry, seconds 1W ; expire, seconds 1D ) ; minimum, seconds NS land-5.com. NS ns2.psi.net. MX 10 land-5.com. ; Primary Mail Exchanger TXT "LAND-5 Corporation" localhost A 127.0.0.1 router A 206.6.177.1 land-5.com. A 206.6.177.2 ns A 206.6.177.3 www A 207.159.141.192 ftp CNAME land-5.com. mail CNAME land-5.com. news CNAME land-5.com. funn A 206.6.177.2 ; ; Workstations ; ws-177200 A 206.6.177.200 MX 10 land-5.com. ; Primary Mail Host ws-177201 A 206.6.177.201 MX 10 land-5.com. ; Primary Mail Host ws-177202 A 206.6.177.202 MX 10 land-5.com. ; Primary Mail Host ws-177203 A 206.6.177.203 MX 10 land-5.com. ; Primary Mail Host ws-177204 A 206.6.177.204 MX 10 land-5.com. ; Primary Mail Host ws-177205 A 206.6.177.205 MX 10 land-5.com. ; Primary Mail Host ; {Many repetitive definitions deleted - SNIP} ws-177250 A 206.6.177.250 MX 10 land-5.com. ; Primary Mail Host ws-177251 A 206.6.177.251 MX 10 land-5.com. ; Primary Mail Host ws-177252 A 206.6.177.252 MX 10 land-5.com. ; Primary Mail Host ws-177253 A 206.6.177.253 MX 10 land-5.com. ; Primary Mail Host ws-177254 A 206.6.177.254 MX 10 land-5.com. ; Primary Mail Host ______________________________________________________________________ Esaminando i name server di land-5 scoprirete che gli host hanno un nome del tipo ws_numero. Con le ultime versioni di bind-4 named ha iniziato a porre delle restrizioni sui caratteri che potevano essere usati nei nomi di host. In questo HOWTO io ho sostituito "-" (trattino) con "_" (trattino basso) in modo da uniformarmi alle regole di bind-8 per i nomi di host. Ma, come ho detto prima, BIND 9 non obbliga più a questa restrizione. Un'altra cosa da notare è che le workstation non hanno nomi individuali, ma un prefisso seguito dalle ultime due parti del numero IP. Usare delle convenzioni simili può semplificare significativamente la manutenzione, ma può risultare impersonale e in effetti potrebbe anche irritare i vostri clienti. Vediamo anche che funn.land-5.com è un alias per land-5.com, ma ciò è fatto tramite un record A, non con un record CNAME. 7.5. /var/named/zone/206.6.177 Commenterò questo file più sotto. ______________________________________________________________________ $TTL 3D @ IN SOA land-5.com. root.land-5.com. ( 199609206 ; Serial 28800 ; Refresh 7200 ; Retry 604800 ; Expire 86400) ; Minimum TTL NS land-5.com. NS ns2.psi.net. ; ; Servers ; 1 PTR router.land-5.com. 2 PTR land-5.com. 2 PTR funn.land-5.com. ; ; Workstations ; 200 PTR ws-177200.land-5.com. 201 PTR ws-177201.land-5.com. 202 PTR ws-177202.land-5.com. 203 PTR ws-177203.land-5.com. 204 PTR ws-177204.land-5.com. 205 PTR ws-177205.land-5.com. ; {Many repetitive definitions deleted - SNIP} 250 PTR ws-177250.land-5.com. 251 PTR ws-177251.land-5.com. 252 PTR ws-177252.land-5.com. 253 PTR ws-177253.land-5.com. 254 PTR ws-177254.land-5.com. ______________________________________________________________________ La zona inversa costituisce la fase della configurazione che causa più grane. Essa serve a ricavare il nome di un host dall'indirizzo IP di una macchina. Esempio: voi siete un server IRC e accettate connessioni dai client IRC. Inoltre siete un server IRC norvegese a volete che queste connessioni provengano da client norvegesi o da altre nazioni scandinave. Quando ricevete una richiesta di connessione da un client la libreria C è in grado di dirvi il numero IP della macchina che sta tentando la connessione, poiché il numero IP del client è contenuto in ogni pacchetto che attraversa la rete. A questo punto potrete chiamare una funzione chiamata gethostbyaddr che ricava il nome di un host a partire dal suo indirizzo IP. Gethostbyaddr interrogherà un server DNS, il quale attraverserà il DNS in cerca della macchina. Supponiamo che il client si connetta da ws-177200.land-5.com. La libreria C presente nel server ricava il numero IP del client che tenta la connessione, in questo caso è 206.6.177.200. Per scoprire il nome di questa macchina bisogna prima scoprire 200.177.6.206.in-addr.arpa. Il server DNS troverà prima i server arpa., poi troverà i server in- addr.arpa., seguendo il percorso inverso passando per 206, poi per 6 e alla fine troverà il server responsabile per la zona 177.6.206.in- addr.arpa presso LAND-5. Da questo finalmente si potrà ricavare che in 200.177.6.206.in-addr.arpa c'è un record "PTR ws-177200.land-5.com", questo significa che il nome associato a 206.6.177.200 è ws-177200.land-5.com. Il server FTP accetta connessioni solo da paesi scandinavi, ovvero *.no, *.se, *.dk il nome ws-177200.land-5.com non corrisponde a nessuno di questi ovviamente e il server metterà tale connessione in una classe di connessioni con meno banda e meno connessioni disponibili. Se non ci fosse la corrispondenza inversa di 206.2.177.200 tramite la zona in-addr.arpa il server sarebbe incapace di scoprire il nome e avrebbe dovuto comparare 206.2.177.200 con *.no, *.se e *.dk, senza trovare nessuna corrispondenza, esso può anche negare la connessione completamente per assenza di classificazione. Alcune persone vi diranno che la mappatura della risoluzione inversa è importante solo per i server, o per nulla importante. Non è così: molti server ftp, news, IRC e anche qualche server http (WEB) non accetteranno connessioni da macchine per le quali non riescono a trovare il nome. Quindi la mappatura inversa diventa di fatto obbligatoria. 8. Manutenzione Mantenerlo operativo C'è un altro compito di manutenzione che dovete fare sui named, oltre a quello di tenerli operativi. Consiste nel mantenere aggiornato il file root.hints. Il modo più semplice è usare dig, fate partire dig senza argomenti, otterrete root.hints in accordo col quello che c'è sul vostro server. Poi fate una richiesta a uno dei root server elencati con dig @rootserver. Vedrete che l'output somiglierà terribilmente al file root.hints. Salvatelo in un file (dig @e.root- servers.net . ns >root.hints.new) e rimpiazzate il vecchio root.hints con questo. Ricordate di rilanciare named dopo aver rimpiazzato il file cache. Questo script mi è stato mandato da Al Longyear, può essere fatto partire automaticamente per aggiornare root.hints, impostate una riga nel crontab che lo faccia partire una volta al mese e dimenticatelo. Lo script assume che il vostro sistema di posta funzioni e che l'alias di posta "hostmaster" sia definito. Dovrete modificarlo affinché si conformi alle vostre esigenze. ______________________________________________________________________ #!/bin/sh # # Update the nameserver cache information file once per month. # This is run automatically by a cron entry. # # Original by Al Longyear # Updated for BIND 8 by Nicolai Langfeldt # Miscelanious error-conditions reported by David A. Ranch # Ping test suggested by Martin Foster # named up-test suggested by Erik Bryer. # ( echo "To: hostmaster " echo "From: system " # Is named up? Check the status of named. case `rndc status 2>&1` in *refused*) echo "named is DOWN. root.hints was NOT updated" echo exit 0 ;; esac PATH=/sbin:/usr/sbin:/bin:/usr/bin: export PATH # NOTE: /var/named must be writable only by trusted users or this script # will cause root compromise/denial of service opportunities. cd /var/named 2>/dev/null || { echo "Subject: Cannot cd to /var/named, error $?" echo echo "The subject says it all" exit 1 } # Are we online? Ping a server at your ISP case `ping -qnc 1 some.machine.net 2>&1` in *'100% packet loss'*) echo "Subject: root.hints NOT updated. The network is DOWN." echo echo "The subject says it all" exit 1 ;; esac dig @e.root-servers.net . ns >root.hints.new 2> errors case `cat root.hints.new` in *NOERROR*) # It worked :;; *) echo "Subject: The root.hints file update has FAILED." echo echo "The root.hints update has failed" echo "This is the dig output reported:" echo cat root.hints.new errors exit 1 ;; esac echo "Subject: The root.hints file has been updated" echo echo "The root.hints file has been updated to contain the following information:" echo cat root.hints.new chown root.root root.hints.new chmod 444 root.hints.new rm -f root.hints.old errors mv root.hints root.hints.old mv root.hints.new root.hints rndc restart echo echo "The nameserver has been restarted to ensure that the update is complete." echo "The previous root.hints file is now called /var/named/root.hints.old." ) 2>&1 | /usr/lib/sendmail -t exit 0 ______________________________________________________________________ Qualcuno di voi potrebbe aver notato che il file root.hints è disponibile anche in ftp da Internic. Per favore, non usate ftp per aggiornare root.hints, il metodo sopra descritto è molto più amichevole verso la rete e Internic. 9. Migrare a BIND 9 La documentazione allegata ai pacchetti di BIND 9 e alla sua distribuzione contiene un documento chiamato migration che contiene note su come migrare da BIND 8 a BIND 9. Questo documento è davvero prioritario. Se avete installato i binari dai pacchetti esso si troverà in /usr/share/doc/bind* o /usr/doc/bind* qualcosa. Se invece state ancora usando BIND 4, troverete un documento chiamato migration-4to9 nello stesso posto. 10. Domande e risposte Per favore leggete questa sezione prima di scrivermi in email. 1. Il mio named vuole il file named.boot State leggendo l'HOWTO sbagliato. Leggete per favore la vecchia versione di questo HOWTO, che tratta bind 4, presso 2. Come si usa il DNS da dietro un firewall? Un indizio: forward only; probabilmente avrete bisogno anche della riga ___________________________________________________________________ query-source port 53; ___________________________________________________________________ all'interno della parte "options" del file named.conf come suggerito nella sezione-esempio ``caching'' 3. Come fare in modo che il DNS distribuisca un servizio attraverso gli indirizzi disponibili, tipo www.sito.occupato per ottenere un effetto di bilanciamento del carico, o simile?? Create numerosi record A per www.sito.occupato e usate bind 4.9.3 o successivo. Poi sarà bind a far ruotare le risposte. Non funziona con le precedenti versioni di BIND. 4. Voglio impostare il DNS su una intranet (chiusa). Cosa devo fare? Cancellerete il file root.hints e creerete solo i file di zona. Questo significa anche che non dovrete aggiornare i file di hint tutte le volte. 5. Come si imposta un name server secondario? Se il server primario ha indirizzo 127.0.0.1 mettete una riga come questa nel file named.conf del vostro secondario: ___________________________________________________________________ zone "linux.bogus" { type slave; file "sz/linux.bogus"; masters { 127.0.0.1; }; }; ___________________________________________________________________ Potrete elencare numerosi server primari alternativi, la zona può essere copiata dalla lista masters, separata da ';'. 6. Vorrei BIND in esecuzione quando mi disconnetto dalla rete. Ci sono quattro articoli che riguardano la questione: · Specifico per BIND 8/9, Adam L. Rice mi ha mandato questa email, su come far funzionare tranquillamente il DNS su una macchina con connessione telefonica: Ho scoperto che con le ultime versioni di BIND non è più necessario [ dove egli spiega come affronta il problema: Faccio partire named sulla mia macchina che fa servizio di masquerading. Ho due file root.hints, uno chiamato root.hints.real, che contiene i veri nomi dei root server, e l'altro chiamato root.hints.fake che contiene... ---- ; root.hints.fake ; this file contains no information ---- Quando mi sconnetto copio il file root.hints.fake su root.hints e faccio ripartire named. Quando mi connetto copio root.hints.real su root.hints e faccio ripartire named. Tutto ciò viene eseguito da ip-down e ip-up rispettivamente. La prima volta che faccio una interrogazione da sconnesso, named non avendo dettagli su di essa lascia una riga simile a questo messaggio... Jan 28 20:10:11 hazchem named[10147]: No root nameserver for class IN con la quale posso convivere. Questo per me funziona certamente. Posso usare il name server per le macchine locali quando sono sconnesso senza il ritardo del timeout per i nomi di dominio esterni e mentre sono collegato alla rete le interrogazioni per domini esterni funzionano normalmente. Perte Denison pensa che Ian non andrà molto lontanto. Egli scrive: Quando connesso) fornisce immediatamente tutte le voci presenti in cache e quelle relative alla rete locale per le voci non presenti in cache, fa il forward al name server del mio ISP. Quando sconnesso risponde alle interrogazioni relative alla rete locale nega tutte le altre **immediatamente** La combinazione di cambiare il cache file root e di inoltrare le richieste non funziona. Così, ho impostato (dopo un sacco di discussioni al LUG locale) due named come segue: named-online: inoltra al name server del mio provider primario per la zona locale primario per la zona locale inversa (1.168.192.in-addr.arpa) primario per 0.0.127.in-addr.arpa ascolta sulla porta 60053 named-offline: (niente forward) file cache root "falso" secondario per 3 zone locali (il primario è 127.0.0.1:60053) ascolta sulla porta 61053 Combinando tutto questo con il port-forwarding , cioè reindirizzando la porta 53 sulla 61053 quando sconnesso e sulla 60053 quando connesso. (Io uso il vecchio pacchetto netfilter con kernel 2.3.18, ma dovrebbe funzionare anche con il vecchio ipchains). Notate che questo potrebbe non funzionare al di fuori della mia macchina, poichè c'è un bug in BIND 8.2, che ho segnalato agli sviluppatori, che impedisce a un server secondario di avere come primario lo stesso IP (anche se su porte differenti). C'è una patch provvisoria che dovrebbe funzionare. Ho ricevuto anche informazioni su come bind interagisce con NFS e con il portmapper su una macchina che in genere rimane sconnessa da Karl-Max Wanger: Sono abituato a eseguire il mio named su tutte le mie macchine che solo occasionalmente sono connesse a Internet via modem. Solo il name server fa da cache, esso non ha un'area di autorità e chiede qualunque cosa ai name server del file root.cache. Come è prassi comune con Slackware, viene fatto partire prima di nfsd e mountd. Con una delle mie macchine (un notebook Libretto 30), avevo il problema che qualche volta avrei voluto fare il mount di essa da un altro sistema connesso alla mia rete locale, ma la maggior parte delle volte non funzionava. Avevo lo stesso effetto usando indistintamente PLIP, una scheda ethernet PCMCIA o il PPP su una interfaccia seriale. Dopo qualche supposizione ed esperimento scoprii che apparentemente named incasinava il processo di registrazione con portmapper che nfsd e mountd devono fare all'avvio (faccio partire questi demoni all'avvio come al solito). Eseguire named dopo nfsd e mountd elimina completamente questo problema. Anche se non ci sono svantaggi da attendersi da una sequenza di boot così modificata, vorrei consigliare a tutti di farla in questo modo per prevenire potenziali problemi. 7. Il caching name server memorizza la sua cache? C'è un modo per controllare la dimensione della cache? La cache è completamente immagazzinata in memoria, non verrà mai scritta sul disco in nessuna occasione. Ogni volta che si uccide named (con il comando "kill") la cache è persa. La cache non è controllabile in alcun modo. Named la gestisce in accordo a qualche semplice regola e basta. Non potete controllare la cache o la sua dimensione in nessun modo per nessuna ragione. Se questo non vi andasse bene potrete sempre cercare di modificare named andando ad agire sul suo codice sorgente. Non è comunque un'operazione raccomandabile. 8. Named salva la cache fra un riavvio e l'altro? Posso fare in modo che la salvi? No, named non salva la cache quando si ferma. Questo significa che la cache deve essere ricostituita ogni volta che fermate e fate ripartire named. Non c'è modo di salvare la cache in un file. Se questo non vi andasse bene potrete sempre cercare di modificare named andando ad agire sul codice sorgente. Non è comunque un'operazione raccomandabile. 9. Come si ottiene un dominio? Io vorrei impostare il mio dominio chiamato (ad esempio) linux-rules.net. Come posso avere il dominio che vorrei mi fosse assegnato? Contattate per favore il vostro provider. Loro sapranno aiutarvi in questo. Sappiate che in molte parti del mondo ci sarà bisogno di pagare per avere un dominio. 11. Come diventare un grande amministratore DNS Documentazione e strumenti Esiste della vera documentazione. Sia in Internet che su carta stampata. La lettura di buona parte di essa è necessaria per fare il passo dall'amministratore DNS a tempo perso a quello a tempo pieno. Io ho scritto The Concise Guide to DNS and BIND (di Nicolai Langfeldt, che sarei io), pubblicata da Que (ISBN 0-7897-2273-9). Il libro è molto simile a questo HOWTO, solo con maggiori dettagli e molto più di tutto.È stato tradotto in Polacco e pubblicato come DNS i BIND by Helion ( , ISBN 83-7197-446-9). Ora nella quarta edizione è DNS and BIND di Cricket Liu e P. Albitz da O'Reilly & Associates (ISBN 0-937175-82-X, affettuosamente noto come "il libro del Cricket"). Un'altro libro è Linux DNS Server Administration di Craig Hunt, pubblicato da Sybex (ISBN 0782127363), non l'ho ancora letto. Un altro must per la Buona Amministrazione DNS (e buono per qualsiasi altra cosa) è Zen and the Art of Motorcycle Maintenance di Robert M. Pirsig [in italiano Lo Zen e l'arte della manutenzione della motocicletta per Adelphi NdT]. In rete troverete il mio libro, insieme a tonnellate di altri libri, disponibili elettronicamente con sottoscrizione a pagamento presso . Troverete della roba presso (DNS Resources Directory), ; una FAQ, un manuale di riferimento (l'ARM dovrebbe essere incluso nella distribuzione di BIND) oltre che documenti, definizioni di protocolli e trucchi (hacks) sul DNS (di questi, la maggior parte, se non tutti, e alcune delle RFC elencate sotto, sono anche contenuti nella distribuzione di bind). Io non ho letto tutto. Il newsgroup si occupa anche delle problematiche del DNS. Inoltre come aggiunta a tutto questo ci sono numerose RFC sul DNS, le più importanti sono probabilmente quelle riportate sotto. Quelle contrassegnate con numeri BCP (Best Current Practice) sono altamente raccomandate. RFC 2671 P. Vixie, Extension Mechanisms for DNS (EDNS0) August 1999. RFC 2317 BCP 20, H. Eidnes et. al. Classless IN-ADDR.ARPA delegation, March 1998. This is about CIDR, or classless subnet reverse lookups. RFC 2308 M. Andrews, Negative Caching of DNS Queries, March 1998. About negative caching and the $TTL zone file directive. RFC 2219 BCP 17, M. Hamilton and R. Wright, Use of DNS Aliases for Network Services, October 1997. About CNAME usage. RFC 2182 BCP 16, R. Elz et. al., Selection and Operation of Secondary DNS Servers, July 1997. RFC 2052 A. Gulbrandsen, P. Vixie, A DNS RR for specifying the location of services (DNS SRV), October 1996 RFC 1918 Y. Rekhter, R. Moskowitz, D. Karrenberg, G. de Groot, E. Lear, Address Allocation for Private Internets, 02/29/1996. RFC 1912 D. Barr, Common DNS Operational and Configuration Errors, 02/28/1996. RFC 1912 Errors B. Barr Errors in RFC 1912. Only available at RFC 1713 A. Romao, Tools for DNS debugging, 11/03/1994. RFC 1712 C. Farrell, M. Schulze, S. Pleitner, D. Baldoni, DNS Encoding of Geographical Location, 11/01/1994. RFC 1183 R. Ullmann, P. Mockapetris, L. Mamakos, C. Everhart, New DNS RR Definitions, 10/08/1990. RFC 1035 P. Mockapetris, Domain names - implementation and specification, 11/01/1987. RFC 1034 P. Mockapetris, Domain names - concepts and facilities, 11/01/1987. RFC 1033 M. Lottor, Domain administrators operations guide, 11/01/1987. RFC 1032 M. Stahl, Domain administrators guide, 11/01/1987. RFC 974 C. Partridge, Mail routing and the domain system, 01/01/1986.