Titolo: Alcuni consigli per la gestione del DNS dei domini geografici Italiani di secondo livello Autori: A.B. Bonito D. Vannozzi Data: 29-06-1995 Riferimento: itanetdoc9.txt -------------------------------------------------------------------- Alcuni consigli per la gestione del DNS dei domini geografici Italiani di secondo livello Antonio Blasco Bonito - Daniele Vannozzi Introduzione Scopo di questo breve documento e' dare qualche informazione essenziale per mettere correttamente in opera un Internet nameserver che gestisca in modo automatico gli alias tra domini, ovverosia permetta l'equivalenza completa tra due o piu' domini. Questo metodo puo' essere utilmente applicato alla gestione degli alias per i domini geografici, dove si voglia permettere l'utilizzo sia dei nomi estesi di una entita' geografica, sia il suo alias corto, ed anche ogniqualvolta esistano due o piu' "domini" applicabili allo stesso insieme di oggetti. Si assume che il lettore abbia sufficienti conoscenze riguardo al sistema operativo del sistema sul quale il suo nameserver gira: e' di fatto impossibile per gli autori conoscere le caratteristiche peculiari di tutti i sistemi operativi sui quali si puo' voler installare un nameserver. Si assume anche che il lettore abbia conoscenza delle procedure tecnico/amministrative necessarie per "registrare" il suo dominio in modo tale che il suo nameserver possa essere noto a tutti gli altri nameserver dell'Internet. In caso contrario queste informazioni sono disponibili presso lo IT-NIC, maggiori dettagli possono essere richiesti inviandoi una mail a info@nic.it. Questo documento si concentra quindi nel cercare di chiarire alcuni concetti generali, nel fornire delle linee guida per la gestione del nameserver e nel descrivere nel dettaglio i files di configurazione. Il Domain Name System Il DNS e' un sistema di database distribuito mirato alla gestione delle informazioni dell'insieme di reti TCP/IP interconnesse a livello mondiale; tale insieme di reti e' noto come Internet (con la i maiuscola). I dati gestiti dal DNS sono essenzialmente i nomi e gli indirizzi IP delle macchine connesse alla rete con la loro reciproca corrispondenza. Ogni macchina connessa in rete ha UN SOLO "nome a dominio" (domain-name) ed uno o piu' indirizzi IP. Per ogni macchina ci deve essere una corrispondenza nei due sensi: dal domain-name agli indirizzi (la cosidetta "risoluzione diretta") e da ogni indirizzo al nome (la "risoluzione inversa"). Scopo del DNS e' consentire una gestione distribuita in modo che ogni singolo network manager possa amministrare il suo spazio di nomi ed indirizzi in maniera autonoma ed allo stesso tempo possa avere accesso immediato, attraverso la rete, ai nomi ed indirizzi definiti da tutti gli altri network managers connessi all'Internet. E' necessario quindi uno schema nel quale i nomi abbiano validita' globale. I nomi dei domini Lo spazio dei nomi del DNS e' diviso secondo uno schema gerarchico (ad albero rovesciato) al primo livello del quale si trovano le nazioni, univocamente identificate dalla sigla di due lettere secondo lo standard ISO3166 (es: "it" per l' Italia). Ogni livello e' un dominio: se ci sono livelli inferiori essi costituiscono degli altri domini, chiamati sottodomini o "domini figli" del "dominio padre". Al secondo livello si trovano organizzazioni, enti nazionali, universita', domini geografici, ecc. I nomi si scrivono da sinistra a destra partendo dal livello piu' basso fino al primo livello, separando i vari nomi di dominio con il carattere punto ("."). Un nome che termina con il dominio di primo livello si dice "fully-qualified" o assoluto. La "radice" dell'albero viene identificata dal "dominio vuoto", costituito dal solo "." Esempi di nomi assoluti: aitek.it. L'organizzazione AITEK iac.rm.cnr.it. L'Istituto IAC del CNR a Roma mi.infn.it. La sezione di Milano dell'INFN dm.unipi.it. Il Dipartimento di Matematica dell'Universita' di Pisa firenze.it. Dominio geografico della Provincia di Firenze Gli stessi nomi, senza il "." finale che puo' venire omesso, vengono molto piu' spesso utilizzati negli usi pratici come valori assoluti, ma implicano una serie di operazioni piu' complesse da parte dei "resolver" per il loro utilizzo. Lo spazio dei nomi che parte dalla radice e prosegue con le sigle delle nazioni e cosi' via, e' quello usato per la risoluzione diretta, da nome ad indirizzo. Il domain-name di una macchina connessa in Internet e' composto dal nome semplice della macchina seguito dal nome del dominio di cui fa parte. Ogni macchina puo' appartenere ad un solo dominio ed deve quindi avere UN SOLO domain-name. Puo' avere eventualmente degli alias (CNAME) nello stesso come anche in altri domini. Attenzione: IMPORTANTE, gli alias possono esistere solo per macchine, non per interi domini; e poi ANCHE, i riferimenti ai server nella parte sinistra dei record SOA, NX, MX non possono essere dei CNAME. Nameserver e resolver Gli elementi essenziali per il funzionamento del DNS sono i nameserver ed i resolver. Un nameserver e' un processo costantemente attivo su un computer connesso in rete che e' in grado di ricevere delle interrogazioni via rete, consultare dei files, eventualmente fare a sua volta delle interrogazioni, e generare una risposta. Il resolver e' un pezzo di software (tipicamente una routine del sistema operativo) che genera le interrogazioni verso un nameserver. Il resolver DEVE essere disponibile su ogni macchina connessa in Internet e fa le sue interrogazioni ad uno o piu' nameserver (quelli che il system manager ha specificato nella configurazione della macchina). Non serve avere il nameserver su ogni macchina, e' sufficiente che ce ne siano almeno un paio per ogni dominio. L'implementazione piu' diffusa di nameserver si chiama BIND (Berkeley Internet Name Domain) come dice il suo nome sviluppata alla universita' di Berkeley e poi esportata sulle piu' svariate piattaforme hw/sw. L'ambiente piu' congeniale per BIND e' comunque Unix nelle sue varianti. Esistono "porting" di BIND anche per VMS, DOS, VM, ed altri sistemi operativi. In ambiente Unix l'attivazione del nameserver corrisponde a quella di un processo solitamente chiamato "named" che basa le sue operazioni su un file di configurazione solitamente chiamato "named.boot". Il resolver non ha necessita' di essere attivato (e' solitamente incorporato in routines di sistema i cui nomi tipici sono gethostbyname e gethostbyaddr); ha pero' necessita' di un file di configurazione (solitamente chiamato "resolv.conf") che indica il nome del dominio ed eventualmente gli indirizzi dei nameserver da interrogare. E' opinione degli autori che per gestire correttamente un nameserver e' indispensabile configurare "a mano" i files: sono infatti molti i parametri che entrano in gioco ed occorre che il gestore ne abbia padronanza. Sono ASSOLUTAMENTE DA EVITARE quelle procedure automatiche che partendo da un file "hosts" generano automaticamente i files necessari al funzionamento del BIND. Utilizzo dei nomi estesi e brevi Come gia' anticipato, esistono molti casi in cui sono presenti sia dei nomi estesi che delle sigle abbreviate per delle entita' che si identificano in un dominio. Un caso tipico e' quello dei nomi geografici Italiani che identificano ad esempio le provincie: esistono infatti i nomi estesi ed anche le vecchie sigle automobilistiche a due lettere (Roma = RM) e puo' essere utile avere la possibilita' di utilizzare entrambe le codifiche. Per poter utilizzare indifferentemente i nomi estesi ed abbreviati e' necessario che i due "rami" dell'albero dei domini (nome esteso ed abbreviato) siano uguali. Per poter mantenere questa simmetria si deve agire sul DNS. Con apposite configurazioni che illustriamo in questo documento si puo' infatti utilizzare lo stesso file di definizioni sia per i nomi estesi che per i nomi abbreviati. Notiamo inoltre che tale metodo e' valido per creare delle equivalenze tra domini anche se questi non sono necessariamente un nome breve ed un nome lungo. Ma torniamo al nostro esempio con i nomi geografici. Immaginiamo per semplicita' che il dominio alias si trovi a livello due (provincia.it alias di pr.it) e che a livello tre (xxx.provincia.it alias di xxx.pr.it) ci siano i dati degli oggetti del nostro dominio (hosts, altri sottodomini o una qualsiasi altre informazione che il DNS puo' contenere). Una configurazione simile e' facilmente trasportabile ad una qualsiasi coppia di domini a livello N ed N+1. Per ottenere il nostro risultato e' necessario utilizzare nel file di definizione del dominio SOLTANTO i nomi relativi per i domini geografici di terzo livello, ovverosia quei nomi in cui NON compare il dominio terminato dal punto finale, ma solo la parte variabile a livello tre. Essi erediteranno la parte mancante (dominio geografico di secondo livello) dal file di configurazione del BIND ("named.boot"). In ogni caso e' utile decidere fin dall'inizio il nome "ufficiale" da assegnare a ciascuna macchina (puo' essere sia esteso sia breve). Infatti tale nome sara' poi quello che dovra' essere utilizzato ad esempio nel campo "From:" delle mail originate dagli utenti dei domini geografici, nei file della risoluzione inversa, ecc. L'esempio di riferimento Per facilitare la descrizione delle necessarie configurazioni dei vari files del BIND ci siamo aiutati con un esempio riferito ad un ipotetico dominio geografico di secondo livello provincia.it . L'esempio suppone che i domini geografici di secondo livello provincia.it e pr.it siano gestiti dal nameserver primario sulla macchina figaro.cnuce.cnr.it e che i nameserver secondari di tali domini si trovino sulle macchine dns2.nic.it e nameserver.unipi.it. Inoltre che i domini provincia.it e pr.it abbiano un sottodominio geografico di terzo livello di nome "citta" ("citta.provincia.it" o "citta.pr.it") ed un sottodominio organizzazionale di nome "tribunale" ("tribunale.provincia.it" o tribunale.pr.it"). Sulla macchina (figaro.cnuce.cnr.it) sono residenti i files di configurazione che vengono periodicamente aggiornati, secondo necessita', dal gestore Mario Verdi. Scopo della nostra configurazione e' ottenere l'equivalenza tra ogni domain-name xxx.provincia.it e xxx.pr.it, nonche' tra yyy.citta.provincia.it e yyy.citta.pr.it. I files di configurazione D'ora in poi descrivendo, o inframmezzando commenti ai files di configurazione si fa riferimento a files e directories in un ambiente Unix: per altri ambienti il lettore dovra' fare le necessarie estrapolazioni/traduzioni di terminologia. Per convezione in tutti files utilizzati dal nameserver tutto cio' che segue al carattere ";" sono commenti. Invece le righe di commento degli autori qui inframmezzate sono precedute da il carattere "|". Volendo generare i vostri files a partire da questo esempio occorre eliminare tali righe o sostituire il carattere "|" con il n carattere ";". named.boot | Il file named.boot e' quello che guida l'attivazione del nameserver ed | il caricamento dei dati dagli altri files. E' l'unico file a cui si fa | riferimento implicitamente od esplicitamente quando si attiva il | processo named. Se si usa un riferimento implicito allora questo file | si deve trovare in un directory ben noto: normalmente e' "/etc" ed il | file deve chiamarsi "named.boot". Se si usa un riferimento esplicito | puo'stare dove si vuole e chiamarsi come si vuole. ; Boot file for the domain provincia.it on figaro.cnuce.cnr.it ; rossi@provincia.it 941227 | Queste righe di commento sono utili ad identificare il file ed il suo | gestore (tramite il suo e-mail address) e la data di revisione. ; ; directory where all the data files are stored directory /usr/local/domain | E' utile mettere tutti i files di configurazione del nameserver in un | unico directory ma e' necessario comunicare al processo "named" | qual'e' il "path" dove andarli a cercare. Quindi ogni succesivo | riferimento a nomi di files qui di seguito si intende preceduto dal | path specificato in "directory". ; preferred networks sortlist 193.24.32.0 | Questa riga fa si' che il nameserver, nel fornire una risposta ad una | richiesta di risoluzione diretta, ordini la lista degli indirizzi (se | ce ne e' piu' d'uno) di una macchina mettendo come primo quello che ha | come prefisso la rete specificata. Possono essere specificate piu' | reti per forzare l'ordine nella risposta. | Le righe che seguono ora iniziano con la parola-chiave "primary" che | identifica il nameserver come primario per un certo dominio e fanno | si' che il nameserver carichi in memoria (che viene definita "cache") | i dati necessari partendo da alcuni files. I dati caricati in questo | modo vengono mantenuti sempre validi, fino a quando il processo che li | gestisce non viene reinizializzato. primary 0.0.127.in-addr.arpa named.local | La riga precedente definisce quale e' il file (named.local) che | contiene la definizione dell'interfaccia locale (localhost). primary provincia.it provincia.soa primary pr.it provincia.soa Le due righe precedenti definiscono i domini (provincia.it e pr.it) per cui la macchina figaro.cnuce.cnr.it e' il nameserver primario. I dati necessari al funzionamento dei domini sono indicati nel file provincia.soa ;Root Nameserver cache . root.cache | Questa riga fa si' che il nameserver, nel fornire una risposta ad una | richiesta di risoluzione al di fuori dei due domini sopracitati, | faccia riferimento ai nameserver ("root nameserver") referenziati nel | file root.cache. Questo file e' mantenuto aggiornato da INTERNIC ed e' | disponibile sul server ftp.rs.internic.net (URL completa | ftp://ftp.rs.internic.net/domain/named.root) File provincia.soa | Il file provincia.soa e' quello che contiene tutte le informazioni | necessarie al funzionamento dei due domini provincia.it e pr.it. ;; ;; AUTHORITATIVE DATA FOR: provincia.it, pr.it ;; | Queste righe di commento sono utili ad identificare i domini per cui | tale file e' autoritativo. @ IN SOA figaro.cnuce.cnr.it. postmaster ( 941227 ;file Version # 86400 ;Refresh = 1 day 1800 ;Retry = 30 minutes 2592000 ;Expire = 30 days 172800 ;Default TTL = 2 days ) | Le precedenti sette righe in realta' da un punto di vista logico | corrispondono ad una sola riga. Questa riga infatti e' quella che | contiene il record SOA (Start Of Authority). La sintassi con cui deve | essere scritto questo record deve essere rispettata rigorosamente. In | particolare nella stringa che segue "SOA" (es: figaro.cnuce.cnr.it) | DEVE essere indicato il nome reale (unico ed univoco) della macchina | su cui e' attivo il nameserver (e' fortemente sconsigliato l'utilizzo | di alias per il nome della macchina). La stringa successiva | (es:postmaster) indica l'indirizzo di Posta Elettronica della persona | incaricata del mantenimento delle informazioni contenute nel file | stesso. E' da notare che in questo esempio non compare volutamente | l'indirizzo assoluto (es:postmaster.provincia.it.) proprio per poter | ereditare tali dati dal file named.boot. | I tag successivi indicano rispettivamente la versione di file, | elemento determinante per un corretto funzionamento ed allineamento | dei nameserver secondari, il secondo tag (refresh) indica l'intervallo | di tempo con cui il nameserver secondario andra' a verificare se vi | sono stati dei cambiamenti nel file (il controllo avviene sul valore | del "file Version") Il terzo tag (Retry) indica l'intervallo di tempo | con cui il nameserver secondario andra' a ricontattare il nameserver | primario in caso di sua irrangiungibilita'. Il quarto tag (Expire) | indica l'intervallo di tempo per cui il nameserver secondario riterra' | valida l'informazione prelevata dal nameserver primario. Il quinto tag | (Default TTL) indica il tempo per cui le informazioni contenute nei | singoli record del file (es: provincia.soa), che non hanno un TTL | esplicito, rimarranno valide. I valori dei vari tag indicati | nell'esempio sono quelli che normalmente vengono consigliati ed | utilizzati dagli esperti del settore. ;; ;; AUTHORITATIVE NAME SERVERS FOR THIS DOMAIN: TTL is 1 week ;; @ 604800 NS figaro.cnuce.cnr.it. @ 604800 NS dns2.nic.it. @ 604800 NS nameserver.unipi.it. | I tre record NS precedenti indicano quali sono i nameserver | "autoritativi" per tale dominio. Con nameserver autoritativi si DEVONO | intendere il nameserver primario e tutti i nameserver secondari per il | dominio. ;; MAILERS AND MAIL-FORWARDERS FOR THIS DOMAIN: TTL is 3 days @ 269200 IN MX 20 vm.cnuce.cnr.it. | Il record precedente (MX) agisce su tutte le mail indirizzate a | @provincia.it o @pr.it. In particolare i record MX | (Mail Exchanger) hanno la funzione di dirigere le mail verso una | determinata macchina che si fara' poi carico della distribuzione | finale al singolo utente. L'utilizzo di questo record MX valido a | livello di dominio e' fondamentale per la raggiungibilita' | dell'indirizzo postmaster@ o postmaster@ previsto | dallo RFC1123 e dallo RFC822. ;; STANDARD STUFF: TTL is 1 week localhost 604800 IN A 127.0.0.1 loopback 604800 IN CNAME localhost loopback-host 604800 IN CNAME localhost | Le tre righe precedenti sono indispensabili per il corretto | funzionamento dell'indirizzo "speciale" localhost. Tale indirizzo e' | utilizzato dal nameserver per indirizzare il traffico verso se stesso. ;; ;; Delegation to subdomains ;; ;; Comune di Citta ;; citta 86400 NS ns.citta.provincia.it. 86400 NS figaro.cnuce.cnr.it. | E' IMPORTANTE prestare attenzione nella definizione delle deleghe per | i domini geografici di terzo livello all'utilizzo dei nomi relativi ed | assoluti (con il "." finale). Come si puo' vedere dalle tre righe | precedenti, la delega per il dominio relativo citta, per avere due | nomi assoluti e' stata e DEVE essere fatta utilizzando i nomi | relativi nella parte sinistra del record NS. Mentre per le macchine | che svolgono la funzione di nameserver per quel dominio (record NS) e' | NECESSARIO utilizzare i nomi assoluti (parte destra del record NS) . ;; ;; Delegate Mail Routing Service for Subdomains ;; (Those without a domain name server). ;; ;; Tribunale ;; tribunale IN MX 10 mailserver.provider.it. | La riga precedente definisce, sempre con nome relativo, i dati del | dominio "tribunale". Ad esso corrisponderanno due nomi effettivamente | utilizzabili, sia | | tribunale.provincia.it | | che | | tribunale.pr.it | | automaticamente. Lo stesso tipo di configurazione con nome relativo | deve essere utilizzata nel file che conterra' gli host del dominio di | livello 3 citta.provincia.it. File named.local | Questo e' il file named.local, il nameserver ha bisogno di esso per | effettuare il "loopback" (e' lo speciale indirizzo usato dalle | macchine per mandare traffico a loro stesse. Questa rete e' | normalmente la 127.0.0.0 e l'indirizzo della macchina e' normalmente | il 127.0.0.1. @ IN SOA figaro.cnuce.cnr.it. postmaster ( 941227 ;file Version # 10800 ;Refresh = 3 hours 3600 ;Retry = 1 hours 604800 ;Expire = 1 weeks 86400 ;Default TTL = 1 day ) @ IN NS figaro.cnuce.cnr.it. 1.0.0.127.in-addr.arpa IN PTR localhost. | La riga precedente e' quella che definisce la "risoluzione inversa" | per l'indirizzo 127.0.0.1 | NOTA IMPORTANTE: la risoluzione inversa, realizzata con i record PTR, | puo' puntare SOLO AD UNO dei possibilia domain alias realizzati: in | pratica ad un indirizzo puo' venir fatto corrispondere SOLO un | domain-name che a scelta puo' essere nel dominio pr.it oppure | provincia.it (nel nostro esempio). | Non e' infatti ovviamente possibile avere una risoluzione inversa | ambigua, che dia cioe' sia xxx.provincia.it che xxx.pr.it | Per quanto detto precedentemente e' bene mantenere una omogeneita' | nella risoluzione inversa dei nomi degli host appartenenti a | sottodomini dei domini geografici di secondo livello con quanto fatto | per il dominio geografico di secondo livello. | Suggeriamo di usare, in quanto piu' comprensibili anche agli | stranieri, i nomi estesi come "nomi ufficiali" e di specificare essi | sia nella parte destra dei record NS o MX che nei record PTR per la | risoluzione inversa. Appendice A Qui di seguito sono riportate le informazioni che dovrebbe contenere gli ipotetici moduli di registrazione dei domini provincia.it e pr.it domain: provincia.it x400-domain: c=it; admd= ; prmd=provincia; org: Province of Provincia - Locality Domain descr: Geographical Italian Second Level Domain admin-c: ST43-RIPE tech-c: DV73 postmaster: DV73 zone-c: DV73 nserver: 131.114.192.100 figaro.cnuce.cnr.it nserver: 193.205.245.8 dns2.nic.it nserver: 131.114.21.10 nameserver.unipi.it remarks: Delegated to pippo.it dom-net: 193.204.1.0 changed: rossi@provincia.it 941227 source: GARR-NIS domain: pr.it x400-domain: c=it; admd= ; prmd=pr; org: Province of Provincia - Locality Domain descr: Geographical Italian Second Level Domain admin-c: ST43-RIPE tech-c: DV73 postmaster: DV73 zone-c: DV73 nserver: 131.114.192.100 figaro.cnuce.cnr.it nserver: 193.205.245.8 dns2.nic.it nserver: 131.114.21.10 nameserver.unipi.it remarks: Delegated to pippo.it dom-net: 193.204.1.0 changed: rossi@provincia.it 941227 source: GARR-NIS