Name Server Operations Guide per BIND Release 4.9.3

Name Server Operations Guide per BIND Release 4.9.3 Release dalla 4.9 Paul Vixie 1 <paul@vix.com> Internet Software Consortium La Honda, CA Release fino alla 4.8.3 inclusa Kevin J. Dunlap 2 Michael J. Karels Computer Systems Research Group Computer Science Division Department of Electrical Engineering and Computer Sciences University of California Berkeley, CA 94720 Traduzione a cura di Leonardo Albrizio <albrizio@freemail.it> 1. Introduzione Il Berkeley Internet Name Domain (BIND) implementa un name server Internet per sistemi operativi derivati da BSD. BIND è composto da un server (o daemon ) chiamato named e da una libreria resolver. Unname server è un servizio di rete che consente ai client di dare un nome a risorse ed oggetti e a distribuire questa informazione con altri oggetti nella rete. Questo, in effetti, è un sistema distribuito di database per oggetti in una rete di computer. Il server BIND funziona in background, servendo le richieste su una porta di rete nota. In /etc/services sono specificate le porte standard per UDP e TCP. Il resolver è un insieme di routine residenti in una libreria di sistema, che fornisce l interfaccia che i programmi possono usare per accedere ai servizi di nome di dominio. 1 Durante lo sviluppo e il rilascio della release 4.9 di BIND, l autore è stato impiegato del Network Systems Laboratory della Digital Equipment Corporation. La release 4.9.2 è stata sponsorizzata da Vixie Enterprises. Le release dalla 4.9.3 sono state sponsorizzate dall Internet Software Consortium. 2 L autore era impiegato nel Engineering Advanced Development Group della Digital Equipment Corporation ULTRIX e, quando questo lavoro è stato portato a termine, egli è stato impiegato temporaneamente al CSRG. ULTRIX èmarchio registrato della Digital Equipment Corporation.

SMM:10-2 Name Server Operations Guide per BIND BIND è pienamente integrato nei programmi di rete BSD (release 4.3 e successive) per il deposito e il recupero dei nomi e dell indirizzo di host. L amministratore può configurare il sistema in modo da usare BIND in sostituzione della vecchia tabella per la ricerca di informazioni sugli host, contenuta nel file /etc/hosts degli host della rete. BIND è usato per la configurazione di default di BSD. 2. Il name service La funzione di base del name server è di fornire informazioni sugli oggetti di rete rispondendo alle richieste. Le specifiche di questo name server sono definite nelle RFC1034, RFC1035 e RFC974. Questi documenti possono essere reperiti in /usr/src/etc/named/doc in 4.3BSD o via ftp da ftp.rs.internic.net. É altresì raccomandato leggere le relative pagine del manuale di named (8), resolver (3) e resolver (5). Ai fini della risoluzione del nome di host, usare un server di nomi invece della tabella di ricerca per la risoluzione del nome di host evita il bisogno di un singolo servizio centralizzato per la traduzione di tutti i nomi. La delega dell autorità può essere conferita alle diverse organizzazioni che in rete sono responsabili per l informazione. Le routine di consultazione relative alla tabella di host richiedono che il principale file per l intera rete sia gestito in un luogo centrale da poche persone. Ciò è ideale per piccole reti dove ci sono solo poche macchine e le differenti organizzazioni responsabili collaborano tra loro, ma non è indicato nelle reti grandi dove le macchine incrociano confini organizzativi. Con il name server la rete può essere frazionata in una gerarchia di domini. Lo spazio del nome è organizzato ad albero, nel rispetto dei confini organizzativi e amministrativi. Ad ogni nodo, chiamato domain, è assegnata un etichetta e il nome del dominio è la concatenazione di tutte le etichette dei domini, dalla radice fino al dominio corrente, elencati da destra a sinistra e separati da punti. Occorre solo che un etichetta sia unica all interno del suo dominio. L intero spazio è ripartito in varie aree chiamate zone. Ogni zona parte da un dominio e si estende giù fino ai domini foglia o ai domini dai quali partono altre zone. Solitamente le zone rappresentano i confini amministrativi. Un esempio di indirizzo di host per un host della University of California di Berkeley appare come segue: monet. Berkeley. EDU Il dominio radice per oganizzazioni dell istruzione è EDU: Berkeley è un dominio sottostante di EDU e monet è il nome dell host. 3. Tipi di zone Una zona è un punto di delega nell albero del DNS. Essa contiene tutti i nomi da un certo punto in giù, ad eccezione di quelli che sono delegati ad altre zone. Un punto di delega hauno o più record NS nella zona da cui dipende che dovrebbe essere resa corrispondente alla radice della zona delegata adopera di record equivalenti NS (es.: il nome @ nel file di zona). Per avere una operatività appropriata per un name server, è di grande importanza capire la differenza tra una zona e un dominio. Come esempio, considerate il dominio DEC.COM, che include nomi quali POBOX1.PA.DEC.COM e QUABBIN.CRL.DEC.COM anche se la zona DEC.COM ha solo deleghe per le zone PA.DEC.COM e CRL.DEC.COM. Una zona può mappare esattamente un singolo dominio, ma può anche includere solo parte di un dominio (il resto del quale potrebbe essere delegato ad altri name server). Tecnicamente parlando ogni nome nell albero del DNS è un dominio, anche se terminale, infatti esso non ha sottodomini. Sempre parlando tecnicamente, ogni sottodominio è un domino ed ogni dominio è anche un sottodominio, ad eccezione di root. La terminologia non è intuitiva e per raggiungere una completa comprensione di questo argomento difficile e sottile è meglio leggere le RFC 1033, 1034 e 1035. Sebbene BIND sia un Domain Name Server, esso è da intendersi principalmente in termini di zona. Nel file named.boot, ledichiarazioni primary e secondary specificano zone, non domini. Quando

Name Server Operations Guide per BIND SMM:10-3 chiedete a qualcuno se desidera costituire il sever secondario per il vostro dominio, state chiedendo un servizio secondario per qualche collezione di zone. Ogni zona ha un server primario che carica i contenuti della zona da qualche file locale questo file è scritto da uomini o viene generato automaticamente da qualche altro file locale che, a sua volta, è scritto da uomini. Quindi vi è un numero di server secondari che caricano i contenuti della zona usando il protocollo IP/DNS (infatti i server secondari contattano quelli primari e recuperano la zona usando IP/TCP). Questo gruppo di server (il primario e tutti i secondari) dovrebbe essere elencato nei record NS nella zona ascendente, che costituirà una delega. Questo insieme di server deve anche essere elencato nel file di zona stesso, di solito con il nome @, carattere che significa top level o root della zona corrente. Potete elencare server nei record NS top-level @ di zona che non sono nella delega NS ascendete, ma non potete elencare i server nella delega di ascendente che non sono presenti nel @ di zona. Qualsiasi server elencato nei record NS deve essere configurato come authoritative (sia primario che secondario) per la zona. Quando si interpella un server elencato in un record NS, senon è authoritative, esso risponde con una delega incerta. 4. Tipi di server Non esistono realmente tipi di server. Un server può essere primario per alcune zone e secondario per altre, o esso può essere solo primario o solo secondario o può non servire zone e rispondere solo a richieste usando la sua cache. Precedenti versioni di questo documento si sono riferite a server come master e slave,maora noi abbiamo la sensazione che quelle distinzioni e l assegnazione di un tipo adunname server non sono utili. 4.1. Server asola cache Tutti i server sono caching server. Questo significa che il server immagazzina nella cache le informazioni che riceve per l uso finché i dati scadono. Un Server Caching Only è un server che non è autoritario per alcuna zona. I servizi di questo server interpellano e chiedono le informazioni necessarie ad altri server che ne hanno autorità. Tutti i server trattengono i dati nella loro cache fino aquando non scadono, ad opera del campo TTL ( Time To Live )che è mantenuto per tutti i record di risorsa. 4.2. Server remoto Un server remoto è una scelta data a chi gradirebbe usare un name server dalla propria workstation o su una macchina che ha quantità di memoria e di cicli CPU limitati. Con questa scelta potete far girare tutti i programmi di networking che usano il name server senza che esso impegni la macchina locale. Tutte le richieste sono fornite da un name server che è fatto girare su di un altra macchina nella rete. Un host che ha un file /etc/resolv.conf, che elenca solo host remoti e non fa girare un name server proprio, è chiamato a volte Server Remoto (perchè il server corrente è remoto?), ma più spesso esso è chiamato semplicemente Client DNS. Dal momento che non ha cache e non dà risposte alle richieste, questo genere di host non è tecnicamente un server. 4.3. Server slave Invece di interagire con i name server per root e altri domini, un Server Slave è un server che spedisce sempre, dalla sua cache ad una fissata lista di forwarding servers, le richieste che non può soddisfare. Le richieste dirette ai forwarding servers sono richieste ricorsive. Vi possono essere uno o più server di forwarding, che sono interrogati a turno fino ad esaurimento della lista. Quando non si vuole che tutti i server di un dato sito interagiscano con il resto dei server in Internet è tipicamente usata una configurazione Slave e forwarder. Uno scenario tipico potrebbe interessare un numero di workstation e una macchina dipartimentale time sharing con accesso ad Internet. Le workstation potrebbero essere amministrativamente interdette dall accesso a Internet. Per dare alle workstation l apparenza di accesso al sistema di dominio di Internet, le stesse workstation

