La presentazione è in caricamento. Aspetta per favore

La presentazione è in caricamento. Aspetta per favore

Massimo Ianigro Massimo Ianigro Daniele Vannozzi Daniele Vannozzi Domain Name System.

Presentazioni simili


Presentazione sul tema: "Massimo Ianigro Massimo Ianigro Daniele Vannozzi Daniele Vannozzi Domain Name System."— Transcript della presentazione:

1 Massimo Ianigro Massimo Ianigro massimo.ianigro@area.ba.cnr.it Daniele Vannozzi Daniele Vannozzi daniele.vannozzi@iat.cnr.it Domain Name System

2 Bologna 23 novembre 2000 2 ule funzioni del Domain Name System ulo spazio dei nomi uinterazioni tra nameserver e resolver uinterazioni tra DNS e posta elettronica Argomenti trattati

3 Bologna 23 novembre 2000 3 Domain Name System: breve storia uGli indirizzi IP sono difficili da ricordare: vanno bene per la comunicazione tra le macchine HOSTS.TXT umodello centralizzato: agli albori di Internet lassociazione tra indirizzo IP e nomi delle macchine era registrata nel file HOSTS.TXT mantenuto presso SRI-NIC (Arpanet) ltraffico e sovraccarico del server centrale lcollisioni dei nomi lconsistenza dei dati gestiti centralmente umodello distribuito: allinizio degli anni 80, laumento del numero degli host ha reso indispensabile ladozione di un modello di gestione distribuita denominato Domain Name System

4 Bologna 23 novembre 2000 4 uad ogni risorsa TCP/IP può essere assegnato un nome simbolico Sono necessari: lun metodo per associare al nome simbolico di una macchina lindirizzo (o gli indirizzi) IP: risoluzione diretta lun metodo per associare ad un indirizzo IP il nome simbolico della macchina: risoluzione inversa uDomain Name System (DNS) ldefinito presso ISI - USC 1984 lRFC 882, RFC 883, RFC 973 (obsolete) lRFC 1034, RFC 1035, RFC 1123, RFC 1537, RFC 1912 DNS: le funzioni

5 Bologna 23 novembre 2000 5 DNS: caratteristiche principali udatabase distribuito ubasato sul modello client/server utre componenti principali: lspazio dei nomi e informazioni associate (Resource Record - RR) lnameserver (application server che mantiene i dati) lresolver (client per linterrogazione del nameserver) uaccesso veloce ai dati (database in memoria centrale e meccanismo di caching)

6 Bologna 23 novembre 2000 6 Lo spazio dei nomi ulo spazio dei nomi è organizzato secondo un modello gerarchico: lil database del DNS ha una struttura logica ad albero rovesciato lciascun nodo dellalbero rappresenta un dominio logni dominio può essere suddiviso in altri domini: sottodomini logni 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. ustruttura dello spazio dei nomi: ldomini generali (gTLD) ldomini nazionali (ccTLD) ldomini per la risoluzione inversa (arpa)

7 Bologna 23 novembre 2000 7 e.c.a h.g.f.d.b uil domain name (nome a dominio) di ogni nodo è composto dalla sequenza delle etichette dal nodo a (root), separate da. (punto). Es: e.c.a, h.g.f.d.b uun nome a dominio assoluto è detto anche fully-qualified domain name o FQDN uil Distributed Information Tree (albero dei nomi) definisce una gerarchia dei nomi che rende ogni nome a dominio completamente qualificato univoco in tutto lalbero Lalbero dei nomi Top Level Domain, TLD First Level Domain Second Level Domain.......... ab cd f.h g e

8 Bologna 23 novembre 2000 8 I domini uper dominio si intende il sottoalbero che inizia dal nodo con il nome a dominio in questione udi solito, le foglie rappresentano il nome a dominio di un host uai nodi sono associate le informazioni relative a quel nome a dominio (RR) lentry di host lentry strutturali nodo con nome a dominio head.acme.com com acme www duck goofy head comp sale dominio com dominio acme.com dominio comp.acme.com.

