Servizi Internet di base

Presentazione sul tema: "Servizi Internet di base"— Transcript della presentazione:

1 Servizi Internet di base
Filippo Castiglione, IAC – CNR, Roma Servizi Internet di base Domain Name System F. Castiglione

2 Argomenti F. Castiglione

3 Argomenti F. Castiglione

4 Breve storia Gli indirizzi IP sono difficili da ricordare: vanno bene per la comunicazione tra le macchine Ä modello centralizzato: agli albori di Internet l’associazione tra indirizzo IP e nomi delle macchine era registrata nel file HOSTS.TXT mantenuto presso SRI-NIC (Arpanet) (che veniva scaricato con FTP da tutti gli host [RFC-952, RFC- 953]) § traffico e sovraccarico del server centrale § collisioni dei nomi § consistenza dei dati gestiti centralmente Ä modello distribuito: all’inizio degli anni ‘80, l’aumento del numero degli host ha reso indispensabile l’adozione di un modello di gestione distribuita denominato Domain Name System (il sistema dei nomi di dominio) F. Castiglione

5 F. Castiglione

6 Breve storia – RFC di riferimento
Il “Domain Name System” Ä Creato nel 1983 da Paul Mockapetris (RFCs 1034 e 1035), modificato, aggiornato e migliorato da una miriade di successive RFCs Ä Domain Name System (DNS) § definito presso ISI - USC 1984 § RFC 882, RFC 883, RFC 973 (obsolete) § RFC 1034, RFC 1035, RFC 1123, RFC 1537, RFC 1912 F. Castiglione

7 Sono necessari: Le funzioni
Ä ad ogni risorsa TCP/IP può essere assegnato un nome simbolico Sono necessari: § un metodo per associare al nome simbolico di una macchina l’indirizzo (o gli indirizzi) IP: risoluzione diretta § un metodo per associare ad un indirizzo IP il nome simbolico della macchina: risoluzione inversa diretta inversa F. Castiglione

8 Caratteristiche principali
Il DNS permette ad ogni organizzazione che ha accesso ad Internet di: Ä amministrare la relazione tra nomi ed indirizzi del proprio dominio in maniera autonoma ed indipendente Ä risolvere i nomi fuori del proprio dominio accedendo alle informazioni gestite da altre organizzazioni F. Castiglione

9 Caratteristiche principali
database distribuito basato sul modello client/server Ä tre componenti principali: § spazio dei nomi e informazioni associate (Resource Record - RR) § nameserver (application server che mantiene i dati) § resolver (client per l’interrogazione del nameserver) Ä accesso veloce ai dati (database in memoria centrale e meccanismo di caching) F. Castiglione

10 Ä Lo spazio dei nomi è organizzato secondo un modello gerarchico:
§ il database del DNS ha una struttura logica “ad albero rovesciato” § ciascun nodo dell’albero rappresenta un dominio § ogni dominio può essere suddiviso in altri domini: sottodomini § ogni nodo ha una etichetta che lo identifica rispetto al padre Ä La radice dell'albero è unica, e la sua etichetta è vuota. In certi casi si indica anche come “.” Ä La struttura dello spazio dei nomi: § domini generali (gTLD, general Top Level Domain) § domini nazionali (ccTLD) § domini per la risoluzione inversa (arpa) F. Castiglione

11 L’internet Domain Name Space
lo spazio dei nomi di Internet, per “tradizione” (RFC1591), è strutturato secondo un modello misto organizzazionale/geografico i Top-Level-Domain sono § domini generali “storici” di tipo organizzazionale (gTLD): com: organizzazioni commerciali edu: università e ricerca USA gov: organizzazioni governative USA mil: organizzazioni militari USA net: provider, centri di interesse per l’Internet, .. org: organizzazioni non governative int: organizzazioni internazionali, trattati, ... § domini nazionali, rappresentati dai codici ISO3166 di 2 lettere (ccTLD) § il dominio arpa § nuovi domini in corso di attivazione: .info, .museum, … F. Castiglione