SMM:10-4 Name Server Operations Guide per BIND potrebbero essere server Slave della macchina timesharing prima di restituire la risposta, questa invierebbe le richieste e interagirebbe con i name server per risolvere le richieste. Quale beneficio aggiunto nell uso della caratteristica di forwarding, la macchina centrale sviluppa una cache di informazioni molto più completa da cui tutte le workstation possono trarre vantaggio. L uso del modo Slave e forwarding è trattato ulteriormente sotto la descrizione dei comandi del file boot di named. Non è proibito dichiarare un server quale slave, anche se esso avesse zone primarie e/o secondarie l effetto è ancora che, nella cache del server locale o nelle zone, qualsiasi cosa è restituita e ciò che resta viene inoltrato usando la lista forwarders. 5. I File Il name server usa vari file per caricare il suo database. Questa sezione riguarda i file ed il loro formato occorrente per named. 5.1. Il File boot All attivazione di named questo file è letto per primo. Esso determina il tipo di server, su quale zona applica la sua autorità e dove reperire i suoi dati iniziali. La posizione di default per questo file è /etc /named.boot. Comunque, quando si compila named, questa può essere cambiata a mezzo della variabile BOOTFILE o, quando si avvia named, specificandola sulla riga dicomando. 5.1.1. Dominio Si può specificare un dominio di default scrivendo una riga del tipo: domain Berkeley. Edu Iname server più datati usano questa informazione quando essi ricevono una richiesta per un nome sconosciuto che non reca un. Più recenti configurazioni danno per assunto che la resolver library aggiunge la sua stessa idea di default domain a qualsiasi nome non qualificato. Sebbene il name server possa ancora essere compilato con il supporto per la direttiva domain nel file boot, per default esso viene tralasciato e noi raccomandiamo con insistenza di essere contrari al suo utilizzo. Se usate questa caratteristica, i client al di fuori del vostro dominio locale che vi inviano richieste riguardanti i nomi non qualificati, hanno la qualificazione implicita del vostro dominio anziché dei loro. La sede propria per questa funzione è nel file /etc/resolv.conf (o equivalente) del client. Scoraggiamo decisamente l uso della direttiva domain nel vostro file boot. 5.1.2. Directory La direttiva directory specifica la directory nella quale dovrebbe essere eseguito il name server, consentendo l uso dei nomi di percorso relativo agli altri nomi di file nel file boot. É permessa una sola direttiva directory, che dovrebbe essere riportata prima di qualsiasi altra direttiva che specifichi nomi di file directory /var/named Se avete più di un paio di file di named da gestire è preferibile collocarli in una directory quale /var/named e regolare il comando directory in modo appropriato. Gli usi principali di questo comando tendono a rendere certo che named sia nella giusta directory quando si tenti di includere file con nomi di percorso relativo con $INCLUDE e di consentire a named di essere eseguito in una locazione ragionevole quando esso deve generare il file core.

Name Server Operations Guide per BIND SMM:10-5 5.1.3. Primary service La riga che, nel file boot, designa il server quale primario per una zona è simile alla seguente: primary Berkeley. Edu ucbhosts Il primo campo specifica che si tratta di server primario per la zona riportata nel secondo campo. Il terzo campo è il nome del file dal quale vengono letti i dati. Quanto prima detto dà per assunto che la zona da specificare sia di classe IN. Se desiderate specificare una classe diversa potete accodare /class al primo campo, dove class èil valore intero o lo standard mnemonico per la classe. Ad esempio, la riga per definire un server primario per una zona di classe hesiod somiglia alla seguente primary/hs Berkeley. Edu hesiod.data Notate che questo supporto per specificare zone di classe diversa da IN è un opzione disponibile solo in fase di compilazione del vostro sistema operativo, che il vostro rivenditore può non aver abilitato durante la sua installazione. 5.1.4. Secondary service La riga per un server secondario è simile a quella per un server primario, tranne per il fatto che esso elenca indirizzi di altri server (generalmente server primari) dai quali si ottengono idati di zona. secondary Berkeley. Edu 128.32.0.10 128.32.0.4 ucbhosts.bak Il primo campo specifica che il server è secondario per la zona riportata nel secondo campo. I due indirizzi di rete specificano il nome dei server che contengono i dati per la zona. Notate che almeno uno di questi è primary e, a meno che non usiate un protocollo diverso da IP/DNS per il meccanismo di trasferimento della vostra zona, gli altri sono tutti altri server secondary. Sela connessione della vostra rete varia in modo scorretto ma solito, è normalmente poco saggio far sì che il proprio server secondario recuperi i dati da altri server secondari, visto che si può aggiungere ritardo alla propagazione dell aggiornamento della zona. L uso desiderato per indirizzi multipli su una dichiarazione di secondary avviene quando il server primary ha interfacce multiple di rete e quindi indirizzi di host multipli. Il server secondario ricava i suoi dati attraverso la rete da uno dei server elencati. Gli indirizzi di server sono provati nell ordine elencato. Se dopo la lista di server primari è presente un nome di file, i dati per la zona sono trasferiti in quel file come backup. Al primo avvio del server, sepossibile, i dati sono caricati dal file di backup e poi viene consultato un server primario per verificare che la zona sia ancora aggiornata. Notate che elencando il vostro server come server secondary non lo rende necessariamente tale deve essere la zona ascendente a delegare l autorità al vostro server, così come il primario e gli altri secondari, altrimenti vi trasferirete in una zona sovrastante senza alcuna ragione nessun altro server ha motivo di interrogarvi per quella zona, a meno che la zona ascendete non vi riporti come server per la zona. Per una classe diversa da IN, come per il primario, potete specificare un server secondario aggiungendo /class alla parola chiave secondary, es.: secondary/hs. 5.1.5. Stub service La riga per un server stub è simile a quella per un secondario (questa caratteristica è sperimentale nella 4.9.3). stub Berkeley. Edu 128.32.0.10 128.32.0.4 ucbhosts.bak Il primo campo specifica che si tratta di un server stub per la zona riportata nel secondo campo.