9 Bologna 23 novembre 2000 9 ulo spazio dei nomi di Internet, per tradizione (rfc1591), è strutturato secondo un modello misto organizzazionale/geografico ui Top-Level-Domain sono ldomini generali storici di tipo organizzazionale (gTLD): lcom: organizzazioni commerciali ledu: università e ricerca USA lgov: organizzazioni governative USA lmil: organizzazioni militari USA lnet: provider, centri di interesse per lInternet,.. lorg: organizzazioni non governative lint: organizzazioni internazionali, trattati,... ldomini nazionali, rappresentati dai codici ISO 3166 di 2 lettere (ccTLD) lil dominio arpa lnuovi domini in corso di definizione:.info, … LInternet Domain Name Space

10 Bologna 23 novembre 2000 10 LInternet Domain Name Space COM MITSTANFORD AI PREPXXVX ARPA IN-ADDR BERKELEY ITUK USNL FIAT RMMI IAT LAZIO FI COMUNEREGIONE DNS HP4000. EDU LCS CNR

11 Bologna 23 novembre 2000 11 Lalbero per la risoluzione inversa l48.146.in-addr.arpa dominio l65.48.146.in-addr.arpa sotto-dominio l69.65.48.146.in-addr.arpa macchina ARPA IN-ADDR 146128195193 865...... 254691..... 48

12 Bologna 23 novembre 2000 12 uIl DNS permette a organizzazioni dotate di un proprio dominio di: lamministrare la relazione nomi-indirizzi del proprio dominio in maniera autonoma ed indipendente ldefinire le regole di naming allinterno del proprio dominio ldelegare ad altri la gestione degli eventuali domini figli (sotto-domini) lrisolvere 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 lautorità per la gestione dei TLD La delega di autorità

13 Bologna 23 novembre 2000 13 Domini e zone: differenze ule informazioni sono mantenute nei nameserver uun nameserver mantiene i dati di un sottoinsieme dello spazio dei nomi: la zona uogni zona può essere un sottodominio completo, cioè comprendere vari domini su una porzione del DIT non disgiunta uun nameserver può gestire più zone disgiunte uil dominio padre contiene solo puntatori alla sorgente dei dati dei suoi sottodomini lciascuna zona contiene i nomi a dominio e i dati appartenenti ad certo dominio, esclusi i nomi e i dati dei sottodomini delegati ad altri. com acme goofy dominio com roger zona com

14 Bologna 23 novembre 2000 14 Domini e zone: i nameserver ula struttura gerarchica dello spazio dei nomi si riflette nella relazione tra i nameserver uil meccanismo della delega di autorità si basa sui seguenti principi: logni nameserver di un dominio, per essere conosciuto nel DNS, deve essere stato registrato dal nameserver del dominio di livello superiore. Questo crea la delega luna volta delegata l'autorità su una zona il nameserver padre perde ogni possibilità di modificare le informazioni dei domini contenuti nella zona delegata li 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

15 Bologna 23 novembre 2000 15 Il parenting Dipende da varie considerazioni: lnecessità di definire sottodomini per partizionare uno spazio dei nomi piatto e molto esteso lnecessità di distinguere laffiliazione delle macchine di un dominio lnecessità di distribuire la gestione uquanti sottodomini definire? uquando delegarne la gestione? uche nome assegnare ai sottodomini? ? Attenzione alla corretta gestione del meccanismo della delega per garantire la risoluzione dei nomi per tutto il dominio!! !

16 Bologna 23 novembre 2000 16 ui root-server sono i nameserver della. (radice). usono essenziali al funzionamento del DNS perchè: lcontengono le informazioni sui Top-Level-Domain e sui relativi nameserver ai quali ne delegano la gestione lcontengono le informazioni per la risoluzione inversa (risoluzione indirizzo-nome) uogni nameserver deve conoscere nomi ed indirizzi dei root-server ula lista aggiornata dei root-server è mantenuta da InterNIC lftp://ftp.rs.internic.net/domain/named.root lftp://ftp.nic.it/pub/DNS/named.root I root-servers