12 § domini nazionali, rappresentati dai codici ISO 3166 di 2 lettere
Top Level Domains § domini nazionali, rappresentati dai codici ISO 3166 di 2 lettere (ccTLD) ( § Il dominio .arpa (Address and Routing Parameter Area) viene usato solo per scopi di gestione dell’Internet-infrastructure. § I nuovi gTLD operativi sono: § .biz: businesses (e.g. § .info: generale (e.g. § .museum: musei (e.g. § .name: persone (e.g. § I nuovi gTLD in corso di attivazione: § .aero: compagnie aeree § .coop: cooperative § .pro: professioni Esercizio: visitare il sito di IANA (Internet Assigned Number Authority) F. Castiglione

13 Visione d’insieme: esempio

14 L’albero dei nomi Ä il “domain name” di ogni nodo è composto dalla sequenza delle etichette dal nodo a “ “ (root), separate da “.” (punto). Es: e.c.a, oppure h.g.f.d.b Ä un nome a dominio assoluto è detto anche “fully-qualified domain name” o FQDN Ä il ”Distributed Information Tree” (albero dei nomi) definisce una gerarchia dei nomi che rende ogni nome a dominio completamente qualificato univoco in tutto l’albero F. Castiglione

15 Esempio ‘‘ ’’ root F. Castiglione 3 3

16 Esempio ‘‘ ’’ root Top Level Domains info com uk F. Castiglione 3 3

17 ‘‘ ’’ info com uk ceu hotels co ac ibm bt Esempio root
Top Level Domains info com uk ceu hotels First Level Domains co ac ibm bt F. Castiglione 3 3

18 ‘‘ ’’ info com uk ceu hotels co ac ibm bt mpglaw rf.mpglaw.co.uk sysa
Esempio ‘‘ ’’ root Top Level Domains info com uk ceu hotels First Level Domains co ac ibm bt mpglaw rf.mpglaw.co.uk sysa sysb F. Castiglione 3 3

19 I domini § entry di host § entry strutturali
Ä per dominio si intende il sottoalbero che inizia dal nodo con il domain name in questione Ä di solito, le foglie rappresentano il domain name di un host Ä ai nodi sono associate le informazioni relative a quel nome a dominio (RR=resource record) § entry di host § entry strutturali F. Castiglione

20 La delega di autorita` (le zone)
Il DNS permette a organizzazioni dotate di un proprio dominio di: § amministrare la relazione nomi-indirizzi del proprio dominio in maniera autonoma ed indipendente § definire le regole di naming all’interno del proprio dominio § delegare ad altri la gestione degli eventuali domini figli (sotto-domini) § risolvere i nomi fuori del proprio dominio accedendo alle informazioni gestite da altre organizzazioni Ä la decentralizzazione della responsabilità amministrativa è ottenuta attraverso il meccanismo della delega Ä il gestore del dominio “.” è InterNIC (per conto dello IANA/ICANN), che delega l’autorità per la gestione dei TLD Esercizio: leggere F. Castiglione

21

22 Esempio: distribuzione dell’autorita` (le zone)
‘‘.’’ gestito da IANA/ICANN info com uk ceu hotels co ac ibm bt mpglaw rf.mpglaw.co.uk sysa sysb F. Castiglione 3 3

23 Esempio: distribuzione dell’autorita` (le zone)
gestito da Nominet gestito da IANA/ICANN ‘‘ ’’ info com uk ceu hotels co ac ibm bt mpglaw gestito da NSI rf.mpglaw.co.uk sysa sysb F. Castiglione 3 3

24 Esempio: distribuzione dell’autorita` (le zone)
gestito da Nominet gestito da IANA/ICANN ‘‘ ’’ info com uk ceu hotels co ac ibm bt mpglaw gestito da NSI rf.mpglaw.co.uk sysa sysb gestito da Manches F. Castiglione 3 3

25 Domini e zone: differenze
Ä le informazioni sono mantenute nei nameserver Ä un nameserver mantiene i dati di un sottoinsieme dello spazio dei nomi: la zona Ä ogni zona può essere un sottodominio completo, cioè comprendere vari domini su una porzione del DIT (Directory Information Tree) non disgiunta Ä un nameserver può gestire più zone disgiunte Ä il dominio padre contiene solo puntatori alla sorgente dei dati dei suoi sottodomini § ciascuna zona contiene i nomi a dominio e i dati appartenenti ad certo dominio, esclusi i nomi e i dati dei sottodomini delegati ad altri F. Castiglione

26 Divisione in zone: esempio

27 Domini e zone: I nameservers
Ä la struttura gerarchica dello spazio dei nomi si riflette nella relazione tra i nameserver Ä il meccanismo della delega di autorità si basa sui seguenti principi: § ogni nameserver di un dominio, per essere conosciuto nel DNS, deve essere stato registrato dal nameserver del dominio di livello superiore. Questo crea la delega § una volta delegata l'autorità su una zona il nameserver “padre” perde ogni possibilità di modificare le informazioni dei domini contenuti nella zona delegata § i nameserver delegati possono essere più d'uno (è consigliato averne almeno due, in alcuni casi è addirittura obbligatorio), ma uno solo è quello che possiede la vera autorità perché gestisce i files contenenti le informazioni F. Castiglione

28 Il “parenting” ovvero la creazione di sottodomini
Quando conviene? Dipende da varie considerazioni: § necessità di definire sottodomini per partizionare uno spazio dei nomi piatto e molto esteso § necessità di distinguere l’affiliazione delle macchine di un dominio § necessità di distribuire la gestione Ä quanti sottodomini definire? Ä quando delegarne la gestione? Ä che nome assegnare ai sottodomini? Attenzione alla corretta gestione del meccanismo della delega per garantire la risoluzione dei nomi per tutto il dominio!! F. Castiglione

29 Esercizio: ftp://ftp.rs.internic.net/domain/named.root
I root-servers Ä i root-server sono i nameserver della “.“ (radice). Ä sono essenziali al funzionamento del DNS perchè: § contengono le informazioni sui Top-Level-Domain e sui relativi nameserver ai quali ne delegano la gestione § contengono le informazioni per la risoluzione inversa (risoluzione indirizzo-nome) ogni nameserver deve conoscere nomi ed indirizzi dei root-server Ä la lista aggiornata dei root-server è mantenuta da InterNIC § ftp://ftp.rs.internic.net/domain/named.root § ftp://ftp.nic.it/pub/DNS/named.root Esercizio: ftp://ftp.rs.internic.net/domain/named.root F. Castiglione

30 Root Name Server Operators
Operated by: A Verisign (US East Coast) B University of S. California –Information Sciences Institute (US West Coast) C PSI (US East Coast) D University of Maryland (US East Coast) E NASA (Ames) (US West Coast) F Internet Software Consortium (US West Coast) G U. S. Dept. of Defense (ARL) (US East Coast) H U. S. Dept. of Defense (DISA) (US East Coast) I KTH (SE) J K RIPE-NCC (UK) L ICANN (US West Coast) M WIDE (JP)

31 Il processo di risoluzione
Il processo di risoluzione dei nomi a dominio è basato sul modello clientserver: Ä il nameserver (server) è un processo che ha il compito di fornire “risposte autoritative” ad interrogazioni sui nomi definiti nell’ambito dei domini per cui è autoritativo; il resolver (client) è invece utilizzato dalle applicazioni che hanno necessità di effettuare una risoluzione di nomi a dominio. Esso è costituito da un insieme di routine di libreria (es. gethostbyname) che sono in grado di colloquiare con i nameserver, interpretarne le risposte e restituire l’informazione al programma richiedente. E’ possibile configurare il default domain di appartenenza, la lista dei nameserver da interrogare e la search list in un apposito file di configurazione (es. file /etc/resolv.conf su Unix) F. Castiglione

32 Il processo di risoluzione dei nomi
Ä Se il nome desiderato non è nella zona (o nella cache) del NS interrogato, si innesca il processo di risoluzione dei nomi Ä La richiesta di risoluzione risale il DIT (Directory Information Tree) fino alla radice e lo ridiscende fino ad arrivare ad un NS autoritativo la cui zona contiene il nome in questione e quindi anche i RR (resource record) Ä La risposta, opportunamente salvata in tutte le cache intermedie, viene infine passata dal resolver all’utente che aveva effettuato la richiesta Ä 2 modalità di risoluzione dei nomi: § ricorsiva (il resolver chiede al nameserver; il nameserver pensa a tutto) § iterativa (il resolver si rivolge direttamente ai vari nameservers della catena) F. Castiglione

33 Il processo di risoluzione dei nomi

34 Nameserver autoritativi
Ä un nameserver si definisce autoritativo quando è “in possesso dei dati” per una determinata zona dell’albero dei nomi Ä per un dominio vi possono essere più nameserver autoritativi § per avere una maggiore affidabilità è fortemente consigliato averne più di uno, localizzati in modo da ridurre il rischio di interruzione del servizio DNS Ä i nameserver autoritativi si dividono in: § primari § secondari F. Castiglione

35 Nameserver autoritativi primari e secondari
Ä Un nameserver si definisce primario quando possiede i file delle informazioni (“file di zona”) e pertanto in ogni zona vi sarà un solo nameserver primario Ä Un nameserver si definisce secondario quando acquisisce, dal nameserver primario, i dati relativi alla zona mediante una procedura automatica denominata “zone-transfer” § i parametri che regolano il funzionamento della procedura di zone-transfer sono contenuti in uno specifico record del nameserver primario (record SOA) procedura: /usr/dns/etc/named-xfer -z domname -f outputfile authNS Ä è necessario valutare attentamente il numero e la dislocazione dei nameserver secondari in modo da ridurre il più possibile il rischio che problemi di connessione possano impedire la risoluzione dei nomi di un dominio F. Castiglione

36 Perché avere più server DNS?
Ä Ci sono tre ragioni per avere dei server secondari: § Ridondanza § Locazioni differenti § Riduzione del carico sul primario Ä Ridondanza § Sono necessari almeno due nameservers per ogni zona, un primario ed almeno un secondario per ridondanza. Come ogni fault tolerant system, le macchine devono essere il più indipendenti possibile (e.g su reti differenti). Ä Locazioni differenti § I secondary servers devono risiedere in locazioni differenti per poter gestire un alto numero di utenti (i.e. per evitare che gli utenti debbano comunicare su linee a bassa velocità). Ä Riduzione del carico sul primario § I name server secondary servono (ovviamente) anche per ridurre il carico di lavoro sul primary server.

37 Caching Ä ogni nameserver mantiene copia di tutte le informazioni di cui è venuto a conoscenza Ä tali informazioni sono utilizzate durante il processo di risoluzione dei nomi Ä le risposte date dal nameserver sulla base della cache sono “not authoritative” Ä le informazioni nella cache di un nameserver rimangono valide per un tempo limitato (Time-To-Live, TTL) L’uso della cache può dare luogo a “temporanee” inconsistenze ma aumenta le performance del sistema F. Castiglione

38 Come funziona il meccanismo di DNS caching?
La cache risiede su disco o in memoria centrale? I record della cache sono memorizzati nel segmento dati del processo name-server in memoria centrale. Quindi la cache viene persa se il processo viene terminato. Per quanto tempo viene mantenuta l’informazione nella cache? Ogni DNS resource record in risposta ad una query, contiene un valore “time to live” (TTL) che determina per quanto tempo il server può tenere quel record in cache. Un valore tipico è secondi (24 hours). C’è un limite massimo per la cache? La cache cresce senza limitazioni, specialmente su servers molto importanti, dove nuovi records vengono messi in cache ad una velocità superiore rispetto a quelli a cui scade il TTL. Sui sistemi UNIX, il processo name server finirà per raggiungere la sua massima dimensione in memoria e verrà terminato dal kernel di sistema. E’ quindi una buona idea schedulare un “cron job” che lo termina e lo fa ripartire settimanalmente.

39 L’albero per la risoluzione inversa (in-addr.arpa)
indirizzo nome § in-addr.arpa dominio § in-addr.arpa sotto-dominio § in-addr.arpa macchina Resource record = F. Castiglione

40 Esempio: risoluzione dei nomi (ricorsiva)
Il processo di risoluzione dei nomi step-by-step: annie.west.sprockets.com ping F. Castiglione

41 The Resolution Process
La workstation annie chiede al suo name-server (quello configurato), dakota, l’indirizzo di dakota.west.com What’s the IP address of annie.west.com ping F. Castiglione

42 The Resolution Process
Il name-server dakota chiede al root-name-server, m, l’indirizzo di m.root-servers.net dakota.west.com What’s the IP address of annie.west.com ping F. Castiglione

43 The Resolution Process
Il root-server m riferisce a dakota il nome dei name-server com Questo tipo di risposta si chiama un “referral” m.root-servers.net dakota.west.com Here’s a list of the com name servers. Ask one of them. annie.west.com ping F. Castiglione

44 The Resolution Process
Il name-server dakota chiede al name-server com, f, l’indirizzo di What’s the IP address of m.root-servers.net dakota.west.com f.gtld-servers.net annie.west.com ping F. Castiglione

45 The Resolution Process
Il name-server com, f, riferisce a dakota il nome del name-server di nominum.com Here’s a list of the nominum.com name servers. Ask one of them. m.root-servers.net dakota.west.com f.gtld-servers.net annie.west.com ping F. Castiglione

46 The Resolution Process
Il name-server dakota chiede ad uno dei server nominum.com, ns1.sanjose, l’indirizzo di What’s the IP address of m.root-servers.net dakota.west.com ns1.sanjose.nominum.net f.gtld-servers.net annie.west.com ping F. Castiglione

47 The Resolution Process
Il name-server nominum.com, ns1.sanjose, risponde con l’indirizzo di m.root-servers.net dakota.west.com Here’s the IP address for ns1.sanjose.nominum.net f.gtld-servers.net annie.west.com ping F. Castiglione

48 The Resolution Process
Il name-server dakota risponde ad annie con l’indirizzo di Here’s the IP address for m.root-servers.net dakota.west.com ns1.sanjose.nominum.net f.gtld-servers.net annie.west.com ping F. Castiglione

49 Resolution Process (Caching)
Dopo la query precedente, il name-server dakota conosce: I nomi e gli indirizzi IP dei name-servers com I nomi e gli indirizzi IP dei name-servers nominum.com L’indirizzo IP di Rivediamo il processo di risoluzione annie.west.com ping ftp.nominum.com. F. Castiglione

50 Resolution Process (Caching)
La workstation annie chiede al suo name-server, dakota, dell’indirizzo ftp.nominum.com m.root-servers.net dakota.west.com What’s the IP address of ftp.nominum.com? ns1.sanjose.nominum.net f.gtld-servers.net annie.west.com ping ftp.nominum.com. F. Castiglione

51 Resolution Process (Caching)
dakota ha memorizzato nella cache un record NS che indica che ns1.sanjose e` un name-server nominum.com, quindi gli chiede l’indirizzo di ftp.nominum.com What’s the IP address of ftp.nominum.com? m.root-servers.net dakota.west.com ns1.sanjose.nominum.net f.gtld-servers.net annie.west.com ping ftp.nominum.com. F. Castiglione

52 Resolution Process (Caching)
Il name-server di nominum.com, ns1.sanjose, risponde con l’indirizzo di ftp.nominum.com m.root-servers.net dakota.west.com Here’s the IP address for ftp.nominum.com ns1.sanjose.nominum.net f.gtld-servers.net annie.west.com ping ftp.nominum.com. F. Castiglione

53 Resolution Process (Caching)
Il name-server dakota risponde alla workstation annie con l’indirizzo di ftp.nominum.com Here’s the IP address for ftp.nominum.com m.root-servers.net dakota.west.com ns1.sanjose.nominum.net f.gtld-servers.net annie.west.com ping ftp.nominum.com. F. Castiglione

54 Servizi Internet di base
Domain Name System BIND = Berkeley Internet Name Domain F. Castiglione

55 Piattaforme HW/SW Ä hardware § disponibile su quasi tutte le attuali piattaforme (PC, Macintosh, workstation, mainframe) Ä software § prodotti di pubblico dominio (BIND per Unix e WinNT/Win95, MIND/NonSequitur per MacOS) § prodotti commerciali (MacDNS, QuickDNS Pro, distribuzione di WinNT server 4.0) F. Castiglione

56 BIND (Berkeley Internet Name Domain)
§ è l’implementazione di nameserver più diffusa su Internet § sviluppata per Unix BSD, ne esistono porting per molti altri ambienti § spesso ne è inclusa una implementazione nel software di corredo di piattaforme Unix § vi sono attualmente tre versioni: § la versione “storica” 4.x.y (l’ultima rilasciata è la 4.9.7) § la versione 8.x.y (l’ultima rilasciata è la P7) § la versione 9.x.y, ancora in fase di evoluzione ( F. Castiglione

57 Le versioni (4.x.y) e (8.x.y): differenze e similitudine
File di configurazione § named.boot (4.x.y) § formato ormai in uso da anni § consente solo alcune “personalizzazioni” generali § named.conf (8.x.y) § nuovo formato (stile linguaggio c) § funziona con IPv6 ( § consente una personalizzazione completa sia generale che zona per zona Ä Esiste una procedura in perl (named-bootconf.pl) per la conversione dal formato 4.x.y al formato 8.x.y rimangono inalterati i file delle singole zone F. Castiglione

58 Nuove funzionalita` della versione 8.x.y
Ä meccanismo del notify § permette l’aggiornamento quasi in tempo reale tra nameserver primario e secondari Ä meccanismo di logging flessibile e personalizzabile, senza uso obbligato del logging del sistema (syslog) Ä controllo degli accessi personalizzabile per zona Ä migliore ottimizzazione della memoria centrale § migliora notevolmente le prestazioni del servizio, specialmente per implementazioni con molte zone attive sulla stessa macchina Ä numero max di zone incrementato a (232) Ä supporto iniziale di DNSSEC Ä supporto di WindowsNT Ä update dinamico (NSUPDATE) e incrementale (IXFR) F. Castiglione

59 Caratteristiche salienti di BIND 9
Ä Versione corrente (rilasciata il 26 novembre 2001!!!) Ä Miglioramento delle funzionalità di update dinamico Ä Supporto per zone di elevate dimensioni (.com) Ä Miglioramento funzionalità DNSSec/TSIG Ä Miglioramento funzionalità IXFR Ä Views Ä RNDC - Remote Named Daemon Control F. Castiglione

60 Ä il file named.boot/named.conf Ä il file named.local
I file necessari Ä il file named.boot/named.conf Ä il file named.local Ä il file named.root Ä i file per la risoluzione diretta Ä i file per la risoluzione inversa F. Castiglione

61 § definisce i riferimenti ai root nameserver (cache)
Il file named.boot Il file named.boot è il file di configurazione principale per il funzionamento del processo nameserver nella versione 4.x.y § definisce la directory in cui si trovano gli altri file necessari al funzionamento del nameserver (directory) § definisce l’ordine con cui verranno restituiti gli indirizzi delle singole macchine (sortlist) § definisce quali sono i nameserver che possono prelevare le zone per cui il nameserver è autoritativo (xfernets) § definisce l’interfaccia locale della macchina su cui il processo nameserver è attivo § definisce i domini per i quali il nameserver è autoritativo (primary e secondary) § definisce i riferimenti ai root nameserver (cache) F. Castiglione

62 Il file named.conf il file named.conf è il file di configurazione principale per il funzionamento del processo nameserver dalla versione 8.x.y § definisce la directory in cui si trovano gli altri file necessari al funzionamento del nameserver (directory) § definisce la raccolta dei dati statistici relativi al processo nameserver (statistics-interval) § definisce l’ordine con cui verranno restituiti gli indirizzi delle singole macchine (topology) § definisce quali sono i nameserver che possono prelevare le zone per cui il nameserver è autoritativo (allow-transfer) § definisce il livello e la distribuzione dei “log” prodotti dal processo nameserver senza dover necessariamente il syslog del sistema (logging/channel/category) § definisce l’interfaccia locale della macchina su cui il processo nameserver è attivo § definisce i domini per i quali il nameserver è autoritativo (master e slave) § definisce i riferimenti ai root nameserver (hint) F. Castiglione

63 Esempio di file named.local
Il nameserver ha bisogno di questo file per utilizzare il loopback. Per convenzione questa rete è la e l'indirizzo della macchina è il Un esempio di file named.local: @ IN SOA nameserver.cnr.it. dns-adm.nameserver.cnr.it ( ;file Version # 86400 ;Refresh = 1 day 1800 ;Retry = 30 minutes ;Expire = 6 days 86400 ;Default TTL = 1 day ) @ IN NS nameserver.cnr.it. in-addr.arpa. IN PTR localhost. F. Castiglione

64 Utility di supporto nella gestione di un nameserver
Ä nslookup Ä host Ä dig Ä dnswalk Ä ndc Ä nsupdate L’RFC 1713 descrive un insieme di tools che possono essere utili per il debugging della configurazione di un nameserver F. Castiglione

65 Ä dispone di aiuto in linea
nslookup Ä è normalmente distribuito insieme al S.O. o alla distribuzione di BIND Ä si può utilizzare sia in modalità interattiva che tramite riga di comando Ä dispone di aiuto in linea filippo[132]->nslookup set query=any Server: Address: #53 Non-authoritative answer: canonical name = silos.iac.rm.cnr.it. Authoritative answers can be found from: iac.cnr.it nameserver = nameserver.cnr.it. iac.cnr.it nameserver = silos.rm.iac.cnr.it. nameserver.cnr.it internet address = silos.rm.iac.cnr.it internet address = F. Castiglione

66 Query per tutti i record del
nslookup filippo[133]-> nslookup Server: Address: #53 set query=any cnr.it Non-authoritative answer: cnr.it nameserver = dns3.nic.it. cnr.it nameserver = pdadr1.pd.cnr.it. cnr.it nameserver = dns.cnr.it. origin = dns.cnr.it. mail addr = m.astolfi.src.cnr.it. serial = refresh = 86400 retry = 3600 expire = minimum = 86400 cnr.it nameserver = dns2.cnr.it. Authoritative answers can be found from: dns3.nic.it internet address = pdadr1.pd.cnr.it internet address = dns.cnr.it internet address = dns2.cnr.it internet address = Query per tutti i record del dominio cnr.it F. Castiglione

67 ftp://ftp.nikhef.nl/pub/network/host.tar.Z
Ä è incluso nella distribuzione di BIND ed è inoltre reperibile presso: ftp://ftp.nikhef.nl/pub/network/host.tar.Z Ä non è interattivo: si utilizza da linea di comando Ä permette di fare interrogazioni complesse a qualsiasi nameserver Ä è dotato di aiuto in linea host host -i host -av cnr.it nameserver.cnr.it host -avl cnr.it nameserver.cnr.it host -t soa cnr.it host -C cnr.it F. Castiglione

68 Ä Query per tutti i record del dominio cnr.it
host Ä Query per tutti i record del dominio cnr.it filippo[137]-> host -va cnr.it Query about cnr.it for record types ANY Trying cnr.it ... Query done, 6 answers, status: no error The following answer is not authoritative: cnr.it IN NS nameserver.cnr.it cnr.it IN NS dns2.nic.it cnr.it IN NS itgbox.iat.cnr.it cnr.it IN NS simon.cs.cornell.edu cnr.it IN NS ns1.surfnet.nl cnr.it IN SOA nameserver.cnr.it Daniele\.Vannozzi.iat.cnr.it ( ;serial (version) 86400 ;refresh period (1 day) 1800 ;retry interval (30 minutes) ;expire time (1 week) 86400 ;default ttl (1 day) ) …… F. Castiglione

69 host filippo[137]->host -C ba.cnr.it
ba.cnr.it NS nameserver.cnr.it dns.ba.cnr.it postmaster.dns.ba.cnr.it ( ) ba.cnr.it NS dns.ba.cnr.it dns.ba.cnr.it postmaster.dns.ba.cnr.it ( ) !!! dns.ba.cnr.it has different serial than nameserver.cnr.it ba.cnr.it NS area.area.ba.cnr.it dns.ba.cnr.it postmaster.dns.ba.cnr.it F. Castiglione

70 qualsiasi nameserver dig Ä è incluso nella distribuzione di BIND
Ä non è interattivo; si utilizza da linea di comando Ä permette di fare interrogazioni complesse ed a qualsiasi nameserver Ä è dotato di aiuto in linea dig -h dig dns.iat.cnr.it dig dns.iat.cnr.it mx dig -x cnr.it F. Castiglione

71 Ä Query per tutti i record del dominio cnr.it
dig Ä Query per tutti i record del dominio cnr.it filippo[137]->dig cnr.it ; <<>> DiG <<>> cnr.it ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 31784 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 ;; QUESTION SECTION: ;cnr.it IN A ;; AUTHORITY SECTION: cnr.it IN SOA dns.cnr.it. m.astolfi.src.cnr.it ;; Query time: 11 msec ;; SERVER: #53( ) ;; WHEN: Wed Aug 20 17:20: ;; MSG SIZE rcvd: 78 F. Castiglione

72 controlla la consistenza dei dati (record NS e MX che
dnswalk Ä DNS debugger Ä Esegue il trasferimento di zona di un dominio e ne controlla la consistenza dei dati (record NS e MX che corrispondono a CNAME, catena di CNAME, mancanza della risoluzione inversa, ecc.) Ä Riproduce sul file system la struttura del DNS per il dominio controllato Ä Fa parte dei contrib del BIND (disponibile anche su Ä Necessita del perl e di alcuni moduli addizionali (Net::DNS e IO::Socket). Le vecchie versioni di dnswalk necessitano anche di ‘dig’ F. Castiglione

73 Effettua controlli su:
dnswalk Effettua controlli su: Ä associazione tra record A e PTR Ä uso dei CNAME (es. CNAME definito verso un altro CNAME) Ä uso dei record MX (MX definito verso CNAME o host inesistenti) Ä presenza di un solo nameserver Ä utilizzo di caratteri non validi nei nomi a dominio (es: ‘_’ ) Ä assenza del ‘.’ finale nei record PTR (125 IN PTR host.cnr.it ) Ä lame delegations F. Castiglione

74 Esempio: dnswalk dnswalk -F ba.cnr.it. Checking ba.cnr.it.
Getting zone transfer of ba.cnr.it. from dns.ba.cnr.it...done. SOA=dns.ba.cnr.it contact=postmaster.dns.ba.cnr.it WARN: netrider.ba.cnr.it A : no PTR record WARN: mailhost.ba.cnr.it CNAME bigarea.ba.cnr.it: unknown host WARN: embnet.ba.cnr.it CNAME embnet.area.ba.cnr.it: CNAME (to area.area.ba.cnr.it) WARN: ftp.ba.cnr.it CNAME ftp.area.ba.cnr.it: CNAME (to area.area.ba.cnr.it) 0 failures, 6 warnings, 0 errors. F. Castiglione

75 NDC consente di gestire il processo named evitando di
inviare segnali con il comando KILL. # ndc reload BA.CNR.IT Zone is now scheduled for reloading. # ndc getpid my pid is <241> # ndc status named REL Sat Oct 30 17:27:21 MET 1999 number of zones allocated: 256 debug level: 0 xfers running: 0 xfers deferred: 0 soa queries in progress: 0 query logging is OFF server is DONE priming server IS NOT loading its configuration F. Castiglione

76 Consente di aggiornare una zona in modo dinamico,
nsupdate Consente di aggiornare una zona in modo dinamico, inviando al named i RR da inserire. # nsupdate > update add cc.dynamic.ba.cnr.it 3600 IN A causerà l’inserimento del RR ‘cc 3600 IN A ’ nel dominio dynamic.ba.cnr.it L’operazione verrà registrata in un file di log (‘file di zona’.log) e propagata ai server secondari: ;BIND LOG V8 [DYNAMIC_UPDATE] id 8347 from [ ].1315 at (named pid 959) : zone: origin dynamic.ba.cnr.it class IN serial update: {add} cc.dynamic.ba.cnr.it IN A [INCR_SERIAL] from to Sat Nov 6 15:44: F. Castiglione

77 ATTENZIONE! Il file di zona verrà riscritto (ogni 30 minuti o
nsupdate ATTENZIONE! Il file di zona verrà riscritto (ogni 30 minuti o allo shutdown di named) con i RR aggiunti via nsupdate: file di zona prima di IN SOA dns.ba.cnr.it. postmaster.dns.ba.cnr.it. ( ) @ NS dns.ba.cnr.it. @ NS area.area.ba.cnr.it. ; WWW IN A file di zona riscritto da named ;BIND DUMP V8 $ORIGIN ba.cnr.it. dynamic IN NS dns.ba.cnr.it. ;Cl=4 86400 IN NS area.area.ba.cnr.it. ;Cl=4 86400 IN SOA dns.ba.cnr.it. postmaster.dns.ba.cnr.it. ( ) ;Cl=4 $ORIGIN dynamic.ba.cnr.it. cc 3600 IN A ;Cl=4 WWW IN A ;Cl=4 F. Castiglione

78 La possibilità di aggiornare una zona via nsupdate va abilitata in
named.conf mediante ‘allow-update’. Il controllo dell’accesso al momento è basato solo sull’indirizzo IP. Esempio: zone "dynamic.ba.cnr.it" { type master; file "dom.dynamic.ba.cnr.it"; allow-update { ; }; F. Castiglione

79 Bibliografia F. Castiglione
Ä DNS and BIND, 3rd Edition (Paul Albitz & Cricket Liu, September 1998) Ä RFC Domain Names, Concepts and Facilities (P. Mockapetris, Sep 1983) Ä RFC Domain Names, Implementation and Specification (P. M., Nov 1983) Ä RFC Domain System Changes and Observations (P. M., Jan 1986) Ä RFC Mail Routing and the Domain System (C. Partridge, Jan 1986) Ä RFC Domain Names, Concepts and Facilities (P. M., Nov 1987) Ä RFC Domain Names, Implementation and Specification (P. M., Nov 1987) Ä RFC Requirements for Internet Hosts, Application and Support (IETF, Oct 1989) Ä RFC Assigned Numbers (ISI, Jul 1992) Ä RFC Common DNS Data File Configuration Errors (P. Beertema, Oct 1993) Ä RFC Domain Name System Structure and Delegation (J. Postel, Mar 1994) Ä RFC Tools for DNS debugging (A. Romao, Nov 1994) Ä RFC Common DNS Operational and Configuration Errors (D. Barr, Feb 1996) Ä RFC Classless IN-ADDR.ARPA delegation (BSD - ISC, Mar 1998) F. Castiglione

80 Sitografia Ä http://www.isc.org : Bind
Ä : RFC index Ä : IANA Ä : ICANN Ä : Registration Authority Italiana Ä : DNS Resources Directory F. Castiglione

81 IL REGOLAMENTO CE 733/2002 SUL DOMINIO .EU
Materiale aggiuntivo IL REGOLAMENTO CE 733/2002 SUL DOMINIO .EU

82 PRINCIPI GIURIDICI DI BASE
Connotazione pubblicistica “storica” (almeno in USA) della gestione del DNS Afferenza al settore delle telecomunicazioni Problemi di conflitto con diritti della personalità e di proprietà industriale per domain names utilizzati a scopo distintivo (ma non per questo qualificazione in re ipsa del domain name come segno distintivo)

83 Il dominio .eu è un ccTLD (ISO 3166-1)
IL REGOLAMENTO Il dominio .eu è un ccTLD (ISO ) Si affianca ai ccTLD degli Stati Membri Base giuridica del regolamento comunitario: reti transfrontaliere (artt. 154 e 155 del Trattato) Conferma dell’afferenza al settore telecomunicazioni ed impostazione marcatamente pubblicistica

84 I SOGGETTI INTERESSATI
Potrà registrare un dominio .eu: qualsiasi impresa che abbia la propria sede legale, amministrazione centrale o sede d'affari principale nel territorio della Comunità europea qualsiasi organizzazione stabilita nel territorio della Comunità europea qualsiasi persona fisica residente nel territorio della Comunità europea Quindi, tecnicamente, anche le amministrazioni pubbliche nazionali

85 LA GESTIONE Titolarità dei diritti e delle politiche di risoluzione dei conflitti in capo agli organismi comunitari Gestione del registro ed applicazione delle politiche di risoluzione dei conflitti affidata ad organismo non-profit stabilito nella UE Affidatario scelto con procedimento ad evidenza comunitaria, secondo le regole della “comitologia” Principi di gestione informati a qualità, efficienza, affidabilità ed accessibilità

86 LA REGISTRAZIONE Servizi di registrazione (registrar) affidati ad organismi terzi, che dovranno sottoscrivere un contratto di registrar con l’affidatario del registro Possibilità di registrazione per fasi per assicurare ai titolari di diritti preesistenti e agli organismi pubblici un adeguato lasso di tempo per la registrazione dei loro nomi Possibilità per gli Stati Membri di fornire liste di blocco di determinati nomi di interesse geografico o geopolitico nazionale

87 CONCLUSIONE Una operazione per fornire uno “spazio di registrazione” comune nella UE Un approccio equilibrato verso i diritti di proprietà industriale e della personalità, senza i velleitarismi delle proposte di legge nazionali Una possibilità in più anche per le amministrazioni pubbliche nazionali

88 fine fine