SMM:10-6 Name Server Operations Guide per BIND Le zone stub sono volute per assicurare che un primario per una zona abbia sempre i corretti record NS per gli eredi di quella zona. Se il primario non è secondario per la zona sottostante dovrebbe essere configurato con zone stub per tutti i suoi discendenti. Le zone stub forniscono un meccanismo per consentire di specificare solo in un luogo i record NS per una zona. primary CSIRO. AU csiro.dat stub dms.csiro. AU 130.155.16.1 dms.stub stub dap.csiro. AU 130.155.98.1 dap.stub 5.1.6. Inizializzazione della cache Per preparare la cache all utilizzo dei name server, tutti i server, inclusi i server caching only, dovrebbero avere una riga come la seguente nel file boot cache. root.cache Oltre all informazione del server root, non inserite altro nei vostri file di cache. Tutti i file cache elencati sono letti al momento del boot di named e ogni valore ancora valido viene ripristinato nella cache. L informazione del name server radice è usata fino a quando una richiesta di root non è contestualmente evasa da uno dei name server presenti nel file cache, quindi, al posto del file di cache, è usata la risposta alla richiesta di root fino a che la richiesta non scada. Come per primary e secondary, per una classe che non sia IN, potete specificare un server secondario accodando /class alla parola chiave cache. es.: class/hs. 5.1.7. Forwarders Qualsiasi server può far uso di forwarders. Un forwarder è un altro server, capace di elaborare richieste ricorrenti, che vuole tentare la risoluzione delle richieste per conto di altri sistemi il comando forwarders specifica che vengono spedite da un indirizzo Internet come segue forwarders 128.32.0.10 128.32.0.4 Sono due le ragioni per adottare questo metodo. Primo, alcuni sistemi possono non avere accesso pieno alla rete e può essere loro impedito di inviare qualsiasi pacchetto IP nella parte restante dell Internet e quindi devono dipendere da un forwarder che abbia accesso all intera rete. La seconda ragione è che il forwarder vede una unione di tutte le richieste come esse passano attraverso il suo server e perciò questo costruisce una cache di dati molto ricca, se comparata alla cache di un name server di una tipica workstation. In effetti, il forwarder diventa una meta-cache di cui tutti gli host possono beneficiare, riducendo così il numero totale di richieste da quel sito al resto della rete. L effetto di forwarders è quello di anteporre alcuni indirizzi stabiliti alla lista dei server da provare per ogni richiesta. Quella lista, normalmente, è fatta solo di server ad alta autorità scoperti a mezzo di consultazioni del record NS per il dominio relativo. Se i forwarders non rispondono, si interrogano direttamente i server appropriati per i domini, a meno che non sia stata data la direttiva slave. 5.1.8. Server slave Il modo slave è usato se l impiego di forwarders è l unica via possibile per risolvere richieste dovute alla perdita dell accesso pieno alla rete o se si vuole prevenire l utilizzo da parte del name server di forwarder diversi da quelli elencati. Il modo slave è attivato inserendo il

Name Server Operations Guide per BIND SMM:10-7 semplice comando options forward-only nel file boot. Se viene usata questa opzione, dovete specificare forwarders. Quando è in modo slave, il server inoltra ciascuna richiesta ad ogni forwarder fino a che non venga reperita una risposta o sia esaurita la lista dei forwarders. Così, mentre forwarders, per ogni richiesta, antepone gli indirizzi alla server list, options forward-only fa sì che server list contenga solo gli indirizzi elencati nella dichiarazione forwarders. Poiché potreste finire per spedire richieste solo ad alcuni insiemi di host che sono anche slave e una o più di esse potrebbero essere richieste di forwarding dirette al vostro indirizzo, un uso inaccurato della direttiva options forward-only può effetivamente causare loop di forwarding realmente tremendi. Si dovrebbe considerare molto attentamente l uso della direttiva options forward-only. Notate che questo stesso comportamento può essere ottenuto usando la sconsigliata direttiva slave. 5.1.9. Server non ricorsivo La separazione che BIND fa tra dati authoritative (zone) e nonauthoritative (cache) è sempre stata in qualche modo debole e l inquinamento dei primi attraverso i secondi è cosa nota. Un modo per prevenire ciò e per salvare memoria sui server che trasportano una grande quantità di dati autoritari (es.: root servers) è di rendere tali server nonrecursive. Ciò può essere ottenuto attraverso la direttiva options no-recursion nel file di boot. Un server che ha questa opzione abilitata, per favorire la risposta alle richieste, non tenta di recuperare dati se richiedete dati che esso non ha, vi rimanda ad un server più autoritario o, se è questo stesso autoritario per la zona della richiesta, vi invia una risposta negativa. Un server non ricorsivo può essere riportato in un RR NS ma esso non può essere elencato nel file resolv.conf. 5.1.10. Registrazione delle richieste Se il file system contenente il vostro file syslog ha abbastanza spazio, potete considerare di usare la direttiva options query-log nel vostro bootfile. Ciò porta il name server a generare una registrazione per ogni richiesta da esso ricevuta che, quando combinata con uno script Perl o AWK per processare a posteriori i log, può essere un utile strumento manageriale. 5.1.11. Pseudo-supporto di richieste inverse Per default, BIND non supporta richieste inverse e ciò è risaputo essere all origine di problemi per certi sistemi operativi di microcomputer e per vecchie versioni del tool nslookup di BIND. Inv ece di rispondere con operation not implemented, potete decidere che named rilevi le richieste inverse più comuni e fornisca loro una risposta con finte informazioni. É meglio aggiornare i vostri client perché smettano di dipendere dalle richieste inverse, ma, se ciò non fosse possibile, dovreste usare la direttiva options fake-iquery nel vostro file di boot.

SMM:10-8 Name Server Operations Guide per BIND NOTA: in effetti le risposte sono finte, esse contengono parentesi quadre ISO8859 ([ e ]), così i vostri client non sono in grado di farci alcunché di utile con queste risposte. É stato osservato che nessun client ha mai fatto qualcosa di utile con le risposte a richieste inverse reali. 5.1.12. Impostazione limiti del name server Alcune operazioni di name server possono impiegare risorse in modo intensivo e, per accordare appropriatamente il vostro sistema, è a volte necessario cambiare le quote interne di BIND. Si può ottenere ciò attraverso la direttiva limit <name> <value> nel file di boot. I limiti e i loro valori di default sono i seguenti: limit transfers-in 10 Questo è il numero di processi simultanei di named-xfer che BIND èingrado di eseguire. Se il vostro server secondario ha centinaia o migliaia di zone da gestire, numeri maggiori di processi portano a una convergenza più veloce verso server primari e, impostando questo parametro ad un numero troppo alto, può causare generazione di testo poco chiaro, in seguito a mancanza di risorse quali ampiezza di banda o spazio di swap. NOTA: questo limite può anche essere espresso attraverso la direttiva sconsigliata max-fetch NN. limit transfers-per-ns 2 Questo è il numero di processi simultanei di named-xfer che BIND è in grado di iniziare per qualsiasi name server dato. Nella maggior parte dei casi non c è bisogno di cambiarlo. Se il vostro server secondario riceve centinaia o migliaia di zone da un singolo server principale, aumentando il valore di transfers-per-ns si può velocizzare la convergenza. Per evitare di causare la generazione di dati inutili e l impoverimento di risorse sul server principale, esso deve essere tenuto il più basso possibile. limit datasize <system-dependent> La maggior parte dei sistemi ha una quota che limita le dimensioni del cosiddetto data segment, che è il luogo dove BIND riceve tutta la sua autorità e i dati di cache. Se BIND va oltre la quota stessa non si comporta in modo ottimale (forse persino smettendo di funzionare). Se il vostro sistema supporta una chiamata di sistema per modificare questa quota per un dato processo, potete chiedere a BIND l uso di quella chiamata di sistema attraverso la direttiva limit datasize NN. Ilvalore qui dato può essere scalato posponendo k per 1024X, m per (1024ˆ2)X e g per (1024ˆ3)X. Nel 1995, i server root usano tutti limit datasize 64m. 5.1.13. Restrizioni al trasferimento di zone Può ricorrere il caso che la vostra organizzazione non voglia dare liste complete dei propri host a chiunque possa raggiungere i vostri name server sull Internet. Mentre è ancora possibile per la gente, guardando nei record PTR, iterare attraverso il range di indirizzi e costruire gradualmente una lista dei vostri host, è ancora considerato ragionevole restringere il vostro export di zone attraverso il protocollo di trasferimento di zona. Per limitare la lista dei vicini che possono trasferire zone dal vostro server, usate la direttiva xfrnets. Questa direttiva ha la stessa sintassi di forwarders tranne che qui potete elencare i numeri di rete in aggiunta agli indirizzi di host. Ad esempio, se volete permettere il trasferimento di zone dal vostro server solo agli host su un network numero 16 in classe A, dovreste aggiungere la direttiva xfrnets 16.0.0.0 Ciò non è capillare a sufficienza e future versioni di BIND permetteranno un tale controllo