17 Bologna 23 novembre 2000 17 Nameserver autoritativi uun nameserver si definisce autoritativo quando è in possesso dei dati per una determinata zona dellalbero dei nomi uper un dominio vi possono essere più nameserver autoritativi lper avere una maggiore affidabilità è fortemente consigliato averne più di uno, localizzati in modo da ridurre il rischio di interruzione del servizio DNS ui nameserver autoritativi si dividono in: lprimari lsecondari

18 Bologna 23 novembre 2000 18 Nameserver primari e secondari uun nameserver si definisce primario quando possiede i file delle informazioni (file di zona) e pertanto in ogni zona vi sarà un solo nameserver primario uun nameserver si definisce secondario quando acquisisce, dal nameserver primario, i dati relativi alla zona mediante una procedura automatica denominata zone-transfer li parametri che regolano il funzionamento della procedura sono contenuti in uno specifico record del nameserver primario (record SOA) lprocedura: /usr/dns/etc/named-xfer -z domname -f outputfile authNS uè 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

19 Bologna 23 novembre 2000 19 uogni nameserver mantiene copia di tutte le informazioni di cui è venuto a conoscenza utali informazioni sono utilizzate durante il processo di risoluzione dei nomi ule risposte date dal nameserver sulla base della cache sono not authoritative ule informazioni nella cache di un nameserver rimangono valide per un tempo limitato (Time-To-Live, TTL) Caching può dare luogo a temporanee inconsistenze aumenta le performance del sistema

20 Bologna 23 novembre 2000 20 Il processo di risoluzione dei nomi a dominio è basato sul modello client- server: uil nameserver (server) è un processo che ha il compito di fornire risposte autoritative ad interrogazioni sui nomi definiti nellambito dei domini per cui è autoritativo; uil 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 linformazione 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) Il processo di risoluzione: Nameserver e Resolver

21 Bologna 23 novembre 2000 21 Il processo di risoluzione dei nomi applicazione utente 1 Default Nameserver (cache vuota) root nameserver query per www.iat.cnr.it. ITCOM CNRUNIPI BO IAT www referral al NS per it. it. nameserver query for www.iat.cnr.it referral al NS per cnr.it cnr.it nameserver query for www.iat.cnr.it referral al NS per iat.cnr.it iat.cnr.it nameserver query: www.iat.cnr.it RR per www.iat.cnr.it 6 5 4 2 3 RESOLVER

22 Bologna 23 novembre 2000 22 uSe il nome desiderato non è nella zona (o nella cache) del NS interrogato, si innesca il processo di risoluzione dei nomi uLa richiesta di risoluzione risale il DIT fino alla radice e lo ridiscende fino ad arrivare ad un NS autoritativo la cui zona contiene il nome in questione e quindi anche gli RR uLa risposta, opportunamente salvata in tutti i cache intermedi, viene infine passata dal resolver allutente che aveva effettuato la richiesta u2 modalità di risoluzione dei nomi: lricorsiva (il NS pensa a tutto) literativa (il resolver si rivolge direttamente ai vari NS della catena) Risoluzione dei nomi

23 Bologna 23 novembre 2000 23 uhardware ldisponibile su quasi tutte le attuali piattaforme (PC, Macintosh, workstation, mainframe) usoftware lprodotti di pubblico dominio (BIND per Unix e WinNT/Win95, MIND/NonSequitur per MacOS) lprodotti commerciali (MacDNS, QuickDNS Pro, distribuzione di WinNT server 4.0) uBIND (Berkeley Internet Name Domain) lè limplementazione di nameserver più diffusa su Internet lsviluppata per Unix BSD, ne esistono porting per molti altri ambienti lspesso ne è inclusa una implementazione nel software di corredo di piattaforme Unix lvi sono attualmente tre versioni: lla versione storica 4.x.y (lultima rilasciata è la 4.9.7) lla versione 8.x.y (lultima rilasciata è la 8.2.2-P7) lla versione 9.x.y, ancora in fase di evoluzione Le piattaforme hardware e software http://www.isc.org/bind.html

