INDICE dns & bind

Transcript

1 INDICE INTRODUZIONE ARCHITETTURA E PRINCIPI DI FUNZIONAMENTO DEL DNS DOMINI IL DNS DI INTERNET IL CONCETTO DI DELEGA NAME SERVER E ZONE DELEGA DEI SOTTODOMINI TIPI DI NAME SERVER ZONE DATA FILE RESOLVER RESOLUTION Root name server Scelta tra name server autoritativi e concetto di round trip time Mappatura da indirizzi a nomi Caching TTL (Time To Live) CREAZIONE ED IMPLEMENTAZIONE DI UN DOMINIO REGISTRY, REGISTRAR E REGISTRAZIONE LA REGISTRATION AUTORITÀ ITALIANA CONFIGURAZIONE DEL BIND DEFINIZIONE DI UNA ZONA Configurazione del TTL della zona Record SOA Record NS Address e alias Record PTR L'esempio completo Il file dei root name server Il file di configurazione del bind ABBREVIAZIONI Nomi e domini La Ripetizione dei nomi Esempio con abbreviazione CONFIGURAZIONE DEGLI HOST ALL INTERNO DI UN DOMINIO LA DIRETTIVA DOMAIN LA DIRETTIVA SEARCH LA DIRETTIVA NAMESERVER DEFINIZIONE DI UN NAME SERVER SLAVE IL RECORD SOA MASTER SERVER MULTIPLI ZONE MULTIPLE GESTIONE DEI SOTTODOMINI E DELEGHE CREAZIONE E GESTIONE DI SOTTODOMINI SENZA DELEGA CREAZIONE E GESTIONE DI SOTTODOMINI CON DELEGA Definizione di uno slave per un sottodominio dns & bind

2 Delega sul name server primario Definizione di uno slave server per il dominio principale DELEGA DI UN DOMINIO IN-ADDR.ARPA Subnetting su ottetti Subnetting su SVLM o non-ottetti IL DNS E LA POSTA ELETTRONICA GESTIONE DEL BIND ORGANIZZAZIONE E GESTIONE DEI FILE DI ZONA Le direttive $ORIGIN e $INCLUDE Le direttive TXT, RP e HINFO IL LOGGING DEL BIND CARATTERISTICHE AVANZATE DEL BIND ROUND ROBIN LOAD DISTRIBUTION FORWARDERS dns & bind

3 Introduzione È noto che i computer presenti in una rete, per poter comunicare tra loro devono potersi riconoscere. Deve quindi esistere un identificativo univoco che ne permetta la distinzione. Nel mondo TCP/IP sappiamo che questo riconoscimento avviene tramite l'utilizzo degli IP addresses. Tuttavia, sebbene le macchine tra loro utilizzano gli indirizzi IP per comunicare, questo sistema risulta scomodo per l'utilizzo umano. Infatti sarebbe necessario ricordarsi tutti gli indirizzi delle macchine che si vogliono contattare. Per questo motivo, ad ogni macchina viene associato un nome, normalmente costituito da campi di stringhe separate da un punto. Resta a chi definisce questi nomi, il buonsenso di inventare delle stringhe che abbiano un significato e che in qualche modo individuino eventuali servizi che il computer offre. Nei casi più semplici abbiamo smtp.dominio.it, dns.dominio.it, ecc. Ogni nome viene associato ad indirizzo IP. Nella realtà pratica dei fatti, quando ad esempio un utente digita nel proprio browser un nome di un sito web, avviene un immediata traduzione del nome nel corrispettivo indirizzo IP, ed è quest ultimo che viene utilizzato per indirizzare i pacchetti, tramite meccanismi di routing, al sito che si vuole visitare. Dunque i nomi vengo solo usati dall uomo nella prima fase di connessione ad un computer, ma non vengono utilizzati da quest ultimi per stabilire la comunicazione. È necessario definire quindi un sistema di associazione tra indirizzi e nomi dei computer all interno di una rete. Nel caso di Internet, è stato addirittura necessario definire un sistema siffatto, ma che funzioni su scala mondiale, permettendo univocità di indirizzi e nomi, ed immediata reperibilità dei nuovi indirizzi e nomi appena definiti. Questo sistema prende il nome di Domain Name System (DNS). Negli anni 60, la rete ARPAnet progenitore dell attuale Internet, era costituita da un numero esiguo di host. Per questo motivo non era difficile definire un sistema di identificazione che permettesse agli host di riconoscersi tra loro tramite nomi. Ogni macchina aveva un file, contenente l'associazione tra indirizzo e nome di se stessa e delle altra macchine presenti su ARPAnet. Dunque, ogni qualvolta veniva introdotta una nuova macchina oppure ne veniva modificato il nome oppure l'indirizzo, tutti file presenti su tutte le macchine dovevano essere aggiornati tramite l utilizzo di un semplice editor di file testo. Ancora oggi, questo file è presente o definibile in tutte le macchine Unix e Windows. In particolare il file è /etc/hosts per i sistemi Unix e %SYSTEMROOT%/HOSTS.TXT (intendendo con %SYSTEMROOT% la directory del sistema che cambia da versione a versione di Windows). Più precisamente Windows prevede anche l'utilizzo del file LMHOSTS.TXT ma non discuteremo in questa sede l'utilizzo di HOSTS.TXT e LMHOSTS.TXT. L'utilizzo del file hosts, in ambienti di LAN con un piccolo numero di macchine può ancora avere senso. Naturalmente, con l'avvento di Internet, l'aggiornamento di un file per ogni singolo cambiamento non può essere proponibile. Per questo motivo è stato introdotto l'utilizzo del DNS. Tra i software più diffusi per definire un sistema DNS, c è il BIND (Berkeley Internet Name Domain), attualmente disponibile per tutte le piattaforme Unix e Windows dns & bind