Name Server Operations Guide per BIND SMM:10-9 dell accesso da specificarsi in base agli host e non in base alla rete com è attualmente. Notate che, anche se gli indirizzi senza una maschera esplicita sono assunti da questa direttiva come network, potete sempre specificare una maschera analitica quanto desiderate, forse con l inclusione di tutti i bit dell indirizzo in modo che un solo host riceva il permesso di trasferimento. Ad esempio si consideri xfrnets 16.1.0.2&255.255.255.255 che potrebbe permettere al solo host 16.1.0.2 il trasferimento di zone dal vostro sistema. Notate che non sono consentiti spazi attorno al carattere &,che introduce una netmask. Per compatibilità con la release 4.9 di BIND, la direttiva xfrnets può anche essere data come tcplist. 5.1.14. Ordinamento degli indirizzi Se per un name server che BIND vuole contattare sono disponibili indirizzi multipli, BIND prova prima quello che egli crede più vicino. La vicinanza è stabilita in termini di similarità di indirizzo infatti, se un indirizzo è sulla stessa sottorete come alcune interfacce dell host locale, allora viene prima provato quell indirizzo. Se ciò fallisse, sarebbe provato per primo un indirizzo che si trova sulla stessa rete. Se ciò fallisse, essi sarebbero provati in un ordine più o meno casuale, finché non sia stata data la direttiva sortlist nel file named.boot. La sintassi di sortlist èsimile a quella di forwarders, xfrnets e bogusns voi date una lista di reti dotted-quad e esso la usa per preferire alcuni server remoti anziché altri. Se non è prevista una maschera esplicita con ogni elemento di una sortlist, ne viene dedotta una in base all indirizzo dei bit di ordine alto. Se vi trovate su una rete di Classe C che ha una rete di Classe B tra voi e il resto di lnternet, potreste tentare di migliorare la fortuna del name server nel recupero di risposte con l elencazione del numero di network di Classe B in una direttiva sortlist. Questo dovrebbe avere l effetto di tentare con server più vicini prima di quelli più distanti. Notate che questo comportamento è nuovo in BIND 4.9. L altro e più vecchio effetto della direttiva sortlist è quello di indurre BIND ad ordinare i record A in qualsiasi risposta egli generi, in modo da porre sulla sortlist quelli che appaiono per primi. Ciò non è molto di aiuto come si potrebbe credere, poiché molti client riordinano i record A ocasualmente o usando LIFO siconsideri anche il fatto che il server non è in grado di indovinare la tipologia di rete del client e quindi non è in grado di ordinare accuratamente i record per vicinanza a tutti i possibili client. Ottenere l ordinamento nel resolver è chiaramente meglio. Nella pratica corrente, questa direttiva è usata solo raramente perché essa materializza informazioni che cambiano rapidamente una rete che oggi è vicina il prossimo mese potrebbe essere distante. Poiché BIND costruisce una cache dei tempi di risposta del name server remoto, esso converge velocemente su un comportamento ragionevole, che non è come dire ottimale, ma ci va abbastanza vicino. Orientamenti futuri per BIND includono la scelta di indirizzi basati su interfaccia metrica locale (su host che ne hanno più di una) e forse su informazioni di tabelle di routing. Noi non intendiamo risolvere il problema generalizzato del multihomed host, ma potremmo essere in grado di rendere le cose migliori di adesso. Nella stessa misura, speriamo di vedere una resolver library di livello più alto che ordini le risposte usando l informazione topologica che esiste solo sull host del client. 5.1.15. Name server falsi Occasionalmente accade che alcuni server remoti vanno male. Potete dire al vostro name server di rifiutarsi di ascoltare o porre domande ad alcuni altri name server elencandoli in una

SMM:10-10 Name Server Operations Guide per BIND direttiva bogusns nel vostro file named.boot. La sua sintassi è la stessa di forwarders, xfrnets e sortlist dategli una lista di indirizzi Internet nella forma dotted-quad. Si noti che le zone delegate a tali server non sono raggiungibili dai client dei vostri server quindi dovreste usare questa direttiva con parsimonia o non usarla affatto. 5.1.16. Segmentazione dei boot file Se il vostro server è secondario per svariate zone, potreste trovare conveniente dividere il vostro file named.boot in una parte statica che non cambia mai consistentemente (potrebbero essere qui incluse direttive come directory, sortlist, xfrnets e cache) ed una parte dinamica che cambia frequentemente (tutte le direttive primary potrebbero andare in un file e tutte le direttive secondary in un altro e uno o entrambi potrebbero essere recuperati automaticamente da qualche vicino in modo che esso possa cambiare la vostra lista della zona secondaria senza la necessità di un vostro intervento attivo). Potete realizzare ciò per mezzo della direttiva include, che accetta un solo nome di file quale suo argomento per l indicazione del nome del file non sono richiesti apici. Il nome del file è valutato dopo che il name server cambia la sua directory di lavoro in quella specificata nella direttiva directory, inmodo che, se il vostro sistema li supporta, potete usare nomi di percorso relativo. 5.2. Configurazione del resolver Il nome del file di configurazione è /etc/resolv.conf. Questo file designa i name server della rete che dovrebbero ricevere le richieste. Se non può trovare il suo file di configurazione, il resolver tenta di contattare un name server su localhost. Dovreste in ogni caso installare il file di configurazione su ogni host, poiché questo è il solo modo raccomandato per specificare un livello di sistema di dominio di default e voi potete ancora elencarvi l indirizzo dell host locale se esso sta eseguendo un name server. Siconsidera ragionevole creare questo file anche se gestite un server locale, poiché, quando il client fa lasua prima chiamata ad una routine di resolver, ilsuo contenuto viene riportato in cache da ogni client della resolver library. Il file resolv.conf contiene una direttiva per riga nelle seguenti forme: commento #commento domain local-domain search search-list nameserver server-address sortlist sort-list options option-list Si dovrebbero dare singole direttive domain o search esattamente una sola volta. Se è data la direttiva search, il primo elemento nella search-list annulla qualsiasi local-domain specificato in precedenza. La direttiva nameserver può essere data fino a tre volte. Le direttive nameserver addizionali sono ignorate. I commenti possono essere inclusi iniziando una riga con o #. Notate che i commenti non erano consentiti in versioni del resolver precedenti a quella inclusa in BIND 4.9 così, se il resolver del vostro rivenditore supporta i commenti, sapete che è un resolver aggiornato. local-domain è accodato a qualsiasi query-name che non contenga un.. local-domain può essere scavalcato sulla base di processo impostando la variabile d ambiente LOCALDOMAIN. Notate che l elaborazione di local-domain può essere disabilitata con la impostazione di una scelta nel resolver. search-list è una lista di domini che sono provati, in ordine, come domini qualificanti per i query-names che non contengono.. Notate che l elaborazione di search-list può essere disabilitata impostando una scelta nel resolver. Notate altresì che la variabile d ambiente