24 Bologna 23 novembre 2000 24 File di configurazione lnamed.boot (4.x.y) lformato ormai in uso da anni lconsente solo alcune personalizzazioni generali lnamed.conf (8.x.y) lnuovo formato (stile linguaggio c) lfunziona con IPv6 (http://www.6bone.net) lconsente una personalizzazione completa sia generale che zona per zona uEsiste una procedura perl (named-bootconf.pl) per la conversione dal formato 4.x.y al formato 8.x.y rimangono inalterati i file delle singole zone Le maggiori differenze tra le versioni 4 e 8

25 Bologna 23 novembre 2000 25 umeccanismo del notify lpermette laggiornamento quasi in tempo reale tra nameserver primario e secondari umeccanismo di logging flessibile e personalizzabile, senza uso obbligato del logging del sistema (syslog) ucontrollo degli accessi personalizzabile per zona umigliore ottimizzazione della memoria centrale lmigliora notevolmente le prestazioni del servizio, specialmente per implementazioni con molte zone attive sulla stessa macchina unumero max di zone incrementato a 4.294.967.295 (2 32 ) usupporto iniziale di DNSSEC usupporto di WindowsNT uupdate dinamico (NSUPDATE) e incrementale (IXFR) u$GENERATE Nuove funzionalità della versione 8.x.y

26 Bologna 23 novembre 2000 26 Caratteristiche salienti di BIND 9 uVersione corrente 9.0.1 uMiglioramento delle funzionalità di update dinamico uSupporto per zone di elevate dimensioni (.com) uMiglioramento funzionalità DNSSec/TSIG uMiglioramento funzionalità IXFR uViews uRNDC - Remote Named Daemon Control uAlcune delle funzionalità correnti della 8.x.y non sono ancora state implementate

27 Bologna 23 novembre 2000 27 Views (Bind 9) E possibile definire viste differenti di una stessa zona: view "internal" { match-clients { 10.0.0.0/8; }; // rete interna recursion yes; //ricorsione abilitata solo alla LAN interna zone "example.com" { type master; file zone-internal.db"; // file completo }; view "external" { match-clients { any; }; // reti esterne recursion no; zone "example.com" { type master; file zone-external.db"; //file con le macchine pubbliche };

28 Bologna 23 novembre 2000 28 RNDC RNDC uConsente il controllo di named in remoto (TCP/953) uRichiede un file di configurazione rndc.conf nel quale è possibile specificare le chiavi per lautenticazione della connessione. Esempio: key rndc_key { algorithm "hmac-md5"; secret "c3Ryb25nIGVub3VnaCBmb3EgK"; }; options { default-server localhost; default-key rndc_key; };

29 Bologna 23 novembre 2000 29 Differenze rispetto a BIND 8.2.2 uNuove categorie di logging; il logging viene attivato solo dopo il parsing completo di named.conf uAssenza delle opzioni: $GENERATE, STATISTICS- INTERVAL, TOPOLOGY, SORTLIST, RRSET-ORDER, CHECK-NAMES,MIN-ROOTS, process limits, file path, selective forwarding uFunzione di resolver implementata da un processo demone (UDP/921) invece che da libresolv.a unamed-xfer integrato in named

30 Bologna 23 novembre 2000 30 Differenze rispetto a BIND 8.2.2 (2) uACL case sensitive uIl TTL del SOA non viene più utilizzato come TTL di default; il default viene determinato dalla direttiva $TTL oppure dal TTL del primo resource record nella zona. In assenza di entrambi la zona non viene caricata!!! uNuova sintassi della direttiva controls uSistema operativo WindowsNT non supportato uAdministrator Reference Manual

31 Bologna 23 novembre 2000 31 La posta su Internet relazione tra SMTP e DNS ulinstradamento della posta su Internet si basa sulle interazioni tra mailer (MTA) SMTP e DNS uper ogni destinatario di un messaggio il mailer SMTP chiede al DNS la lista di RR di tipo MX per il nome a dominio specificato nella parte globale ui record MX costituiscono una lista ordinata, secondo la preferenza, di mailer (MTA) per il dominio (host) destinazione

32 Bologna 23 novembre 2000 32 Mail Routing & DNS ualgoritmo di un mailer SMTP per destinazione REMOTA: llista mailers vuota: lripete linterrogazione per record A e tenta la consegna all'host remoto : llista mailers non vuota: lse la lista contiene il mailer stesso scarta se stesso ed ogni mailer con preference minore o uguale a se stesso (preference con valore numerico maggiore o uguale) - loop prevention se la lista risultasse vuota: ERROR ltenta la consegna ai mailers della lista, partendo dal preference maggiore (numericamente minore).

33 Bologna 23 novembre 2000 33 Mail routing & DNS: esempio mail to user@domainA MTA1 MTA1 MX for domainA DNS domainA MX 0 MTA3 MX 50 MTA2 MX 100 MTA4 MTA3 MTA3 MTA2 MTA2 MTA4 MTA4 mail delivery domainA: LOCAL

34 Bologna 23 novembre 2000 34 Utilizzo dei record MX per il routing della posta elettronica Utilizzando opportunamente i pesi associati ai record MX è possibile controllare il routing della posta elettronica Esempio: effettuare un controllo sullinstradamento della posta elettronica verso le macchine del dominio

35 Bologna 23 novembre 2000 35 Utilizzo dei record MX 2 Internet Firewall.domain.it User@host.domain.it HostIN mx 10 host mx 20 firewall Nella zona di domain.it

36 Bologna 23 novembre 2000 36 Alcune regole pratiche per la sicurezza del named Alcune regole pratiche per migliorare il livello di sicurezza di un named: urestringere lo zone-transfer solo ai nameserver secondari e verificare che tali restrizioni siano attivate anche su tutti gli altri nameserver autoritativi udisabilitare la possibilità di effettuare update dinamici (nsupdate) udisabilitare la ricorsione ueseguire named senza i privilegi di root (named -u xxx) unel caso di utilizzo di un firewall per proteggere una rete, predisporre un nameserver esterno con le sole informazioni relative alle macchine visibili su Internet (es. www server, mail server, etc) e uno interno, utilizzabile solo dalle macchine locali, con le informazioni complete della zona.

37 Bologna 23 novembre 2000 37 Utility di supporto nella gestione di un nameserver unslookup uhost udig udnswalk undc unsupdate LRFC 1713 descrive un insieme di tools che possono essere utili per il debugging della configurazione di un nameserver

38 Bologna 23 novembre 2000 38 nslookup uè normalmente distribuito insieme al S.O. o alla distribuzione di BIND usi può utilizzare sia in modalità interattiva che tramite riga di comando udispone di aiuto in linea nslookup Default Server: dns.iat.cnr.it Address: 146.48.65.3 > > set q=any > www.iat.cnr.it > www.iat.cnr.it canonical name = soi.cnr.it

39 Bologna 23 novembre 2000 39 nslookup (2) uQuery per tutti i record del dominio cnr.it > nslookup Default Server: dns.pi.cnr.it Address: 146.48.65.2 > set q=any > cnr.it Server: dns.pi.cnr.it Address: 146.48.65.2 Non-authoritative answer: cnr.it nameserver = nameserver.cnr.it cnr.it nameserver = dns2.nic.it cnr.it nameserver = itgbox.iat.cnr.it cnr.it nameserver = simon.cs.cornell.edu cnr.it nameserver = ns1.surfnet.nl cnr.it origin = nameserver.cnr.it mail addr = Daniele\.Vannozzi.iat.cnr.it serial = 2000111801 refresh = 86400 (1 day) retry = 1800 (30 mins) expire = 604800 (7 days) minimum ttl = 86400 (1 day)... > set type=mx > ls iat.cnr.it

40 Bologna 23 novembre 2000 40 host uè incluso nella distribuzione di BIND ed è inoltre reperibile presso: ftp://ftp.nikhef.nl/pub/network/host.tar.Z unon è interattivo: si utilizza da linea di comando upermette di fare interrogazioni complesse a qualsiasi nameserver uè dotato di aiuto in linea host host -i 146.48.65.3 host -av cnr.it nameserver.cnr.it host -avl cnr.it nameserver.cnr.it host -t soa cnr.it host -C cnr.it

41 Bologna 23 novembre 2000 41 host (2) uQuery per tutti i record del dominio cnr.it > 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 542353 IN NS nameserver.cnr.it cnr.it 542353 IN NS dns2.nic.it cnr.it 542353 IN NS itgbox.iat.cnr.it cnr.it 542353 IN NS simon.cs.cornell.edu cnr.it 542353 IN NS ns1.surfnet.nl cnr.it 155353 IN SOA nameserver.cnr.it Daniele\.Vannozzi.iat.cnr.it ( 2000111801 ;serial (version) 86400 ;refresh period (1 day) 1800 ;retry interval (30 minutes) 604800 ;expire time (1 week) 86400 ;default ttl (1 day) ) ……

42 Bologna 23 novembre 2000 42 host (3) > host -C ba.cnr.it ba.cnr.it NS nameserver.cnr.it dns.ba.cnr.it postmaster.dns.ba.cnr.it (1999071201 3600 1800 604800 86400) ba.cnr.it NS dns.ba.cnr.it dns.ba.cnr.it postmaster.dns.ba.cnr.it (1999071202 3600 1800 604800 86400) !!! 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 (1999071201 3600 1800 604800 86400) !!! area.area.ba.cnr.it has different serial than dns.ba.cnr.it

43 Bologna 23 novembre 2000 43 dig uè incluso nella distribuzione di BIND unon è interattivo; si utilizza da linea di comando upermette di fare interrogazioni complesse ed a qualsiasi nameserver uè dotato di aiuto in linea dig -h dig dns.iat.cnr.it dig dns.iat.cnr.it mx dig -x 146.48.65.3 dig @nameserver.cnr.it cnr.it

44 Bologna 23 novembre 2000 44 dig (2) uQuery per tutti i record del dominio cnr.it > dig cnr.it ; > DiG 2.2 > cnr.it ;; res options: init recurs defnam dnsrch ;; got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6 ;; flags: qr rd ra; Ques: 1, Ans: 0, Auth: 1, Addit: 0 ;; QUESTIONS: ;; cnr.it, type = A, class = IN ;; AUTHORITY RECORDS: cnr.it. 504 SOA nameserver.cnr.it. Daniele\.Vannozzi.iat.cnr.it. ( 2000111801; serial 86400 ; refresh (1 day) 1800 ; retry (30 mins) 604800 ; expire (7 days) 86400 ) ; minimum (1 day) ….. ;; Total query time: 28 msec ;; FROM: dns.pi.cnr.it to SERVER: default -- 146.48.65.2 ;; WHEN: Mon Nov 20 12:32:20 2000

45 Bologna 23 novembre 2000 45 dnswalk uDNS debugger uEsegue 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.) uRiproduce sul file system la struttura del DNS per il dominio controllato uFa parte dei contrib del BIND (disponibile anche su http://www.visi.com/~barr/dnswalk/) uNecessita del perl e di alcuni moduli addizionali (Net::DNS e IO::Socket). Le vecchie versioni di dnswalk necessitano anche di dig

46 Bologna 23 novembre 2000 46 dnswalk (2) Effettua controlli su: uassociazione tra record A e PTR uuso dei CNAME (es. CNAME definito verso un altro CNAME) uuso dei record MX (MX definito verso CNAME o host inesistenti) upresenza di un solo nameserver uutilizzo di caratteri non validi nei nomi a dominio (es: _ ) uassenza del. finale nei record PTR (125 IN PTR host.cnr.it ) ulame delegations

47 Bologna 23 novembre 2000 47 dnswalk (3) Esempio: 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 194.119.200.30: 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.

48 Bologna 23 novembre 2000 48 NDC - Name daemon control NDC consente di gestire il processo named evitando di inviare segnali con il comando KILL. Esempi: # ndc reload BA.CNR.IT Zone is now scheduled for reloading. # ndc getpid my pid is # ndc status named 8.2.2-REL Sat Oct 30 17:27:21 MET 1999 root@area.area.ba.cnr.it:/root/bind8_2_2/src/bin/named 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

49 Bologna 23 novembre 2000 49 NSUPDATE Consente di aggiornare una zona in modo dinamico, inviando al named i RR da inserire. Esempio: # nsupdate > update add cc.dynamic.ba.cnr.it 3600 IN A 100.100.100.100 causerà linserimento del RR cc3600 IN A 100.100.100.100 nel dominio dynamic.ba.cnr.it Loperazione verrà registrata in un file di log (file di zona.log) e propagata ai server secondari: ;BIND LOG V8 [DYNAMIC_UPDATE] id 8347 from [193.204.191.39].1315 at 941985572 (named pid 959) : zone: origin dynamic.ba.cnr.it class IN serial 1999072501 update: {add} cc.dynamic.ba.cnr.it. 3600 IN A 100.100.100.100 ;BIND LOG V8 [INCR_SERIAL] from 1999072501 to 1999072502 Sat Nov 6 15:44:32 1999

50 Bologna 23 novembre 2000 50 NSUPDATE (2) 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 nsupdate@ IN SOA dns.ba.cnr.it. postmaster.dns.ba.cnr.it. ( 1999072501 3600 1800 604800 86400 ) @ NS dns.ba.cnr.it. @ NS area.area.ba.cnr.it. ; WWW IN A 194.119.200.100 file di zona riscritto da named ; BIND DUMP V8 $ORIGIN ba.cnr.it. dynamic 86400 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. ( 1999072502 3600 1800 604800 86400 ) ;Cl=4 $ORIGIN dynamic.ba.cnr.it. cc 3600 IN A 100.100.100.100 ;Cl=4 WWW 86400 IN A 194.119.200.100 ;Cl=4

51 Bologna 23 novembre 2000 51 NSUPDATE (3) La possibilità di aggiornare una zona via nsupdate va abilitata in named.conf mediante allow-update. Il controllo dellaccesso al momento è basato solo sullindirizzo IP. Esempio: zone "dynamic.ba.cnr.it" { type master; file "dom.dynamic.ba.cnr.it"; allow-update { 193.204.191.39; };

52 Bologna 23 novembre 2000 52 Riferimenti Bibliografici uDNS and BIND, 3rd Edition (Paul Albitz & Cricket Liu, September 1998) uRFC 882 - Domain Names, Concepts and Facilities (P. Mockapetris, Sep 1983) uRFC 883 - Domain Names, Implementation and Specification (P. M., Nov 1983) uRFC 973 - Domain System Changes and Observations (P. M., Jan 1986) uRFC 974 - Mail Routing and the Domain System (C. Partridge, Jan 1986) uRFC 1034 - Domain Names, Concepts and Facilities (P. M., Nov 1987) uRFC 1035 - Domain Names, Implementation and Specification (P. M., Nov 1987) uRFC 1123 - Requirements for Internet Hosts, Application and Support (IETF, Oct 1989) uRFC 1340 - Assigned Numbers (ISI, Jul 1992) uRFC 1537 - Common DNS Data File Configuration Errors (P. Beertema, Oct 1993) uRFC 1591 - Domain Name System Structure and Delegation (J. Postel, Mar 1994) uRFC 1713 - Tools for DNS debugging (A. Romao, Nov 1994) uRFC 1912 - Common DNS Operational and Configuration Errors (D. Barr, Feb 1996) uRFC 2317 - Classless IN-ADDR.ARPA delegation (BSD - ISC, Mar 1998)

53 Bologna 23 novembre 2000 53 ugestito presso lo IAT di Pisa uorganizzato in sottodomini che riflettono la struttura organizzativa del CNR, la distribuzione sul territorio ed esigenze di rete ututti i domini devono avere almeno 2 nameserver ututti i domini di terzo livello (es: pi.cnr.it, src.cnr.it, ecc) devono avere come nameserver secondario nameserver.cnr.it uè suggerito avere un secondario sul nameserver primario del dominio padre uè consigliato utilizzare come nameserver secondario per la risoluzione inversa delle reti usate dal CNR (non per le subnet delle reti in classe B) nameserver.cnr.it uè necessario registrare il router che assicura linterconnessione alla dorsale della rete nel dominio net.cnr.it Il naming attuale del dominio CNR.IT IT CNR pisrcwww. iatnet dns area adrserv pisa-router iei ieiserv

54 Bologna 23 novembre 2000 54 Il nuovo naming del dominio cnr.it uApprovato dalla commissione CIRT lattualmente allapprovazione del Presidente/Consiglio Direttivo uNovita introdotte lEliminazione del dominio geografico lUnivocita delle sigle dei nuovi istituti lSpecifiche tecniche sullerogazione del servizio di risoluzione dei nomi lControllo del rispetto dei requisti tecnici anche dopo lattivazione del nuovo dominio lAttivazione di un gruppo di esperti per la valutazione delle richieste di nuovi nomi a dominio non previsti dalle attuali policy

55 Un possibile utilizzo del nuovo naming del dominio cnr.it IRPI un istituto con sezioni distribuite sul territorio nazionale

56 Bologna 23 novembre 2000 56 La situazione attuale uStesso nome di dominio lIrpi (eccezione attuale sede di Bari) uUn dominio per ogni sede lPerugiairpi.pg.cnr.it lPadovairpi.pd.cnr.it lCosenzairpi.cs.cnr.it lBaricerist.ba.cnr.it lTorinoirpi.to.cnr.it

57 Bologna 23 novembre 2000 57 Le possibili soluzioni uAdozione di uno schema di naming che non tenga conto della dislocazione fisica delle sezioni e delle macchine lHost.irpi.cnr.it uAdozione di uno schema geografico sotto al nuovo dominio lHost.pg.irpi.cnr.it lHost.pd.irpi.cnr.it

58 Bologna 23 novembre 2000 58 Alcuni elementi utili alla scelta dello schema di naming uSinergie interne al nuovo istituto uComprensione/immediatezza/semplificazione dellindirizzi Internet uConoscenze informatiche (dns ed altri servizi Internet di base) uDisponibilita di risorse hardware nelle varie sedi uIndividuazione delle responsabilita nelle varie sedi

59 Bologna 23 novembre 2000 59 La migrazione verso il nuovo naming uRegistrazione/delega del nuovo dominio uVerifica/Attivazione dei server dns autoritativi per il nuovo dominio uGestione contemporanea del vecchio naming e nuovo naming

60 Bologna 23 novembre 2000 60 Interazione tra DNS e migrazione ulinterazione e legata al cambio, da parte di ogni host, del proprio nome a dominio ui file da modificare/creare sono: lnamed.conf lfile della risoluzione diretta lfile della risoluzione inversa ui record coinvolti sono principalmente lrecord A e CNAME lrecord PTR


Scaricare ppt "Massimo Ianigro Massimo Ianigro Daniele Vannozzi Daniele Vannozzi Domain Name System."

Presentazioni simili


Annunci Google