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