Name Server Operations Guide per BIND SMM:10-11 LOCALDOMAIN può annullare questa search-list sulla base del processo. I server-address sono associati e quindi usati come destinazione di default di richieste generate attraverso il resolver. In altri termini, questo è il modo con cui voi dite al resolver quali name server esso dovrebbe usare. É possibile che una data applicazione client annulli questa lista e ciò è spesso realizzato all interno del name server (che è esso stesso un client resolver) e in programmi di test quali nslookup. Notate che se desiderate elencare il local host nel vostro file di configurazione del resolver, dovreste probabilmente usare il suo indirizzo Internet principale anziché un alias di local-host quale 127.0.0.1 o 0.0.0.0. Ciò è dovuto ad un bug nella manipolazione dei socket collegati di SOCK_DGRAM in alcune versioni del codice di networking BSD. Se dovete usare un address-alias, dovreste preferire 0.0.0.0 (o semplicemente 0 ) al posto di 127.0.0.1, in ogni caso state attenti che, secondo la datazione del vostro codice di networking derivato da BSD, ambedue sono in grado di fallire da soli. Se l implementazione dell IP del vostro host non crea un instradamento a cortocircuito fra l interfaccia di default e l interfaccia di loopback, per ottenerla, potreste anche voler aggiungere un instradamento statico (es.: in /etc/rc.local) come il seguente: route add myhost.domain.name localhost 1 sort-list è una lista di coppie indirizzi-ip/netmask. Gli indirizzi restituiti da gethostbyname sono ordinati come specificato da questa lista. Qualsiasi indirizzo non rispondente alla coppia indirizzo/netmask è restituito dopo quelli rispondenti. La netmask è opzionale e, se non specificato, èusata la netmask naturale. option-list è una lista di scelte ognuna delle quali annulla alcune variabili del resolver interno. Le scelte supportate a tuttora sono: debug imposta il bit RES_DEBUG in _res.options. ndots:n imposta il limite minimo (misurato in numero di punti ) dei nomi forniti a res_query() in modo che i nomi che hanno un numero maggiore di punti vengono provati come nomi assoluti prima che sia fatta qualsiasi elaborazione di local-domain o search-list. Il valore predefinito di questa variabile interna è 1. 5.3. File di inizializazione di cache 5.3.1. root.cache Il name server ha bisogno di conoscere i server che sono name server authoritative per il dominio radice della rete. Per far ciò, noi dobbiamo preparare la cache del server di nomi con gli indirizzi di queste autorità più alte. Nel file boot è specificata la posizione di questo file. Questo file usa il formato standard di Resource Record (Standard Resource Record Format - conosciuto anche come Masterfile Format), ulteriormente trattato in questo scritto. 5.4. File dati di dominio Per specificare i dati per un dominio vi sono due file standard. Questi sono hosts e host.rev. Questi file usano lo Standard Resource Record Format, trattato in seguito in questo scritto. Notate che i nomi dei file sono arbitrari molti amministratori di rete preferiscono dare un nome ai loro file zona dopo i domini che essi contengono, specialmente nella media dei casi dove un dato server è primario e/o secondario per molte e diverse zone.

SMM:10-12 Name Server Operations Guide per BIND 5.4.1. hosts Questo file contiene tutti i dati riguardanti le macchine di questa zona. La directory di questo file è specificata nel file boot. 5.4.2. hosts.rev Questo file specifica il dominio IN-ADDR.ARPA che è un dominio speciale per consentire la conversione da indirizzo a nome. Poiché gli indirizzi di host Internet non cadono nei confini di dominio, per consentire la traduzione inversa degli indirizzi, è stato formato questo dominio speciale. Precedono il dominio IN-ADDR.ARPA quattro etichette, che corrispondono ai quattro octet di un indirizzo Internet. Tutti e quattro gli octet devono essere specificati anche se un octet è zero. L indirizzo Internet 128.32.0.4 è situato nel dominio 4. 0. 32. 128. IN-ADDR. ARPA. Questo capovolgimento dell indirizzo è scomodo da leggersi, ma consente il naturale raggruppamento di host in una rete. 5.4.3. named.local Questo file specifica il record PTR per l interfaccia del loopback locale, meglio conosciuto come localhost, il cui indirizzo di rete è 127.0.0.1. La directory di appatenenza di questo file è specificata nel file boot. Al fine di un appropriata operazione di tutti i name server, è di importanza vitale che l indirizzo 127.0.0.1 abbia un record PTR che punti indietro al nome localhost.. Il nome di questo record PTR è sempre 1.0.0.127.IN-ADDR.ARPA. Ciò è necessario se volete che i vostri utenti siano in grado di usare hostname-authentication (hosts.equiv o /.rhosts) sul nome localhost.come suggerito da questo record PTR, dovrebbe esserci un record localhost.my.dom.ain A (con indirizzo 127.0.0.1) in ogni dominio contenente gli host. localhost. perde il punto in coda quando è richiesto 1.0.0.127.inaddr.arpa allora, le scelte di resolver DEFNAMES e/o DNSRCH provocano la valutazione di localhost quale nome di host nel dominio locale, il che significa che i domini top (o idealmente qualsiasi dominio), nel path di ricerca del vostro resolver, farebbero meglio ad avere qualcosa corrispondente a quel nome. 5.5. Standard Resource Record Format Irecord del file di dati del name server sono chiamati resource records. Lo Standard Resource Record Format (RR) è specificato in RFC-1035. La seguente è una descrizione generale di questi record: {name} {ttl} addr-class Record Type Record Specific data Irecord di Risorsa hanno il formato standard sopra indicato. Il primo campo è sempre il nome del record del dominio e deve essere sempre riportato a partire dalla prima colonna. In un file, per tutti i RR oltre al primo, il nome può essere lasciato in bianco in tal caso ad esso viene attribuito il nome del RR precedente. Il secondo campo è un campo opzionale di durata questo indica quanto tempo questi dati permarranno nel database. Tralasciando questo dato, resta valido il time to live di default che è indicato nel record di risorsa Start Of Authority (vedere appresso). Il terzo campo riporta la classe di indirizzo attualmente è supportata solo la classe per indirizzi Internet e altre informazioni Internet IN. Per la classe HS è incluso un supporto limitato, che è per l informazione MIT/Athena Hesiod. Il quarto campo indica il tipo di resolver record. I campi dopo questo sono dipendenti dal tipo di RR. Quando i dati sono caricati nel name server, nei campi di nomi e dati, sono rispettati i caratteri maiuscoli e minuscoli. Tutte le comparazioni e le ricerche portate nei database del name server non sono sensibili al tipo di carattere (maiuscolo/minuscolo).