4 Architettura e principi di funzionamento del DNS In modo estremamente semplificato, il DNS non è altro che un database distribuito. Il database DNS distribuito è indicizzato da nomi di dominio. Un nome di dominio è essenzialmente un percorso all interno di un enorme albero, chiamato spazio dei nomi di dominio, noto in gergo inglese come domain name space. Nella figura seguente viene rappresentato il domain name space: Figura 1 Il DNS prevede la radice di partenza dell albero che in gergo viene chiamata root. Il numero di livelli massimo (o livelli di profondità) è 127. In nomi sono separati da un punto (dot) ed ogni nome può avere al massimo 63 caratteri. La successioni di nomi separati da un punto individuano un percorso all interno dell albero. Il nome con lunghezza nulla (zero caratteri è riservato al root.). La sequenza di nomi va letta da sinistra verso destra ed individua il nome a livello più basso (sinistra) fino al root (destra). Un punto finale alla fine di un nome completo, indica il root. Ad esempio termina con un punto finale ed indica quindi che oltre al punto non c è altro, in quanto questo rappresenta il root. Se il punto non è indicato, (ad esempio non si esclude la possibilità che sia solo una parte del nome e che possa esserci un altro nome a seguire, fino al root. In altre parole è un nome relativo. Un nome con il punto finale è detto Fully Qualified Domain Name o più brevemente FQDN od ancora nome assoluto. Un FQDN non ammette ambiguità di nome per sua stessa natura mentre un nome relativo non garantisce ciò, infatti potrebbero esserci due nomi relativi uguali all interno di un DNS. Tuttavia due nomi relativi anche se uguali, sicuramente hanno a livello più elevato necessariamente delle differenze di percorso all interno dell albero DNS. In figura viene rappresentata l'impossibilità di avere ambiguità di nome: dns & bind

5 Figura 2 Come si può notare, due nomi uguali non possono coesistere. Il tentativo di introdurre due nomi hobbes.pa.ca.us è impossibile. Tuttavia è possibile ad esempio introdurre un hobbes.pa.ca.us ed un hobbes.lg.ca.us Sebbene dunque, ca.us sia due, il cammino che li precede è diverso per cui è possibile che tali nomi coesistano. Domini Un dominio è semplicemente un sottoalbero o ramo del domain name space. Il nome di un dominio coincide con il nome del nodo al livello più alto del dominio stesso. Vediamo un esempio in figura: Figura 3 Il nome del dominio purdue.edu è uguale al nodo a livello più elevato all interno del dominio stesso. Ogni dominio all interno del sottoalbero è considerato una parte del dominio ed è detto anche sottodominio. Vediamo in figura un esempio: dns & bind

6 Figura 4 In figura, il dominio pa.ca.us è un sottodominio di ca.us che a sua volta è un sottodominio di us a sua volta sottodominio di. Ovvero del dominio root. Non necessariamente un dominio deve avere dei sottodomini. In alcuni casi, un nome che appare come sottodominio non è tale ma coincide con il nome di un host. Quindi un nodo può essere un sottodominio oppure può coincidere con un nome di host. In tal caso ovviamente non può avere sottodomini. Il DNS di Internet Come già anticipato nei paragrafi precedenti, i nomi possono essere scelti a piacere. Tuttavia, relativamente ad Internet, il primo livello ha dei nomi preesistenti. Questi livelli sono detti in gergo top-level e sono dedicati a particolari organizzazioni. I nomi più noti sono: com: organizzazioni commerciali come le aziende e le industrie edu: organizzazioni relative all educazione come ad esempio le università gov: organizzazioni governative come governo di uno stato, NASA, National Science Foundation mil: organizzazioni militari net: organizzazioni che gestiscono e forniscono infrastrutture di rete come NFSNET, UUNET. Ultimamente essa è anche utilizzata dalle organizzazione commerciali in analogia al livello com. org: organizzazioni non commerciali come IEEF, organizzazioni di volontariato, ecc. int: organizzazioni internazionali, come ad esempi la NATO. arpa: dedicato all ARPA ed ad organizzazioni ad essa correlate. Essi sono noti anche come gtld o generic Top Level Domain. Nel 2001 sono stati introdotti dei nuovi domini quali info, museum, biz, name e pro dns & bind

7 I gtld sono definiti dall ente ICANN (Internet Corporetion for Assigned Numbers and Names) che può essere visitato all indirizzo Oltre ai gtld, sono stati definiti anche dei TLD per gli stati ed i governi. Alcuni brevi esempi sono: it: Dominio dedicato all Italia fr: Dominio dedicato alla Francia es: Dominio dedicato alla Spagna de: Dominio dedicato alla Germania us: Dominio dedicato agli USA e così via per tutti gli altri stati. Il concetto di delega I domini e la loro gestione possono essere delegati. Questo significa che chi definisce e crea un dominio non necessariamente lo deve gestire ma può delegare tale attività. Normalmente avviene una delega di domini ad altre organizzazioni. Un organizzazione di grande dimensioni è probabile che abbia un dominio ed un numero elevato di sottodomini. Gestire i sottodomini può diventare oneroso, soprattutto se questi sono distribuiti nel mondo. I gtld stessi non possono preoccuparsi di gestire tutti i sottodomini esistenti. Consideriamo ad esempio il gtld.edu e l'università di Standford con dominio standford.edu. È ovvio che il responsabile del dominio.edu non possa seguire le attività del dominio standford.edu relegata esclusivamente all Università omonima. Figura 5 Dalla figura, come si può vedere, c è una delega di gestione del dominio. Vediamo nel dettaglio come ciò può essere realizzato. Name server e zone I server che gestiscono i domini e contengono le tabelle di conversione tra indirizzi e nomi delle macchine sono detti name server dns & bind

8 Normalmente un name server ha le informazioni complete di un dominio o parti di dominio chiamate zone che eventualmente carica da altri name server. Un name server che gestisce una zona è detto autoritativo di quella zona. Un name server può essere autoritativo di più zone. Definiamo ora meglio la differenza tra dominio e zona. I domini possono essere spezzati in parti più piccole chiamate zone. Vediamo un esempio nella figura seguente: Figura 6 Come si può vedere, il dominio.edu è spezzato nelle zone berkeley.edu, nwu.edu e purdue.edu Si notano anche le aree di delega, nel senso che berkley.edu è delegato alla rispettiva Università, è ciò viene definito dai gestori di.edu A sua volta chi ha in delega il dominio berkeley.edu può ulteriormente dividere a proprio piacere tale dominio in ulteriori zone: dns & bind

9 Figura 7 Oltre ad aver creato nuove zone, ci sono ulteriori deleghe per i sottodomini cc, ce, cs ed me. Ognuna di queste zone può avere il relativo name server autoritativo, alcuni dei quali potrebbero coincidere con il name server autoritativo di berkeley.edu Come si vede, una zona ed un dominio possono avere lo stesso nome tuttavia, come vedremo ora hanno nodi differenti più precisamente una zona non contiene i nodi dei sottomini delegati. Consideriamo ad esempi il dominio.ca del Canada. Figura 8 Tutti i sottodomini hanno una delega e quindi un relativo name server autoritativo. Il dominio ca, contiene tutti i dati relativi al dominio ca, oltre a tutti i dati relativi ai sottodomini ab, ca, on, qc. Tuttavia, la zona.ca contiene solo informazioni relative al dominio ca, e anche le sottozone contengono ognuna i relativi dati. Qualora invece, una zona non sia stata delegata, allora il livello precedente deve necessariamente gestire anche le sue informazioni. Vediamo in figura un esempio: dns & bind

10 Figura 9 In questo caso non è stata fatta alcuna delega delle zone bc ed sk, per cui restano di competenza della zona immediatamente precedente, in questo caso di ca. Dunque un name server non gestisce un dominio ma bensì una zona un dominio potrebbe contenere molte più informazioni di quelle che dovrebbe contenere. Qualora un dominio non contenga sottodomini, ovviamente la zona coincide con il dominio stesso. Delega dei sottodomini Più volte abbiamo già accennato alla delega dei sottodomini. Ciò che avviene nella realtà, è quella di delegare ad altri name server uno specifico sottodominio. Il name server diventa autoritativo per quest ultimo. Tipi di name server Il DNS definisce due tipi di name server: primary master e secondary master. Il primary master è il name server che contiene un file con l'elenco degli host ed i rispettivi indirizzi per la zona o le zone di cui è autoritativo. Il secondary master legge le informazioni relative ad una zona da un altro name server, chiamato master server. Normalmente il master server coincide con il primary server ma non è assolutamente un requisito. Un secondary server può leggere le informazioni da un altro secondary server. Quando un secondary server viene attivato, contatta un master server e se necessario, carica le nuove zone o le modifiche apportate dall ultima volta. Si parla di zone transfer. Ultimamente, un secondary server è più comunemente detto slave. Lo scopo di uno slave, è quello di essere il backup del master server, qualora quest ultimo dovesse presentare dei problemi. In questo modo viene garantita l'esistenza e la persistenza di un dominio. La definizione di master e slave non è così rigorosa. I name server possono essere configurati in modo tale da essere master per alcune zone e slave per altre. Dunque il ruolo di master e di slave non è ben definito. La definizione delle zone e le loro modifiche avvengono solo sui master server. Gli slave non devono essere utilizzate per tali operazioni. Zone data file Tutte le informazioni relative alle zone sono contenute nei cosiddetti zone data file del master server. Questi file sono gli stessi che vengono caricati dagli slave dns & bind

11 Resolver I resolver sono i client che contattano i name server. I programmi presenti sui computer normalmente contattano un resolver per intervistare un name server. Un resolver assolve principalmente a tre compiti: Effettua la richiesta al name server Interpreta la risposta ottenuta (il quale può essere un informazione corretta od un errore) Restituisce le informazioni al programma che ne ha effettuato la richiesta iniziale. Un programma che effettua le richiesta da solo, senza contattare un resolver intermedio, è detto stub resolver. Esistono poi gli smart resolver che hanno funzioni di cache delle richieste. Questi server vengono contattati come normali name server. Tuttavia, effettuata una richiesta, mantengono le informazioni in una cache. Qualora si presentasse la stessa richiesta, utilizzano le informazioni precedentemente salvate per soddisfare la richiesta. Resolution Lo scopo dei name server è dunque quello di individuare le informazioni all interno di un domain name space e fornire le informazioni richieste. Essi non devono fornire solo informazioni relative alle zone di cui sono autoritativi ma di qualsiasi zona esistente ed ovunque essa sia. Questo processo è detto name resolution o più brevemente resolution. Poiché la struttura del DNS è ad albero, un name server per individuare una zona di cui non ha conoscenza, utilizza i name server posti a livello di root. Ogni name server ha la possibilità di contattare un name server root, il quale a sua volta può individuare un name server relativo al sottoalbero del dominio di cui è stata effettuata la richiesta. Tale riposta viene comunicata in direzione opposta, ovvero viene rigirata al name server richiedente che a sua volta la restituisce al resolver. Root name server I root name server si conoscono tra loro e conoscono i name server autoritativi di ogni top-level (essi stessi in molti casi sono autoritativi del top-level). A fronte di una richiesta, un root name server conosce almeno il name server del dominio corrispondente. A sua volta questo name server conosce il name server dei sottodomini. In questo modo è possibile scendere all interno dell albero fino ad individuare il name server del sottodominio richiesto. L'importanza dei root name server è quindi fondamentale. Per questo motivo e per il carico di lavoro a cui sono sottoposti, è stato inventato un meccanismo di caching che analizzeremo in seguito. Senza la presenza di almeno un root server, l'intera risoluzione sarebbe ferma e di conseguenza ogni nodo su Internet non sarebbe raggiungibile per nome (ma solo per indirizzo). Per questo motivo al momento i root server mondiali sono 13 (uno gestito dalla NASA, uno da PSINet, due sono in Europa, uno in Giappone, ecc.). Nella figura seguente riportiamo un esempio di risoluzione di un nome: dns & bind

12 Figura 10 In figura, si può notare un resolver che richiede l'indirizzo IP del nodo girigiri.gbrampa.gov.au (au è il dominio relativo all Australia) al name server locale. Poiché il name server non conosce l'indirizzo richiesto e non lo ha nemmeno nella propria cache, contatta un root server. Il root server naturalmente conosce il top-level name server relativo al dominio au. Contattato quindi quest ultimo, l'indirizzo viene comunicato al name server locale il quale provvede a contattare il name server relativo ad au. Quest ultimo conosce il sottodominio gov.au ed il relativo name server, il quale viene comunicato al name server locale. Questa procedura continua nei vari sottodomini, fino a contattare il name server che conosce la macchina girigiri. L'indirizzo di quest ultima viene quindi comunicata al name server locale il quale rigira l'indirizzo al resolver e dunque al programma che ora conosce l'indirizzo per raggiungere la macchina remota. Più in generale ed indipendentemente dal nome da risolvere lo schema di risoluzione può essere schematizzato con la seguente figura: dns & bind

13 Figura 11 Scelta tra name server autoritativi e concetto di round trip time Abbiamo detto che a livello di root name server, questi sono attualmente 13. È necessario capire quali di questi viene contattato qualora se ne presenti la necessità. La scelta del name server da contattare è basata sul concetto di round trip time, noto anche come RTT. I name server usano questa metrica (RTT) per contattare gli altri name server. Essa consiste nel verificare quanto tempo trascorre nel ricevere una risposta da un name serve remoto. Viene poi effettuata una comparazione dei tempi tra i vari server e viene scelto quello che risponde in tempi minori. Mappatura da indirizzi a nomi Fino ad ora abbiamo parlato della risoluzione dei nomi, ovvero, noto un nome, recuperare il relativo indirizzo. Tuttavia alcune applicazioni richiedono il processo contrario, ovvero risalire al nome, noto l'indirizzo. Questo può ad esempio essere necessario nei file di log di alcuni servizi, in cui è comodo per l'occhio umano vedere i nomi dei server contattati o che hanno contattato il nostro server, oppure possono essere utilizzati in alcune modalità di controllo di accesso, ad esempio in Unix è noto l'utilizzo (ormai remoto) del file.rhosts ed hosts.equiv. Il processo contrario a quanto analizzato fino ad ora non è banale. Per questo motivo, è stato creato un dominio di indirizzi ARPA, in cui gli indirizzi appaiono in modo inverso. Esso ha il nome inaddr.arpa e sfrutta le proprietà dell albero analizzato fino ad ora, con la differenza che in questo caso i nomi dei domini sono i numeri che costituiscono gli IP address. Vediamo in figura come esso è costituito: dns & bind

14 Figura 12 Come si può notare, l'indirizzo IP punta al nome della macchina che può così essere recuperato. L'utilizzo dell indirizzo tuttavia, viene effettuato leggendo quest ultimo in modo inverso. Infatti nel namespace dei nomi fino ad ora analizzato, la lettura di un FQDN viene effettuata dal basso verso l'alto ad esempio winnie è in basso e.com è in alto. Invece, nel namespace inaddr.arpa., effettuando questa lettura troviamo l'ip address al contrario. Dunque se winnie.corp.hp.com ha indirizzo , il relativo indirizzo nel dominio in-addr.arpa sarà in-addr.arpa Potrebbe sembrare più utile quindi definire il namespace in-addr.arpa al contrario di quanto definito in figura. Tuttavia è necessario utilizzare gli indirizzi in modo inverso per il seguente motivo. Consideriamo la seguente figura: Figura 13 Come possiamo vedere, la parte più alta di un indirizzo (che individua la classe e la rete) è inversa rispetto ai nomi degli indirizzi e l'unico modo per avere la classe a livello di Top-Level Domain è quella di invertire l'ip. Così facendo permettiamo agli amministratori di effettuare delle deleghe di subnet (proprio come visto per i nomi dei domini in sottodomini). Dunque le subnet del namespace 15.in-addr.arpa possono essere delegate ai gestori della rete in concomitanza con la definizione di sottodomini. Lasciano invece l'indirizzo IP nella versione originale, tale deleghe non sarebbero possibili dns & bind

15 Caching Abbiamo già accennato al fatto che i name server hanno anche funzionalità di caching. Sostanzialmente la prima volta che un name server deve rispondere ad una query ricorsiva, memorizza all interno della propria cache il nome del name server autoritativo per il dominio che ha risolto. Nelle ultime versioni del BIND esiste anche la cache negativa: se un name server autoritativo risponde che un dominio oppure un sottodominio non esiste, questa informazione viene inserita nella cache del name server locale per un certo periodo di tempo. Indipendentemente da una riposta negativa o positiva, la volta successiva che il name server viene interpellato, quest ultimo risponde con le informazioni contenute nella cache. Vediamo il seguente esempio: Figura 14 Nell esempio sopra riportato vediamo la richiesta dell indirizzo IP di baobab.cs.berkeley.edu, supponendo che già in passato sia stato richiesto un dominio all interno di berkeley.edu (ad esempio potrebbe essere stato contattato eecs.berkeley.edu Ora, il name server locale conosce il name server autoritativo del dominio berkeley.edu. Come da figura, il name server locale evita di andare a contattare i root name server ma contatta direttamente il name server autoritativo del dominio berkeley.edu e successivamente attraverso la ricorsività contattata la macchina ricercata. TTL (Time To Live) Come già detto, le informazioni permangono all interno di una cache del name server. È possibile configurare il TTL, ovvero il tempo di permanenza delle informazioni all interno di una cache. L'impostazione del valore del TTL spetta al name server remoto. In altre parole è il name server autoritativo di un dominio che ne imposta il TTL ovvero quanto le informazioni dovranno permanere nei name server che ne faranno richiesta. Terminato questo tempo, le informazioni vengono cancellate dalla cache ed un name server con cache, dovrà necessariamente ricontattare il name server autoritativo di una certa zona dns & bind

16 Creazione ed implementazione di un dominio Prima di procedere alla creazione di un dominio è necessario individuare un dominio (solitamente scelto a piacere e che ricordi eventuali attività a cui si dedicheranno eventuali servizi che i vorranno implementare). Individuato il dominio è necessario verificare che questo non esista già. Un modo per verificare se un dominio esiste già ed avere qualche informazioni aggiuntiva è il seguente: Digitare il comando nslookup. Al prompt digitare set type=soa, premere enter e poi il nome del dominio che vogliamo verificare. Un altro modo per effettuare verifiche è attraverso il comando whois, oppure visitando il sito Registry, registrar e registrazione Una registry è un organizzazione responsabile dei top level domain. Una registrar o registration authority (RA) è un organizzazione che funge da intermediario tra la registry ed il richiedente di un dominio. La RA effettua la registrazione del dominio richiesto e fornisce eventuali servizi aggiuntivi. La registration autorità Italiana La registration authority italiana è l'ente responsabile dell'assegnazione dei domini posti sotto ".it", opera in regime di monopolio e consente di registrare domini solo mediante antiquate procedure cartacee. La RA gestisce nomi a dominio cctld (country code Top Level Domain).it sulla base delle norme internazionali ISO I servizi forniti dalla RA sono rivolti sia ai Provider/Maintainer, cioè a quelle organizzazioni che intendono registrare domini per conto terzi, sia a quelle persone fisiche o giuridiche che intendono gestire direttamente i propri nomi a dominio. La RA scoraggia chi intende gestire direttamente i domini singoli, mediante tariffe nettamente superiori a quelle proposte ai Provider/Maintainer. La storia del dominio.it iniziò nel 1987, quando il ruolo di registro venne informalmente assegnato al CNUCE (che diventerà poi Istituto di Informatica e Telematica), un istituto del CNR, il massimo ente di ricerca pubblico nazionale. La questione di come formalizzare questa delega si pose per la prima volta nel 1993, quando UNINFO, il rappresentante italiano di ISO, ricevette dall'iso stessa il compito di coordinarsi con le istituzioni e la comunità tecnica accademica locale per individuare formalmente le modalità di gestione del dominio Internet nazionale. Fu costituito un gruppo di lavoro che giunse sostanzialmente a definire la situazione attualmente in vigore. Il compito operativo di gestire i server centrali del dominio.it e le pratiche di registrazione, appartengono alla Registration Authority. Il compito di definire le regole di registrazione è invece affidato alla Naming Authority dns & bind

17 La registration authority italiana è responsabile di oltre domini ".it". Le regole istituite dalla Naming Authority per la registrazione di un nome a dominio.it sono le seguenti: i nomi a dominio vengono assegnati dalla RA in uso ai richiedenti, seguendo l'ordine cronologico delle richieste alcuni nomi a dominio sono riservati (Nomi a Dominio Riservati), in particolare quelli di due lettere e quelli geografici un nome a dominio non è prenotabile la procedura di assegnazione di un nome a dominio si conclude quando avviene il suo caricamento nel database dei nomi a dominio sotto il cctld "it", detto anche Registro dei Nomi Assegnati (RNA). Tale caricamento viene effettuato quando la RA ha ricevuto tutta la documentazione richiesta ed è stata verificata l'effettiva funzionalità. La documentazione per la richiesta di registrazione identificata con il nome LAR (Lettera di assunzione di responsabilità), deve essere firmata dalla persona fisica (o dal rappresentante della persona giuridica) che sarà assegnataria del dominio stesso e deve essere inviata via raccomandata o fax alla Registration Authority Italiana, Via Giuseppe Moruzzi 1, PISA o via fax al numero Il provider che registra il dominio per conto di terzi dovrà inviare un modulo elettronico. In base alle regole della Naming Autorithy Italiana possono registrare un dominio con suffisso.it solo le persone fisiche e giuridiche residenti o appartenenti ad un Paese membro dell'unione europea. La documentazione e la richiesta di registrazione identificata con il nome LAR (Lettera di assunzione di responsabilità), deve essere inviata dal legale rappresentante della società che registra il dominio, specificando ragione sociale, sede legale, partita iva, ed i dati di registrazione presso tribunale e camera di commercio. In questo caso le registrazioni sono illimitate. I liberi professionisti che richiedono l'assegnazione di un dominio devono compilare un modulo specificando l'iscrizione all'albo di competenza. Possono essere registrati infiniti nomi di dominio. Le associazioni che richiedono l'assegnazione di un dominio devono compilare un modulo specificando la ragione sociale, ed indicando una persona responsabile dell'associazione. Le associazioni riconosciute possono registrare infiniti nomi di dominio, le associazioni non riconosciute possono registrare solo un dominio. Le pubbliche amministrazioni che richiedono l'assegnazione di un dominio devono compilare un modulo specifico. Possono essere registrati infiniti nomi di dominio. In caso di registrazione da parte di una persona singola, sono sufficienti i dati anagrafici, la residenza ed il codice fiscale. Un singolo può registrare un solo nome di dominio. Per maggiori informazioni sia sulla registration authority che per la naming authority, è possibile visitare l'indirizzo In particolare si consiglia di visitare la pagina La RA dipende a sua volta dall organismo internazionale ICANN già brevemente indicato all inizio del manuale. Nella richiesta di un dominio sarà naturalmente necessario indicare anche l' indirizzo IP dell eventuale name server locale che è stato assegnato alla propria infrastruttura, in modo che avvenga l'associazione tra il name server locale autoritativo del proprio dominio ed il nome del dominio dns & bind

18 È importante registrare il nostro dominio, affinché questi appaia sotto un cctld in questo modo sarà visibile su tutta internet. Qualora non avvenga la registrazione, nessun name server presente su internet sarà in grado di individuare il nostro name server locale e quindi di accedere al nostro dominio. Configurazione del BIND L'attuale BIND è giunto alla versione 9 e noi utilizzeremo quest ultimo è importante notare che in alcuni casi esistono delle profonde differenze dalle versioni attuale, soprattutto dalla versione BIND 8 a successive. Definizione di una zona Normalmente, in ambiente Unix, i file di configurazione del BIND sono nella directory /etc/bind All interno di questa directory vi sono svariati file, quelli che traducono da nome ad IP e sono detti forward mapping mentre quelli che traducono da IP a nome sono detti reverse mapping. I file iniziano con db. seguito dal nome del dominio per quanto riguarda il forward mapping mentre è seguito dalla rete IP per i reverse mapping esclusi gli zeri ed eventuali subnet dovute alla netmask. Quindi ad esempio la classe A avrà file reverse db.15, la classe B avrà file db ed infine la classe C avrà il file di nome db Dunque supponendo di avere una rete privata di classe 10, e volendo creare un dominio di nome dominio.it i file saranno rispettivamente db.dominio.it e db.10 Questi file sono comunemente noti come zone data files. Infine c è un file denominato named.conf che identifica tutti i file forward e reverse mapping presenti nella directory. Naturalmente, un name server può gestire più domini, quindi potranno apparire più file relativi a domini diversi. In particolare, sono previsti anche i domini ed i file relativi al localhost con indirizzo ed al broadcast. Questi file sono predefiniti e non richiedono modifiche. All intero dei file, i vari record sono detti Resource Record o più comunemente RR. Le informazioni i essi contenute sono case-insensitive, dunque non c è differenza tra lettere maiuscole e minuscole, anche se convenzionalmente si utilizzano le lettere minuscole. All interno degli RR, incontriamo diverse tipologie di informazioni, ed anche se l'ordine di apparizione non è importante, convenzionalmente si scrivono: SOA (Start Of Authority): RR che indica l'autorità della zona NS (Name Server): RR che indica il nome del name server della zona. Altri record (dati relativi agli hosts interni alla zona quali nomi e relativi indirizzi di rete) Esistono poi ancora altri tipi di record: A (Address):RR con conversione da nome ad indirizzo dns & bind

19 PRT (Pointer):RR con conversione da indirizzo a nome CNAME (Canonical name):rr con alias per gli hosts Esistono poi ancora altri RR di importanza minore che analizzeremo in seguito. Configurazione del TTL della zona Prima di configurare la zona, è necessario individuare la versione di BIND che stiamo utilizzando. Prima della versione 8.2, l'ultimo campo del SOA record, indicava il TTL, che come già visto indica il tempo di permanenza delle informazioni all interno delle cache dei name server che individueranno la nostra zona. Nelle versioni successive, questo campo è diventato relativo alla cache negativa già vista in precedenza. Per poter definire il TTL vero e proprio (o anche detto TTL di cache positiva) è necessario che ogni file (sia forward che reverse) inizia con lo statement $TTL. Per indicare ad esempio un tempi di permanenza i n cache di tre ore, i nostro file di dominio dovranno iniziare con la riga $TTL 3h. Record SOA Come già anticipato, questo campo identifica il name server autoritativo della zona, più alcuni altri parametri che ora analizzeremo. Il SOA deve comparire in entrambi i file di zona (forward e reverse) ed all interno di un singolo file, il SOA deve essere unico. Vediamo un esempio: Si noti che tutti i nomi delle macchine che seguiranno nelle prossime pagine terminano sempre con il punto finale indicando quindi nomi assoluti. movie.edu. IN SOA terminator.movie.edu. al.robocop.movie.edu. ( 1 Serial 3h Refresh after 3 hours 1h Retry after 1 hour 1w Expire after 1 week 1h ) Negative caching TTL of 1 day In questo caso è stato dichiarato un dominio di nome movie.edu con name server autoritativo di nome terminator. Il secondo nome (al.robocop.movie.edu) indica l'indirizzo di posta elettronica (il primo punto in realtà è da immaginarsi con il anche se non può essere utilizzato) del responsabile del dominio. Il termine IN sta ad indicare il tipo di rete (in questo caso INternet) sembrerebbe un osservazione banale ma in realtà esistono altre tipologie di rete e dunque IN specifica quella che si vuole utilizzare. Record NS Dopo il record SOA è possibile inserire i nomi dei name server che possono essere più di uno. Un esempio è il seguente: movie.edu. IN NS terminator.movie.edu. movie.edu. IN NS wormhole.movie.edu dns & bind

20 Anche i RR NS come i SOA devono comparire sia nei file forward che reverse. Address e alias Dopo i record NS si inseriscono i nomi delle macchine e relative alias. Vediamo un esempio: Host addresses localhost.movie.edu. IN A robocop.movie.edu. IN A terminator.movie.edu. IN A diehard.movie.edu. IN A misery.movie.edu. IN A shining.movie.edu. IN A carrie.movie.edu. IN A Multi-homed hosts wormhole.movie.edu. IN A wormhole.movie.edu. IN A Aliases bigt.movie.edu. IN CNAME terminator.movie.edu. dh.movie.edu. IN CNAME diehard.movie.edu. wh.movie.edu. IN CNAME wormhole.movie.edu. wh249.movie.edu. IN A wh253.movie.edu. IN A Come è possibile vedere, ogni nome di macchina ha un relativo IP associato. Inoltre un singolo computer può avere più nomi. Per definire un secondo nome si utilizza il RR CNAME come visto in esempio. Record PTR Nel file reverse, il RR SOA è diverso in alcuni punti rispetto al forward: $TTL 3h in-addr.arpa. IN SOA terminator.movie.edu. al.robocop.movie.edu.( 1 Serial 3h Refresh after 3 hours 1h Retry after 1 hour 1w Expire after 1 week 1h ) Negative caching TTL of 1 hour Name servers in-addr.arpa. IN NS terminator.movie.edu in-addr.arpa. IN NS wormhole.movie.edu. Come è possibile notare, nel SOA, al posto del dominio abbiamo inserito la classe utilizzata e scritta al contrario, privandola di eventuali zeri indicanti la rete ed eventuali subnet dovute alla netmask. Analogamente nella definizione dei RR di tipo NS. All interno dei file reverse è necessario indicare le associazione tra IP e nome della macchina. La sintassi è la seguente: in-addr.arpa. IN PTR wormhole.movie.edu dns & bind

21 in-addr.arpa. IN PTR robocop.movie.edu in-addr.arpa. IN PTR terminator.movie.edu in-addr.arpa. IN PTR diehard.movie.edu. L'esempio completo. Vediamo dunque il file completo di forward: $TTL 3h movie.edu. IN SOA terminator.movie.edu. al.robocop.movie.edu. ( 1 Serial 3h Refresh after 3 hours 1h Retry after 1 hour 1w Expire after 1 week 1h ) Negative caching TTL of 1 hour Name servers movie.edu. IN NS terminator.movie.edu. movie.edu. IN NS wormhole.movie.edu. Addresses for the canonical names localhost.movie.edu. IN A robocop.movie.edu. IN A terminator.movie.edu. IN A diehard.movie.edu. IN A misery.movie.edu. IN A shining.movie.edu. IN A carrie.movie.edu. IN A wormhole.movie.edu. IN A wormhole.movie.edu. IN A Aliases bigt.movie.edu. IN CNAME terminator.movie.edu. dh.movie.edu. IN CNAME diehard.movie.edu. wh.movie.edu. IN CNAME wormhole.movie.edu. Interface specific names wh249.movie.edu. IN A wh253.movie.edu. IN A mentre per quanto riguarda il file di reverse $TTL 3h in-addr.arpa. IN SOA terminator.movie.edu. al.robocop.movie.edu.( 1 Serial 3h Refresh after 3 hours 1h Retry after 1 hour 1w Expire after 1 week 1h ) Negative caching TTL of 1 hour Name servers in-addr.arpa. IN NS terminator.movie.edu in-addr.arpa. IN NS wormhole.movie.edu. Addresses point to canonical name in-addr.arpa. IN PTR wormhole.movie.edu in-addr.arpa. IN PTR robocop.movie.edu dns & bind

22 in-addr.arpa. IN PTR terminator.movie.edu in-addr.arpa. IN PTR diehard.movie.edu. Il file dei root name server Nella versione 9 del BIND c è un file chiamato db.cache (nelle versioni precedenti è chiamato named.root) il quale contiene tutti i riferimenti ai name server root di Internet già illustrati precedentemente. Un estratto potrebbe essere: IN NS A.ROOT-SERVERS.NET. A.ROOT-SERVERS.NET A formerly NS1.ISI.EDU NS B.ROOT-SERVERS.NET. B.ROOT-SERVERS.NET A formerly C.PSI.NET NS C.ROOT-SERVERS.NET. C.ROOT-SERVERS.NET A formerly TERP.UMD.EDU NS D.ROOT-SERVERS.NET. D.ROOT-SERVERS.NET A formerly NS.NASA.GOV NS E.ROOT-SERVERS.NET. E.ROOT-SERVERS.NET A Questo file ovviamente non deve essere modificato. Tuttavia esso può essere periodicamente aggiornato. Esso può essere prelevato all indirizzo ftp.rs.internic.net ( ). Il file di configurazione del bind Oltre ai file di zona c è il file named.conf. In esso vanno inseriti i file di zona e le modalità di configurazione. Una prima opzione indica la directory di lavoro del bind, un esempio potrebbe essere options { directory "/var/named" // Place additional options here. } Sul server che abbiamo deciso essere il primario del dominio, è necessario indicarlo. Ciò avviene tramite le seguenti istruzioni: zone "movie.edu" in { type master file "db.movie" } dns & bind

23 Analogamente per il reverse è necessario introdurre: zone " in-addr.arpa" in { type master file "db " } Abbreviazioni Fino ad ora abbiamo visto come effettuare formalmente la configurazione dei file. Tuttavia è possibile introdurre delle abbreviazioni: Nomi e domini Parte dei nomi possono essere abbreviati eliminando il dominio ad esempio la riga robocop.movie.edu. IN A può essere abbreviata in robocop IN A Anche nel file reverse la riga in-addr.arpa. IN PTR roboco.movie.edu. può essere abbreviata in 2 IN PTR robocop.movie.edu. La Molto frequentemente, all interno del SOA, al posto del dominio si può trovare il Dunque esso ha il significato di sostituire il nome del dominio. Dunque il SOA potrebbe IN SOA terminator.movie.edu. al.robocop.movie.edu. ( 1 Serial 3h Refresh after 3 hours 1h Retry after 1 hour 1w Expire after 1 week 1h ) Negative caching TTL of 1 hour Ripetizione dei nomi Qualora ci si debba riferire, in due righe successive alla stessa macchina, non è necessario ripetere due volte il suo nome. Supponiamo ad esempio che una macchina abbia due indirizzi. Per indicarlo sarà sufficiente scrivere: wormhole IN A IN A dns & bind

24 Esempio con abbreviazione Riprendiamo i file di configurazione precedentemente analizzati e vediamoli in forma abbreviata Il forward è: $TTL 3h Origin added to names not ending in a dot: IN SOA terminator.movie.edu. al.robocop.movie.edu. ( 1 Serial 3h Refresh after 3 hours 1h Retry after 1 hour 1w Expire after 1 week 1h ) Negative caching TTL of 1 hour Name servers (The name '@' is implied) IN NS terminator.movie.edu. IN NS wormhole.movie.edu. Addresses for the canonical names localhost IN A robocop IN A terminator IN A diehard IN A misery IN A shining IN A carrie IN A wormhole IN A IN A Aliases bigt IN CNAME terminator dh IN CNAME diehard wh IN CNAME wormhole Interface specific names wh249 IN A wh253 IN A Per quanto riguarda il reverse invece avremo: $TTL 3h Origin added to names not ending in a dot: IN SOA terminator.movie.edu. al.robocop.movie.edu. ( 1 Serial 3h Refresh after 3 hours 1h Retry after 1 hour 1w Expire after 1 week 1h ) Negative caching TTL of 1 hour Name servers (The name '@' is implied) IN NS terminator.movie.edu. IN NS wormhole.movie.edu dns & bind

25 Addresses point to canonical names 1 IN PTR wormhole.movie.edu. 2 IN PTR robocop.movie.edu. 3 IN PTR terminator.movie.edu. 4 IN PTR diehard.movie.edu. Il SOA ed i NS possono ulteriormente essere semplificati eliminando i IN SOA terminator al.robocop ( 1 Serial 3h Refresh after 3 hours 1h Retry after 1 hour 1w Expire after 1 week 1h ) Negative caching TTL of 1 day IN NS terminator IN NS wormhole Configurazione degli host all interno di un dominio Ora che abbiamo visto come configurare un name server, è necessario che tutte le macchine appartenenti ad un dominio facciano riferimento ad esso, affinché possano accedere ad internet od a servizi presenti all interno del dominio. In questo contesto parleremo di macchine Unix. Tutti i sistemi Unix hanno il file /etc/resolv.conf Questo contiene indicazioni sul dominio di appartenenza ed i riferimenti ai name server relativi al dominio stesso. La direttiva domain All interno del file si utilizza la direttiva domain seguita dal dominio a cui la macchina appartiene. Ad esempio domain movie.edu Questo parametro può anche essere indicato tramite il comando hostname di Unix. Ad esempio hostname pc.movie.edu imposta il nome della macchina ed il relativo dominio. La direttiva search Un altra direttiva è search che può essere utilizzata per gestire la search list. La search list contiene un elenco di domini che vengono inseriti tramite la direttiva search. Questi vengono appesi automaticamente dopo i nomi delle macchine. Ad esempio telnet pc tenterà di connettersi alla macchina pc.movie.edu perché la direttiva domain movie.edu ha inserito automaticamente nella search list il dominio indicato (la direttiva domain, per default inserisce nella search list il dominio, senza la necessità di usare search). Qualora sia necessario lavorare su macchine in domini diversi, oppure una macchina appartiene a domini diversi, può essere utile definire una search list: search movie.edu ho.com fox.it dns & bind

26 in questo caso, digitando telnet pc, verrà applicata la search list, nell ordine indicato fino a trovare la macchina. La direttiva nameserver Infine la direttiva più importante è nameserver che indica l'ip address del nameserver a cui fare riferimento. Ad esempio nameserver è possibile (e consigliabile) indicare almeno due nameserver in modo che se il primo (master) non funziona, viene contattato il secondo (slave). Normalmente le direttive domain e nameserver sono un esempio sufficiente da inserire nel file resolv.conf Definizione di un name server slave Fino ad ora abbiamo visto un esempio per la definizione di una master name server ovvero di un name server che funge da autoritativo per una zona. Vediamo ora l implementazione di uno slave, dunque di un name server secondario che funge da backup, qualora il master presenti dei problemi. Ovviamente sarà necessario installare il bind sulla macchina in questione. Inoltre dovremo mantenere i file presenti sotto la directory /etc/bind così come ci vengono proposti. Tuttavia, in questo caso non dovremo creare i file relativi al dominio che vogliamo gestire. Vediamo ora le differenze tra il master e lo slave: il file named.conf nel master era configurato nel seguente modo: zone "movie.edu" in { type master file "db.movie.edu" } ora invece dovremo inserire le seguenti direttive: zone "movie.edu" in { type slave file "bak.movie.edu" masters { } } In questo modo abbiamo istruito il server di che tipo è, ovvero uno slave, che dovrà salvare un file di nome bak.movie.edu e che dovrà prelevare le informazioni (il zone data file) dal master con l IP indicato. Il file bak verrà salvato in base alla direttiva iniziale contenuta all inizio del file named.conf. Il default è /var/cache/bind dns & bind

27 Questi file sono una copia dei file del master. Per verificare che tutto funzioni si consiglia su entrambi i sistemi di fare un tail f del file syslog dove si può vedere il trasferimento delle informazioni. Naturalmente la stessa cosa andrà fatta per gli indirizzi inversi, dunque un esempio potrebbe essere: zone " in-addr.arpa" in { type slave file "bak " masters { } } Il record SOA Ora possiamo analizzare alcuni parametri incontrati in precedenza relativi al SOA record. Rivediamolo: movie.edu. IN SOA terminator.movie.edu. al.robocop.movie.edu. ( 1 Serial 3h Refresh after 3 hours 1h Retry after 1 hour 1w Expire after 1 week 1h ) Negative caching TTL of 1 day Il primo campo è il numero seriale. Questo viene incrementato ogni volta che si apporta una modifica ai file delle zone. È necessario che questa operazione venga effettuata, in caso contrario le modifiche non verranno percepite dallo slave server. Normalmente è buona norma indicare la data al posto del semplice numero. Dunque ad esempio YYYYMMGGVE, dove VE indica un numero di versione a due cifre all interno della singola giornata qualora sia necessario in un giorno solo effettuare più modifiche. Un esempio potrebbe essere per la prima modifica della giornata e per la seconda modifica e così via. Il numero deve sempre essere maggiore dei precedenti, in caso contrario lo slave non attuerà gli aggiornamenti. Dopo aver effettuato una modifiche è necessario effettuare un reload del server master. Non è necessario effettuare nulla sullo slave. Il campo refresh indica allo slave l'intervallo di tempo in cui andare nuovamente a prelevare e verificare aggiornamenti sul master. Il campo retry indica l'intervallo di tempo dopo il quale, lo slave cerca di contattare il master, qualora quest ultimo non risulti raggiungibile. Il campo expire indica il tempo di scadenza delle informazioni dello slave, qualora quest ultimo non sia in grado di contattare il master. Scopo di questo intervallo di tempo è il seguente: qualora questo sia trascorso, si ritiene che le informazioni siano obsolete e dunque non compatibili con la realtà, dunque lo slave non propaga più le informazioni. Naturalmente questo parametro deve indicare un periodo notevolmente più lungo dei precedenti per ovvi motivi. Il campo negative TTL indica le informazioni relative alla cache negativa, ovvero la durata di validità di queste informazioni dns & bind

28 Master server multipli Abbiamo visto che nello slave server compare un riferimento al master server. Naturalmente è possibile indicare, qualora esistano, più master server a cui lo slave server deve fare riferimento. Questo viene effettuato con la sintassi seguente: masters { } Lo slave contatterà il master server nell ordine sequenziale in cui compaiono. Il primo che gli risponde sarà colui che gli trasferisce le informazioni. Zone multiple Fino ad ora abbiamo visto come definire una zona all interno di un server. Come detto all inizio di questo manuale, un server può gestire più zone. Per fare ciò è sufficiente effettuare quanto visto fino ad ora sullo stesso server. Dunque bisognerà creare i due file di forward e reverse ed inserirne le definizioni all interno del file named.conf. Gestione dei sottodomini e deleghe In alcuni casi è necessario definire dei sottodomini, sia per differenziare settori diversi, oppure clienti diversi o per altre necessità. Un sottodominio può essere gestito dal name server che lo definisce, oppure quest ultimo può delegare ad un altro name server la gestione del dominio stesso. Creazione e gestione di sottodomini senza delega Per creare un sottodominio basta agire nel file di zona con una semplice operazione quale quella descritta dal seguente esempio: brazil.personnel IN A IN MX 10 brazil.personnel.movie.edu. IN MX 100 postmanrings2x.movie.edu. employeedb.personnel IN CNAME brazil.personnel.movie.edu. db.personnel IN CNAME brazil.personnel.movie.edu. Come si può vedere, è stata introdotta una macchina di nome brazil all interno del sottodominio personnel che così è stato creato. Inoltre, anche se non obbligatorio, sono stati creati due CNAME sempre appartenenti al sottodominio. È anche possibile, tramite lo statement $ORIGIN, definire delle aree riferite al sottodominio all interno del file: $ORIGIN personnel.movie.edu. brazil IN A IN MX 10 brazil.personnel.movie.edu. IN MX 100 postmanrings2x.movie.edu. employeedb IN CNAME brazil.personnel.movie.edu. db IN CNAME brazil.personnel.movie.edu. In questo modo non è necessario specificare il sottodominio dns & bind

29 Creazione e gestione di sottodomini con delega Qualora, oltre a creare un sottodominio, sia necessario anche definire una delega, bisogna effettuare alcune operazioni sulla configurazione dei server. Supponiamo si voglia creare il dominio fx.movie.edu e lo si voglia delegare ad un server di nome bladerunner. Ovviamente su quest ultimo sarà necessario installare il bind. $TTL IN SOA bladerunner.fx.movie.edu. hostmaster.fx.movie.edu. ( 1 serial 3h refresh 1h retry 1w expire 1h ) negative caching TTL IN NS bladerunner IN NS outland MX records for fx.movie.edu IN MX 10 starwars IN MX 100 wormhole.movie.edu. starwars handles bladerunner's mail wormhole is the movie.edu mail hub bladerunner IN A IN MX 10 starwars IN MX 100 wormhole.movie.edu. br IN CNAME bladerunner outland IN A IN MX 10 starwars IN MX 100 wormhole.movie.edu. starwars IN A IN MX 10 starwars IN MX 100 wormhole.movie.edu. empire IN A IN MX 10 starwars IN MX 100 wormhole.movie.edu. jedi IN A IN MX 10 starwars Vi sarà poi il file reverse: $TTL IN SOA bladerunner.fx.movie.edu. hostmaster.fx.movie.edu. ( 1 serial 3h refresh 1h retry 1w expire 1h ) negative caching TTL IN NS bladerunner.fx.movie.edu. IN NS outland.fx.movie.edu. 2 IN PTR bladerunner.fx.movie.edu. 3 IN PTR outland.fx.movie.edu. 4 IN PTR starwars.fx.movie.edu dns & bind

30 5 IN PTR empire.fx.movie.edu. 6 IN PTR jedi.fx.movie.edu. Infine bisognerà configurare il file named.conf: Tra le varie direttive dovranno sicuramente anche comparire: zone "fx.movie.edu" { type master file "db.fx.movie.edu" } zone " in-addr.arpa" { type master file "db " } Definizione di uno slave per un sottodominio Vogliamo anche garantire una ridondanza dei name server e dunque definiamo anche uno slave server per il sottodominio fx.movie.edu Come noto il corrispondente named.conf dovrà avere la seguente configurazione: zone "fx.movie.edu" { type slave masters { } file "bak.fx.movie.edu" } zone " in-addr.arpa" { type slave masters { } file "bak " } Delega sul name server primario In questo modo, per quanto visto fino ad ora, abbiamo i server master e slave pronti per gestire il sottodominio fx.movie.edu Ora, sul master server del dominio movie.edu bisogna delegare la gestione del sottodominio fx.movie.edu ai due server appena analizzati. Per fare questo è necessario effettuare le seguenti impostazioni all interno del file db.movie.edu: fx IN NS bladerunner.fx.movie.edu IN NS outland.fx.movie.edu. In questo modo viene indicato che il sottodominio fx è gestito dai server sopra indicati. Tuttavia queste informazioni non sono ancora sufficienti. Infatti un name server esterno che chiedesse al primario di movie.edu quale fosse il name server che gestisce il sottodominio fx, avrebbe bisogno del corrispondente indirizzo IP. Ma quest ultimo non compare nelle informazioni sopraindicate. Dunque è necessario anche indicare quest ultimo: fx IN NS bladerunner.fx.movie.edu dns & bind

31 86400 IN NS outland.fx.movie.edu. bladerunner.fx.movie.edu IN A outland.fx.movie.edu IN A In questo modo abbiamo demandando la gestione del sottodominio ai due server. Queste informazioni sono dette glue records, in quanto incollano il dominio con il sottodominio. Naturalmente queste glue record sono necessari perché i server sono all interno di fx. Se i server erano esterni, non era necessario inserire alcun glue record, in quanto sarebbero stati trattati come normalissimi name server esterni da contattare in modo tradizionale secondo quanto visto fino ad ora. Definizione di uno slave server per il dominio principale Il dominio principale movie.edu è gestito dal master server secondo quanto descritto dal paragrafo precedente. Tuttavia vogliamo anche definire uno slave per il sottodominio. Al fine di fare ciò, invece di utilizzare una nuova macchina possiamo sfruttare il sistema chiamato bladerunner, già primario del sottodominio fx. Dunque la macchina avrà due ruoli: master per il sottodominio fx e slave per il dominio principale. Per effettuare ciò definiremo la seguente configurazione nel file named.conf di bladerunner: zone "fx.movie.edu" { type master file "db.fx.movie.edu" } zone " in-addr.arpa" { type master file "db " } zone "movie.edu" { type slave masters { } file "bak.movie.edu" } Come è possibile vedere, il server agisce come master per il sottodominio fx, tuttavia agisce come slave per il dominio principale movie.edu Delega di un dominio in-addr.arpa Qualora il dominio ed i sottodomini siano costituiti da macchine appartenenti alla stessa classe di indirizzi, non è necessario fare nulla. Qualora invece gli indirizzi siano diversi od appartenenti a subnet diverse, è necessario effettuare alcune operazioni aggiuntive. Subnetting su ottetti Consideriamo il subnetting basato su ottetti interi. Ad esempio consideriamo la classe B /24 ovvero con il terzo ottetto dedicato alle subnet. Si considerino alcuni sottodomini, ognuno di essi con la relativa subnet derivata dalla classe B sopra indicata. Un esempio del file reverse potrebbe quindi essere: dns & bind

32 IN NS gump.fx.altered.edu IN NS toystory.fx.altered.edu IN NS prettywoman.makeup.altered.edu IN NS priscilla.makeup.altered.edu IN NS blowup.foley.altered.edu IN NS muppetmovie.foley.altered.edu. In questo caso, possiamo vedere che ai vari sottodomini, sono state assegnate varie subnet: fx.altered.edu /24 makeup.altered.edu /24 Foley.altered.edu /20 Tabella 1 Subnetting su SVLM o non-ottetti Consideriamo ora classi in cui vengono utilizzate le SVLM Dobbiamo distinguere tra: Reti di classi A e B Si prenda la classe con netmask Le subnet potranno andare da 200 a 207. In questo caso il file 15.in-addr.arpa sarà: in-addr.arpa IN NS ns-1.cns.hp.com in-addr.arpa IN NS ns-2.cns.hp.com in-addr.arpa IN NS ns-1.cns.hp.com in-addr.arpa IN NS ns-2.cns.hp.com in-addr.arpa IN NS ns-1.cns.hp.com in-addr.arpa IN NS ns-2.cns.hp.com in-addr.arpa IN NS ns-1.cns.hp.com in-addr.arpa IN NS ns-2.cns.hp.com in-addr.arpa IN NS ns-1.cns.hp.com in-addr.arpa IN NS ns-2.cns.hp.com in-addr.arpa IN NS ns-1.cns.hp.com in-addr.arpa IN NS ns-2.cns.hp.com in-addr.arpa IN NS ns-1.cns.hp.com in-addr.arpa IN NS ns-2.cns.hp.com in-addr.arpa IN NS ns-1.cns.hp.com in-addr.arpa IN NS ns-2.cns.hp.com. Esiste uno statement che permette di semplificare la struttura del file precedente sebbene quest ultima sia corretta e funzionante: $GENERATE $.1.15.in-addr.arpa IN NS ns-1.cns.hp.com. $GENERATE $.1.15.in-addr.arpa IN NS ns-1.cns.hp.com. Lo statement $GENERATE permette di effettuare un loop su tutti gli indirizzi indicati subito dopo di esso e di sostituirli al posto del simbolo $, come appare chiaro dall esempio. Reti di classe C Consideriamo ora la rete /24 con netmask dns & bind

33 In questo modo abbiamo le subnet /26, /26, /26, and /26. In base a quanto visto in precedenza bisogna in-addr.arpa IN NS ns1.foo.com in-addr.arpa IN NS ns2.foo.com in-addr.arpa IN NS ns1.foo.com in-addr.arpa IN NS ns2.foo.com in-addr.arpa IN NS relay.bar.com in-addr.arpa IN NS gw.bar.com in-addr.arpa IN NS relay.bar.com in-addr.arpa IN NS gw.bar.com in-addr.arpa in-addr.arpa in-addr.arpa in-addr.arpa IN NS mail.baz.com. IN NS IN NS mail.baz.com. IN NS e così via fino all indirizzo in-addr.arpa. Semplificando con lo statement $GENERATE questo può essere trasformato in: $GENERATE 0-63 $ in-addr.arpa IN NS ns1.foo.com. $GENERATE 0-63 $ in-addr.arpa IN NS ns2.foo.com. $GENERATE $ in-addr.arpa IN NS relay.bar.com. $GENERATE $ in-addr.arpa IN NS gw.bar.com. $GENERATE $ in-addr.arpa IN NS mail.baz.com. $GENERATE $ in-addr.arpa IN NS Ovviamente anche il file named.boot sui server di delega dovrà essere opportunamente configurato, ad esempio su ns1.foo.com, il file sarà: zone " in-addr.arpa" { type master file "db " } zone " in-addr.arpa" { type master file "db " } Il file db sarà quindi: $TTL IN SOA ns1.foo.com. root.ns1.foo.com. ( 1 Serial 3h Refresh 1h Retry 1w Expire 1h Negative caching TTL IN NS ns1.foo.com. IN NS ns2.foo.com. IN PTR thereitis.foo.com dns & bind

34 che ovviamente ha un solo PTR In questo modo tuttavia, è necessario mantenere un file di zona per ogni IP. Esiste quindi un modo per ovviare a questo: Esso consiste nel creare dei CNAME e dunque dei sottodomini relativi ad ogni subnet. Ognuno di questi sottodomini vengono poi, come visto in precedenza delegati ai relativi name server. Dunque: in-addr.arpa. IN CNAME in-addr.arpa in-addr.arpa. IN CNAME in-addr.arpa in-addr.arpa IN NS ns1.foo.com in-addr.arpa IN NS ns2.foo.com in-addr.arpa. IN CNAME in-addr.arpa in-addr.arpa. IN CNAME in-addr.arpa in-addr.arpa IN NS relay.bar.com in-addr.arpa IN NS gw.bar.com in-addr.arpa. IN CNAME in-addr. arpa in-addr.arpa. IN CNAME in-addr. arpa in-addr.arpa IN NS mail.baz.com in-addr.arpa IN NS Utilizzando $GENERATE il tutto può essere scritto: $GENERATE 1-63 $ IN CNAME $ in-addr.arpa in-addr.arpa IN NS ns1.foo.com in-addr.arpa IN NS ns2.foo.com. $GENERATE $ IN CNAME $ in-addr.arpa in-addr.arpa IN NS relay.bar.com in-addr.arpa IN NS gw.bar.com. In questo modo ora possono essere creati dei file reverse relativi ai sottodomini. Può quindi ad esempio essere creato relativo a in-addr.arpa. Parte del file db sarà dunque: $TTL IN SOA ns1.foo.com. root.ns1.foo.com. ( 1 Serial 3h Refresh 1h Retry 1w Expire 1h ) Negative caching TTL IN NS ns1.foo.com. IN NS ns2.foo.com. 1 IN PTR thereitis.foo.com. 2 IN PTR setter.foo.com. 3 IN PTR mouse.foo.com dns & bind

35 Il DNS e la posta elettronica Abbiamo già incontrato negli esempi precedentemente illustrati alcuni record con la direttiva MX. Questi record sono detti MX record ed indicano qual è il server di posta elettronica (mail exchanger)che deve ricevere, per quello specifico dominio, la posta elettronica. In altre parole, quando si invia un messaggio ad [email protected], è necessario che il nostro client di posta elettronica sabbia a quale macchina inviare il messaggio che intende spedire. Questa macchina (nota appunto come mail exchanger) dovrà trattare in modo adeguato il messaggio, rigirandolo ad un altro computer addetto ad archiviare il messaggio nella casella postale di utente (mailbox) oppure il mail exchanger stesso può possedere delle mailbox tra cui quella di utente. Per indicare l'ip del mai exchanger al client di posta naturalmente viene utilizzato il DNS secondo quanto visto fino ad ora, ma con la differenza che viene richiesto l?ip del cosiddetto MX per quello specifico dominio (nel nostro caso movie.edu). Dopo che il client di posta elettronica sarà a conoscenza dell IP del mail exchanger, invierà a quest ultimo il messaggio. Un MX record viene così definito: peets.mpk.ca.us. IN MX 10 relay.hp.com. Il primo campo indica il dominio mentre l ultimo campo è il nome del mail exchanger. Il numero 10 che compare come quarto campo indica la priorità dell MX. Più basso è il numero più è elevata la priorità. In questo modo si possono inserire più MX con priorità diversa. Dall esterno, verrà sempre contattato quello con priorità più elevata (numero più basso). Qualora quest ultimo non sia raggiungibile, viene contattato quello con priorità maggiore tra quelli disponibili. plange.puntacana.dr. IN MX 1 listo.puntacana.dr. plange.puntacana.dr. IN MX 2 hep.puntacana.dr. In questo caso l'host listo verrà trattato con priorità maggiore di hep, tuttavia se listo non può essere contattato, verrà tentata la connessione ad hep. I numeri in sé non hanno alcun significato, infatti nell esempio precedente invece dei numeri 1 e 2 avremmo potuto utilizzare 10 e 20 o qualsiasi altri numero di nostra preferenza. È anche possibile avere dei server con la stessa priorità: plange.puntacana.dr. IN MX 1 listo.puntacana.dr. plange.puntacana.dr. IN MX 2 hep.puntacana.dr. plange.puntacana.dr. IN MX 2 fire.puntacana.dr. In questo caso gli host hep e fire hanno la stessa priorità. Qualora listo non sia disponibile, verrà scelto a caso un host tra hep e fire. La modalità con cui viene scelto un server tra alcuni di stessa priorità dipende dal server mittente, anche se l'algoritmo più diffuso è una scelta casuale. Sebbene il concetto di MX alternativi sembri banale, in realtà il sistema da implementare non è così banale. Infatti possono avvenire dei routine loop dei messaggi di posta. Consideriamo ancora l'esempio precedente qualora listo non sia raggiungibile, verrà selezionato uno dei due host successivi. Tuttavia quest ultimi non hanno le caselle postali degli utenti. Infatti i clienti posta, come noto, sono configurati per ricevere ed inviare posta tramite un mail exchanger unico, non è possibile specificare altri indirizzi alternativi. Dunque le mailbox risiedono su listo dns & bind

36 (In realtà si potrebbe prevedere mailbox condivise da più macchine tramite ad esempio NFS, avendo così la disponibilità continuativa delle mailbox). Supponiamo dunque che la posta pervenga su hep. Ora hep, cercherà di inviare la posta a listo che non risponde. Potrebbe succedere che cerchi dunque di rispedirlo a se stesso, creando un routing loop. Oppure ancora potrebbe cercare di inviare il tutto a fire, che tuttavia presenterà gli stessi problemi creando nuovamente un routing loop. Per evitare questo problema, un mail exchanger (noto anche come mail transfer agent o più semplicemente MTA) prima di rigirare la posta elettronica ad un altro MTA, ne verifica la priorità indicata nell MX record. Se risulta uguale o più bassa della sua, scarta l'mx. Solo quelli con valore più alti di priorità (numero dell MX più basso) saranno presi in considerazione. In caso contrario trattiene la posta elettronica fino a quando uno di essi non sarà nuovamente disponibile. Gestione del BIND Come già visto, il file di configurazione principale del BIND è named.conf. In esso possono essere inserite svariate direttive per controllare il funzionamento del BIND. Per gestire lo startup, stop, reload del BIND è possibile utilizzare i comandi di invio segnali tradizionali di Unix tramite il comando kill. Tuttavia la versione 9 di BIND è supportata dal comando rndc. Questo comando può essere seguito da dei parametri, oppure può essere seguito direttamente dal tasto enter. In questo casi appare un prompt in cui possono essere digitati ulteriori comandi. Ad esempio: #rndc[invio] getpid status stop exec reload [zone]... reconfig [-noexpired] (just sees new/gone zones) dumpdb stats trace [level] notrace querylog qrylog help quit rndc> Tra i comandi più utilizzati: getpid indica il PID del processo named, responsabile del funzionamento del BIND. status indica svariate funzioni che indicano il funzionamento attuale del BIND start, stop e restart hanno un significato ovvio. reload permette al named di rileggere i file di configurazione dumpdb effettua un backup dei zone file. stats scrive in un file le statiche di funzionamento del named. trace appende delle informazioni di debug notrace disattiva il comando precedente querylog attiva o disattiva il log all intenrno del file syslog dns & bind

37 Il comando rndc utilizza anche la direttiva control per esempio per configurare il proprio DNS su una specifica porta si può inserire il comando control all interno del file named.conf: controls { inet port 953 allow { localhost } } In questo modo il BIND funziona sulla porta TCP 953. Normalmente il name server non utilizza porta TCP, inoltre i comandi rndc possono essere solo impostati dall host locale. Per poter invece controllare il proprio DNS dalla propria rete locale si potrebbe ad esempio impostare: controls { inet * port 953 allow { localnets } } è anche possibile l'utilizzo di chiavi di accesso: controls { inet * allow { any } keys { "rndc-key" } } Dopo questa direttiva è necessario introdurre la direttiva: key "rndc-key" { algorithm hmac-md5 secret "Zm9vCg==" } Qualora il file named.conf sia leggibile per tutti gli utenti è preferibile nascondere la password (sebbene sia cifrata) all interno do un altro file. Questo può essere referenziato. Ad esempio i named.conf sarà possibile inserire: include /etc/rndc.key Per generare la chiave cifrata si può utilizzare il comando Unix mmencode oppure il tool fornito da BIND chiamato dnssec-keygen. Ad esempio: % mmencode foobarbaz CmZvb2JhcmJh Per utilizzare il comando rndc è necessario creare il file rndc.conf con le direttive più opportune. Ad esempio: options { default-server localhost default-key "rndc-key" } key "rndc-key" { algorithm hmac-md5 secret "Zm9vCg==" dns & bind

38 } In questo modo si evita di introdurre quanto visto fino ad ora nel file named.conf. È possibile gestire server DNS remoti: server localhost { key "rndc-key" } server wormhole.movie.edu { key "wormhole-key" } Ora è possible inviare comandi al server remoto ad esempio % rndc -s wormhole.movie.edu reload Se è stata anche associate una key, sarà necessario specificare anche quest ultima con l'opzione y: % rndc -s wormhole.movie.edu -y rndc-wormhole reload Infine se il server è stato impostato su una porta specifica sarà necessario specificare quest ultima con l opzione p: % rndc -s terminator.movie.edu -p 54 reload Organizzazione e gestione dei file di zona I file di zona possono essere distribuiti in directory diverse e quindi è possibile ad esempio separare i vari domini gestiti dal name server. Inoltre è possibili separare in directory diverse i file primari da quelli secondari. Ad esempio: options { directory "/var/named" } // // These files are not specific to any zone // zone "." { type hint file "db.cache" } zone " in-addr.arpa" { type master file "db " } // // These are our primary zone files // zone "movie.edu" { type master file "primary/db.movie.edu" } zone " in-addr.arpa" { type master file "primary/db " } zone " in-addr.arpa" { type master file "primary/db " } // dns & bind

39 // These are our slave zone files // zone "ora.com" { type slave file "slave/bak.ora.com" masters { } } zone " in-addr.arpa" { type slave file "slave/bak " masters { } } Un altra opportunità è quella di utilizzare la direttiva include: options { directory "/var/named" // // These files are not specific to // zone "." { type hint file "db.cache" } zone " in-addr.arpa" { type master file "db " } include "named.conf.primary" include "named.conf.slave" dove ad esempio il file named.conf.primary potrebbe avere la struttura: // // These are our primary zone files // zone "movie.edu" { type master file "primary/db.movie.edu" } zone " in-addr.arpa" { type master file "primary/db " } zone " in-addr.arpa" { type master file "primary/db " } Le direttive $ORIGIN e $INCLUDE Abbiamo già incontrato la direttiva $ORIGIN. Questa permette di evitare di digitare il dominio all interno dei file di zona. Ad esempio all interno di un file di zona potremmo scrivere: $ORIGIN classics.movie.edu. maltese IN A casablanca IN A $ORIGIN comedy.movie.edu. mash IN A twins IN A dns & bind

40 La direttiva $INCLUDE permette invece di includere file di zona esterni. Ad esempio, combinata con $ORIGIN potrebbe dare origine ad un sintetico file come il seguente: $ORIGIN classics.movie.edu. $INCLUDE db.classics.movie.edu $ORIGIN comedy.movie.edu. $INCLUDE db.comedy.movie.edu Addirittura, in questo caso l'origine può essere specificato come secondo parametro del comando $INCLUDE. Dunque l'esempio precedente può diventare: $INCLUDE db.classics.movie.edu classics.movie.edu. $INCLUDE db.comedy.movie.edu comedy.movie.edu. Le direttive TXT, RP e HINFO È possibile introdurre altri direttive che permettono una migliore gestione delle informazioni contenute nei zone data file. Il resource record TXT permette di introdurre informazioni aggiuntive relative al singolo nodo. Un esempio potrebbe essere il seguente: cujo IN TXT "Location: machine room dog house" oppure ancora, possiamo avere più campi: cujo IN TXT "Location:" "machine room dog house" Il resource record RP permette invece di indicare l address del responsabile della macchina: robocop IN RP root.movie.edu. hotline.movie.edu. IN RP richard.movie.edu. rb.movie.edu. hotline IN TXT "Movie U. Network Hotline, (415) " rb IN TXT "Richard Boisclair, (415) " RP ha due campi, il primo è l' del responsabile dove il è sostituito da un punto, ed il secondo campo punta ad un dominio fittizio. Questo dominio deve avere un corrispondente RR di tipo TXT come riportato nell esempio (hotline e rb), dove vengono aggiunte ulteriori informazioni. Il resource record HINFO, che permette Il logging del BIND Non tratteremo il logging del BIND: Tuttavia è necessario sapere che è possibile personalizzare il jogging indicato nome e locazione dei vari file di log ed inoltre è possibile determinare vari livelli di indicazione di messaggi in base alla loro criticità che sono: critical error warning notice info debug [level] dynamic dns & bind

41 Caratteristiche avanzate del BIND Quanto visto fino ad ora rappresenta le funzionalità di base del BIND. Tuttavia è possibile effettuare configurazioni avanzate. Round Robin Load distribution Tra le caratteristiche avanzate più importanti vi è il cosiddetto round robin. Questo permette di fare in modo che il nome di una macchina, possa presentarsi con indirizzi IP diversi, ogni qualvolta ne venga richiesto l'indirizzo. Gli indirizzi IP con cui si presenta il nome della macchina sono ciclici (di qui il nome round robin) nel senso che vi è un insieme di indirizzi, e raggiunto l'ultimo si riparte dal primo. Supponiamo ora di assegnare gli indirizzi di cui sopra a macchine fisiche diverse. Quando viene richiesto l'indirizzo della macchina, verrà restituito un indirizzo di una macchina fisica e nella richiesta successiva verrà restituito un secondo indirizzo relativo ad una macchina fisica diversa dalla prima, e così via in modo che circolarmente tutte le macchine verranno coinvolte. Ciò permette una distribuzione di carico di lavoro e di traffico tra macchine. Quindi ad esempio un web server potrebbe essere in realtà costituito da più macchine. Ogni qualvolta un browser effettuerà una richiesta di accesso al web server, in realtà verrà inviato su una macchina diversa dalla macchina su cui è stato inviato il browser precedente e così per il browser successivo, ciclicamente. Un esempio di realizzazione è il seguente: foo.bar.baz. 60 IN A foo.bar.baz. 60 IN A foo.bar.baz. 60 IN A Il tempo di permanenza nelle cache dei name server intermedi dell informazione è molto basso (60 secondi). In questo modo se un name server intermedio non supporta il round robin, l'informazione nella cache verrà eliminata in tempi brevi. In questo modo se il name server intermedio ricerca l'indirizzo, il name server autoritativo ha il tempo di effettuare il round robin. Forwarders Qualora si abbiano più name server in gestione, non è necessario che tutti debbano contattare internet per cercare le informazioni. Questo potrebbe essere necessari se i server sono locali e posti ad esempio su una intranet, oppure per svariati motivi non si ha una line dedicata. In questo caso è possibile designare un solo name server ad effettuare ricerche su internet, mentre tutti gli altri demandano a quest ultimo la ricerca. Il nome del name server che effettua le richiesta ed accetta quelle degli altri eventuali name server è forwarder. Su tutti i server escluso il forwarder sarà sufficiente introdurre la seguente configurazione: options { forwarders { } } dove naturalmente gli IP sono quelli dei forwarder, se questi sono più di uno. Esistono ulteriori funzioni che permettono di utilizzare i name server in modalità normale per alcuni domini ed i forwarder per altri domini, ma non analizzeremo queste funzionalità dns & bind