Name Server Operations Guide per BIND SMM:10-13 Icaratteri seguenti hanno significati speciali:. Nel campo del nome, un punto a sè stante si riferisce al dominio root. @ Nel campo del nome, un @ a sè stante denota l origine corrente. \X Dove X è qualsiasi carattere ad eccezione dei numeri (0-9), evidenzia quel carattere in modo che il suo significato speciale non sia applicato. Ad esempio \. può essere usato per inserire un punto in una etichetta. \DDD Dove ogni D è un numero, è l octet corrispondente al numero decimale descritto da DDD. L octet risultante è assunto essere di test e non è verificato per uno speciale significato. () Leparentesi sono usate per raggruppare dati che impiegano più di una riga. In effetti, i fine riga non sono riconosciuti all interno delle parentesi (al momento, questa notazione è attiva solo per gli SOA del RR e non è facoltativa). Con punto e virgola inizia un commento: il resto della riga è ignorato. Notate che una riga completamente bianca denota ugualmente un commento e viene ignorata. * Un asterisco indica un metacarattere. Notate che questo è esattamente un altro dato-carattere il cui significato speciale cambia solo durante le operazioni di ricerca interne del name server. I wildcard sono significativi solo per alcuni tipi di RR (notoriamente MX) e quindi solo nel campo del nome non nei campi dei dati. Ovunque compare un nome nel campo nomi o in alcuni campi di dati definiti per contenere nomi se il nome non termina in un.,viene aggiunta l origine attuale. Questo è utile per aggiungere il nome del dominio corrente ai dati, come i nomi di macchine, ma può causare problemi laddove non li desiderate. Se il nome non si trova nel dominio per il quale state creando il file dati, è una buona regola empirica terminare il nome con un.. 5.5.1. $INCLUDE Una riga include comincia dalla prima colonna con $INCLUDE che è seguito da un nome file e, a scelta, da un nuovo temporaneo $ORIGIN da usarsi durante la lettura di questo file. Questa possibilità è particolarmente utile per separare tipi differenti di dati in molteplici file. Un esempio potrebbe essere: $INCLUDE /usr/local/adm/named/data/mail-exchanges Si può interpretare la riga quale richiesta per caricare il file /usr/local/adm/named/data/mailexchanges. Il comando $INCLUDE non provoca il caricamento dei dati in zona o albero differenti. Questo è semplicemente un modo per permettere di organizzare i dati in file distinti per una data zona primaria. La caratteristica temporary $ORIGIN suddetta non è sempre sufficiente per far intraprendere ai dati una nuova attività in qualche altra zona i confini della zona possono essere introdotti solo nel file di boot. Un file $INCLUDE deve avere un nome sul suo primo RR. Infatti il primo carattere di una riga non di commento non deve essere uno spazio. Il nome corrente predefinito nel file padre non conduce al file $INCLUDE. 5.5.2. $ORIGIN $ORIGIN è un mezzo per cambiare l origine in un file dati. La riga inizia in colonna 1 ed èseguita dall origine di un dominio. Ciò sembra come se esso potesse essere utile per mettere più di una zona in un file dati, ma non è così. Fondamentalmente il name server richiede che una data zona sia trascritta su qualche file specifico. Dovreste quindi essere molto accurati nell usare $ORIGIN solo una volta all inizio di un file o, all interno di un file, passando ad un

SMM:10-14 Name Server Operations Guide per BIND dominio più basso nella zona mai completamente a qualche altra zona. 5.5.3. SOA -Start Of Authority name {ttl} addr-class SOA Origin Person in charge @ IN SOA ucbvax.berkeley.edu. kjd.ucbvax.berkeley.edu. ( 1995122103 Serial 10800 Refresh 1800 Retry 3600000 Expire 259200 ) Minimum Il record Start of Authority, SOA, designa l inizio della zona. Il nome della zona è indicato da name ed è spesso dato come @ poiché questo è sempre la $Origin corrente e il RR SOA è abitualmente il primo record del file della zona primaria. Origin è il nome dell host sul quale risiede questo file dati (in altre parole, il server primary master per questa zona). Person in charge è l indirizzo e-mail della persona responsabile del name server, con @ sostituito da un.. Serial number è il numero di versione di questo file dati e deve essere un intero positivo. Questo numero deve essere aumentato ogni qualvolta si apporta una modifica ai dati. I server più vecchi permettevano l uso di un. fantasma in questo e in altri numeri in un file zona il significato di n.m era n000m al posto del più intuitivo n*1000+m (tanto che 1.234 era tradotto 1000234 e non 1234). Data la sua complicatezza, imprevedibilità e assenza di necessità, questa caratteristica è stata disapprovata. Notate che usando una notazione YYYYMMDDNN potete ancora apportare 100 variazioni al giorno fino all anno 4294. Dovreste scegliere una notazione che vada bene per voi. Se siete programmatori esperti in perl, per sostenere la generazione dei numeri seriali per la vostra zona, potreste anche usare i numeri versione RCS. Refresh indica la frequenza, in secondi, con cui i name server secondari scambiano verifiche con il name server primario per vedere se occorre un aggiornamento. Retry indica il tempo, in secondi, che un server secondario dovrebbe attendere prima di ritentare un traferimento fallito di una zona. Expire è il tempo massimo, in secondi, che un name server secondario ha a disposizione per l uso dei dati, prima che il tempo stesso scada per mancato aggiornamento. Minimum è il numero minimo di secondi, predefinito, da usarsi per il campo Time To Live su resource records che non ne indichino uno nel file zona se questo è specificato su qualche resource record (RR) nella zona, esso è anche un minimo forzato di Time To Live. Per ogni zona vi può essere esattamente un record SOA. 5.5.4. NS -Name Server {name} {ttl} addr-class NS Name servers name IN NS ucbarpa. Berkeley. Edu. Il record Name Server, NS, elenca un name server responsabile di un dato dominio, creando un punto di delega euna sotto zona. Ilcampo del primo nome indica la zona che è servita dal name server specificato dal secondo nome. Ogni zona dovrebbe avere almeno due name servers.

Name Server Operations Guide per BIND SMM:10-15 5.5.5. A -Address {name} {ttl} addr-class A address ucbarpa IN A 128.32.0.4 IN A 10.0.0.78 Il record Address, A, elenca l indirizzo per una data macchina. Il campo name indica il nome della macchina e address è l indirizzo di rete. Vi può essere un record A per ogni indirizzo della macchina. 5.5.6. HINFO -Informazione di host {name} {ttl} addr-class HINFO Hardware OS IN HINFO VAX-11/780 UNIX Il resource record Host Information, HINFO, contiene i dati specifici di host, specificando l hardware e il sistema operativo dell host elencato. Se si vuole inserire uno spazio nel nome della macchina, si deve comprendere il nome tra doppio apice (usando il carattere " ). Per ogni host dovrebbe esserci un record HINFO, sebbene, per ragioni di sicurezza, la maggior parte dei domini non hanno affatto il record HINFO. Nessuna applicazione dipende da questo record. 5.5.7. WKS -Servizi ben noti {name} {ttl} addr-class WKS address protocol list of services IN WKS 128.32.0.10 UDP who route timed domain IN WKS 128.32.0.10 TCP (echo telnet discard sunrpc sftp uucp-path systat daytime netstat qotd nntp link chargen ftp auth time whois mtp pop rje finger smtp supdup hostnames domain nameserver ) Il record Well Known Services, WKS, descrive i servizi ben noti supportati da un particolare protocollo di un indirizzo specifico. La lista di servizi e numeri di porta provengono dalla lista di servizi specificati in /etc/services. Dovrebbe esserci solo un record WKS per protocollo e per indirizzo. A proposito dei record WKS, larfc1123 cita: 2.2 Uso del Domain Name Service... Poiché il tipo di RR WKS non è spesso usato dai siti Internet, un applicazione NON DOVREBBE dipendere dall abilità di localizzare, ad un particolare indirizzo di host, un record WKS che contiene un accurata lista di tutti i servizi. Per aver conferma che un servizio esiste, provate semplicemente ad usarlo.... 5.2.12 Uso di WKS nella elaborazione di MX: RFC-974, p. 5 La RFC-974 [SMTP:3] ha raccomandato che, per verificare che ogni obiettivo di posta proposto supporti SMTP, sia interrogato il sistema di dominio per i record WKS

SMM:10-16 Name Server Operations Guide per BIND ("Well-Known Service"). Più recenti esperienze hanno dimostrato che WKS non èlargamente supportato, così SI DOVREBBE IGNORARE il passo riguardante WKS utilizzato nell elaborazione di MX.... 6.1.3.6 Stato dei RR Types... Itipi di RR TXT e WKS non sono stati largamente usati dai siti Internet quale risultato un applicazione non può ora contare sull esistenza, nella maggioranza dei domini, di RR come TXT e WKS 5.5.8. CNAME - Canonical Name alias {ttl} addr-class CNAME Canonical name ucbmonet IN CNAME monet Il record di risorsa Canonical Name, CNAME, indica un alias o un nickname per il nome di host ufficiale o canonical. Questo dovrebbe essere il solo record associato al nome alias. Tutti gli altri record di risorsa dovrebbero essere associati al nome canonical, non al nickname. Qualsiasi record di risorsa che include un nome di dominio come suo valore (es.: NS or MX) deve riportare un nome canonical, non il nickname similmente, quando si cercano RR di tipo A, ma non di tipo MX o NS o la maggior parte dei tipi di RR, si segue un CNAME. É consentito che i CNAME puntino ad altri CNAME, ma ciò è considerato disordinato. Inickname sono anche utili quando un host ben noto cambia il suo nome. In quel caso è solitamente una buona idea avere un record CNAME così chi usa ancora il vecchio nome approda nel giusto luogo. 5.5.9. PTR -Puntatore alnome di dominio name {ttl} addr-class PTR real name 7.0 IN PTR monet. Berkeley. Edu. Un record Domain Name Pointer, PTR, consente a nomi speciali di puntare altrove nel dominio. Per impostare i puntatori inversi per il dominio speciale IN-ADDR. ARPA si usa il precedente esempio di un record PTR. Questa riga ètratta da file di esempio hosts.rev. Irecord PTR sono richiesti dalla funzione gethostbyaddr. Notate il. in coda che impedisce a BIND di aggiungere a quel nome di dominio la $ORIGIN corrente. 5.5.10. MX -Mail exchange name {ttl} addr-class MX preference value mail exchange Munnari. OZ. AU. IN MX 0 Seismo. CSS. GOV. *. IL. IN MX 0 RELAY. CS. NET. I record Mail exchange, MX, sono usati per specificare una lista di host configurati per ricevere la posta inviata a questo nome di dominio. Ogni nome che riceve posta dovrebbe avere un MX, poiché, se non se ne trova uno al momento dell invio della posta, viene immesso un MX con costi nulli e con destinazione l host stesso. Se volete che un host riceva la propria posta, dovreste creare un MX per il vostro nome di host, che punti al vostro nome di host. É meglio che questo sia esplicitato che lasciare sia immesso dai servizi remoti. Nel primo esempio sopra riportato Seismo. CSS. GOV. è un gateway di posta che sa come spedire la posta a

Name Server Operations Guide per BIND SMM:10-17 Munnari. OZ. AU.. Queste due macchine possono avere una connessione privata o usare un mezzo di trasporto differente. Il valore da preferire è l ordine che il servizio di posta deve seguire quando vi è più di una via per inviare posta ad una macchina singola. Notate che un numero più basso indica una precedenza più alta che si suppone i mailer rendano casuale gli host MX paritetici e distribuiscano equamente il carico se i costi sono uguali. Per maggiori dettagli consultate l RFC974 Per l instradamento di posta con i record MX, si possono usare nomi che comprendono il meta-carattere *. Probabilmente in rete esistono server che stabiliscono semplicemente che qualsiasi posta diretta a un dominio deve essere instradata attraverso un relay. Nel secondo esempio riportato sopra, tutta la posta diretta agli host del dominio IL è instradata attraverso RELAY.CS.NET. Questo si ottiene creando un record di risorsa metacarattere, che stabilisce che *.ll ha un MX di RELAY.CS.NET. I record wildcard MX non sono in pratica molto utili, sebbene, da quando un messaggio di posta raggiunge un gateway per un dato dominio, esso deve essere ancora instradato all interno di quel dominio e non è correntemente possibile che esso abbia un appparentemente diverso insieme di record MX all interno e al di fuori di un dominio. Se non desiderate Mail Exchange alcuno all interno del vostro dominio, andate avanti e usate un wildecard. Notate che se volete usare sia il top-level wildcard che gli specifici record MX interni, ogni specifico record deve terminare con una completa esposizione degli stessi dati, che sono trasportati nel record top-level ciò perché gli specifici record MX hanno la precedenza sui record wildcard top-level. Se un dato dominio interno deve essere in grado di ricevere posta dall esterno del gateway, esso deve poter dare performance ai top-level. I record wildcard MX sono molto subdoli e dovreste essere accorti nel trattarli. 5.5.11. TXT -Testo name {ttl} addr-class TXT string Munnari. OZ. AU. IN TXT "foo" Un record TXT contiene dati testuali in forma libera. La sintassi del testo dipende dal dominio di appartenenza molti sistemi usano i record TXT per codificare i dati locali in un formato stilizzato. Uno di tali sistemi è l Hesiod del MIT. 5.5.12. RP -Persona Responsabile owner {ttl} addr-class RP mbox-domain-name TXT-domain-name franklin IN RP ben.franklin.berkeley.edu. sysadmins.berkeley.edu. Il record Responsible Person, RP, identifica il nome della persona responsabile di un host o il nome del suo gruppo. Spesso si desidera essere in grado di identificare il responsabile di un host particolare. Quando l host non funziona o funziona male, potreste voler contattare le persone che possono ripararlo. Il primo campo, mbox-domain-name, è un nome di dominio che specifica la mailbox per la persona responsabile. In un file zona, il formato di questo campo usa la convenzione DNS per la codifica delle mailbox identica a quella usata per il campo mailbox Person-in-charge nel record SOA. Nel precedente esempio, mbox-domain-name evidenzia la codifica per <ben@franklin.berkeley.edu>.per indicare che non è disponibile nessuna mailbox si può specificare il nome di dominio di root (esattamente. ). Il secondo campo, TXT-domain-name, è un nome di dominio per il quale esistono i record TXT. Per recuperare i record di risorsa TXT associati a TXT-domain-name, si può ottimizzare una richiesta successiva. Ciò fornisce un level of indirection (n.d.t.: numero di passi, nella ricerca su tabella, richiesti per produrre un indirizzo) sì che, da più parti nel DNS, si può far

SMM:10-18 Name Server Operations Guide per BIND riferimento a questa entità. Per indicare che non esiste un RR TXT associato, per il nome di dominio TXT-domain-name, può essere specificato il nome di dominio di root (esattamente. ). Nell esempio precedente sysadmins.berkeley.edu. è il nome di un record TXT che potrebbe contenere qualche testo con nomi e numeri di telefono. Il formato del record RP è insensibile alla classe. In un database, per un singolo nome, possono essere presenti record RP multipli, sebbene essi dovrebbero avere TTL identici. Il record RP è ancora sperimentale non tutti i name server lo implementano o riconoscono. 5.5.13. AFSDB -DCE o server AFS name {ttl} addr-class AFSDB subtype server host name toaster.com. IN AFSDB 1 jack.toaster.com. toaster.com. IN AFSDB 1 jill.toaster.com. toaster.com. IN AFSDB 2 tracker.toaster.com. I record AFSDB sono usati per specificare gli host che forniscono uno stile di servizio distribuito, dichiarato sotto questo nome di dominio. Un valore di sottotipo (analogo al valore preference nel record MX) indica quale stile di servizio distribuito è fornito con il dato nome. Il sottotipo 1 indica che il nome di host è un server database AFS (R) per la cella AFS del dato nome di dominio. Il sottotipo 2 indica che l host menzionato fornisce il name server di intra-cell per la cella DCE (R) nominata dal nome di dominio dato. Nell esempio sopra riportato, jack. toaster. com e jill. toaster. com sono stati dichiarati come server di database per la cella AFS toaster. com, in modo che i client che chiedono il servizio da parte di toaster. com sono indirizzati a quei due host per ulteriori informazioni. Il terzo record dichiara che tracker. toaster. com ospita una directory del server per il root della cella DCE toaster. com, in modo che i client DCE, che preferiscono riferirsi ai servizi DCE, dovrebbero consultarsi con l host tracker. toaster. com per ulteriori informazioni. Per altre informazioni che specificano ulteriori dettagli da usarsi nell accesso alla cella DCE, il sottotipo di record DCE è accompagnato di solito da un record TXT. Nella RFC1183 si trovano informazioni più dettagliate sull uso di questo tipo di record. Il record AFSDB è ancora sperimentale non tutti i name server lo implementano o lo riconoscono. 5.5.14. PX -Puntatore all informazione di mappatura X.400/RFC822 name {ttl} addr-class PX prefer 822-dom X.400-dom *.ADMD-garr.X42D.it. IN PX 50 it. ADMD-garr.C-it. *.infn.it. IN PX 50 infn.it. O.PRMD-infn.ADMD-garr.C-it. *.it. IN PX 50 it. O-gate.PRMD-garr.ADMD-garr.C-it. I record PX (Puntatore all informazione mapping X.4OO/RFC822) sono usati per specificare le regole del mapping di indirizzo fra gli indirizzi X.400 O/R e gli indirizzi di posta stile RFC-822 (domain-style). Preghiamo di riferirsi alla RFC-1327 per una descrizione dettagliata del processo di mapping. Le regole per il mapping sono di tre tipi diversi: 1) mappatura da X.400 a RFC822 (definita in RFC1327 come "table 1 rules") 2) mappatura da RFC822 a X.400 (definita in RFC1327 come "table 2 rules") 3) codifica di RFC822 dentro X.400 (definita in RFC1327 come "gate table")

Name Server Operations Guide per BIND SMM:10-19 Tutti e tre i tipi di regole di mapping sono specificati usando i Resource Records PX in DNS, sebbene il valore di name sia diverso: per il caso 1 il valore di name èundominio X.400 in sintassi DNS, per i casi 2 e 3 il valore di name è un dominio RFC-822. Per dettagli sulle specifiche del dominio X.400 in sintassi DNS e per l uso della parola chiave X42D in esso contenuta riferitevi alla richiesta RFC-1664. Esistono dei tool per la conversione dal formato di tabella RFC1327 nella sintassi di file DNS. Preference è analogo al parametro Preference del RR MX: è correntemente consigliato attribuire ad esso sempre un valore fisso di 50. 822-dom fornisce la parte di RFC-822 per la regola di mapping e X.400-dom dà la parte di X.400 della regola di mapping (in sintassi DNS). Visto che le tavole di specifiche RFC-1327 permettono solo specificazioni espresse con wildcard, è sempre attuale il consiglio di usare wildcard per esprimere i valori di name. Ciò per conservare compatibilità con i servizi esistenti usando tabelle statiche RFC1327 anziché informazioni PX di DNS. Le specifiche delle regole di mapping dalla sintassi X.400 a quella RFC822 richiede la creazione nel DNS di un albero di dominio X.400 appropriato, includendo quindi record SOA e NS, specifici per il dominio in sè. Le specifiche delle regole di mapping da RFC822 in X.400 possono essere inserite direttamente nell albero diretto e normale di name. Ancora, per dettagli sull organizzazione di questa struttura, riferitevi alla RFC-1664. Per recuperare dal DNS le appropriate regole di mapping nella sintassi RFC-1327 o nella sintassi DNS, sono disponibili i tool e le routine di libreria basati su quelli standard di resolver. Ancora una volta, riferitevi alla RFC-1664 per l uso dei record di risorsa PX e ponete attenzione nel coordinare le informazioni di mapping che potete specificare nel DNS con la stessa informazione specificata nelle tabelle statiche RFC-1327. Il record PX èancora sperimentale non tutti i server lo implementano o lo riconoscono. 5.6. Trattazione del TTL Il Time To Live assegnato ai record e alla zona per mezzo del campo Minimum nel record SOA èmolto importante. Valori alti portano ad abbassare il traffico di rete di BIND e a tempi di risposta più veloci valori più bassi tendono a generare svariate richieste ma consentono una più veloce propagazione dei cambiamenti. I TTL influenzano solo cambiamenti nelle zone e cancellazioni da queste zone. Le aggiunte si propagano in sintonia con il valore Refresh nel SOA. L esperienza ha dimostrato che, per le loro zone, i siti usano valori di default di TTL che variano da circa 0.5 a circa 7 giorni. Potreste voler considerare di aumentare il TTL di default riportato nella vecchia versione di questa guida da un giorno (86400 secondi) a tre giorni (259200 secondi). Ciò riduce drasticamente il numero di richieste fatte al vostro name server. Se avete bisogno di una veloce propagazione di cambi e cancellazioni, potrebbe essere saggio ridurre il campo Minimum pochi giorni prima del cambio, quindi apportate la modifica stessa e aumentate il TTL al suo vecchio valore. Se sapete che la vostra zona è abbastanza stabile (aggiungete principalmente nuovi record senza cancellare o cambiare i vecchi), potreste anche considerare un TTL più alto di tre giorni. Notate che in ogni caso non ha senso avere record con un TTL sotto il ritardo di Refresh di SOA, in quanto Delay è il tempo richiesto dai secondari per ottenere una copia della zona recentemente modificata. 5.7. Le zone sicure Le zone sicure implementano detta sicurezza con il criterio di zona per zona. Essa è disegnata per usare una lista di permessi di rete o di host che possono ottenere particolari

SMM:10-20 Name Server Operations Guide per BIND informazioni provenienti dalla zona. Per usare la sicurezza di zona, named deve essere compilato con la definizione SECURE_ZONES e voi dovete avere almeno un RR TXT di secure_zone. Nessuna restrizione viene applicata ai dati in quella zona fino a che, per una data zona, esiste il record secure_zone. Il formato per il RR TXT di secure_zone è: secure_zone addr-class TXT string L addr-class può essere sia HS che IN. La sintassi per la stringa TXT è sia network address:netmask che host IP address:h. La network address:netmask accetta richieste da un network intero. Se, per l indirizzo di network specificato, la netmask è omessa, named usa la netmask predefinita. host IP address:h consente l inoltro delle richieste da un host. Per differenziare l indirizzo di host dall indirizzo di network è richiesta la H dopo i due punti :. Nello stesso file zona sono consentiti RR TXT di secure_zone multipli. Ad esempio, aggiungendo le seguenti due RR TXT, potete impostare una zona perché risponda solo alle richieste Hesiod dalla rete con netmask di classe B 130.215.0.0 e dall host 128.23.10.56: secure_zone HS TXT 130.215.0.0:255.255.0.0 secure_zone HS TXT 128.23.10.56:H Questa caratteristica può essere usata per limitare l accesso a una mappa di password Hesiod o per separare, su una macchina firewall, la risoluzione degli indirizzi interni da quelli esterni ad internet senza aver bisogno di eseguire un named separato per la risoluzione interna ed esterna di indirizzi. Notate che avrete bisogno di includere la vostra interfaccia di loopback (127.0.0.1) nel vostro record secure_zone o i vostri client non saranno in grado di risolvere i nomi. 5.8. Hesiod erecord di risorse HS-class Hesiod, sviluppato dal Project Athena del MIT, èun servizio informazioni che opera su BIND. Il suo intento è simile a quello del NIS della Sun: fornire informazioni su user, gruppi, file system accessibili dalla rete, capacità delle stampanti e servizio di posta attraverso una installazione. A parte l uso che Hesiod fa dibind anzichè del codice di un server separato, un altra importante differenza tra Hesiod e NIS è che Hesiod non è fatto per essere in sintonia con password e autenticazioni, ma solo con dati che non sono sensibili alla sicurezza. I server Hesiod possono essere implementati aggiungendo record di risorse ai server BIND o essi possono essere implementati come separati server, amministrati a parte. Per ottenere e apprendere Hesiod, stabilite una connessione FTP anonymous con l host ATHENA-DIST.MIT.EDU efate il download del file tar compresso /pub/athena/hesiod.tar.z. Non avrete bisogno delle librerie di named e resolver, parti della distribuzione, perché la loro funzionalità è stata già integrata in BIND dalla 4.9. Per imparare come funziona Hesiod come parte dell ambiente di calcolo di Athena, scaricate lo scritto /pub/athena/usenix/athena-changes.ps dal server FTP del predetto host. Esiste anche un archivio tar del file di esempio di risorse Hesiod. Poiché gli stessi servizi possono probabilmente essere forniti con i record di classe IN, tipo TXT e tipo CNAME, rimane aperta la discussione sull uso della classe Hesiod. In un caso o nell altro, il codice e i documenti su Hesiod suggeriscono come impostare e usare il servizio. Notate che mentre BIND include il supporto per le richieste di classe HS, la logica di trasferimento di zona, per zone non di classe IN, èancora sperimentale.