DNS. I Nomi a Dominio

Transcript

1 DNS I Nomi a Dominio

2 Agenda Introduzione Organizzazione Domini Architettura DNS Registrazione Domini Propagazione dell informazione Funzionamento Client

3

4 Introduzione Internet è una rete con milioni di calcolatori, ogni calcolatore ha un proprio indirizzo univoco chiamato indirizzo ip. L indirizzo IP è un numero composto da 4 ottetti binari separati da un punto: Per comodità noi siamo abituati a digitare questo numero nella sua forma decimale: Per evidenti leggi matematiche il valore che può assumere ogni ottetto va dallo 0 al 255. Per effettuare la connessione verso un calcolatore è necessario conoscerne l indirizzo.

5 L indirizzo IP è un numero più adatto ad essere usato dalle macchine che dagli uomini, un uomo fa molta più fatica a ricordare un numero piuttosto che un nome, per questo motivo fin dagli albori si è deciso di abbinare ad ogni indirizzo ip un nome che consentisse agli operatori di internet di memorizzare più facilmente gli indirizzi dei server. Negli anni 70 quando internet si chiamava ancora Arpanet i calcolatori collegati erano poche centinaia, per conservare l abbinamento tra nomi e indirizzi era stato generato un file di nome hosts, questo file era composto da due colonne: nella prima veniva inserito l indirizzo ip nella seconda veniva inserito il nome corrispondente. Questo file era gestito dal NIC (Network Information Center) dello Stanford Researce Institute di Menlo Park, in California. Il primo file hosts della storia conteneva solo 14 indirizzi, le organizzazioni che desideravano aggiungere un calcolatore semplicemente mandavano una mail al gestore, quest ultimo provvedeva ad aggiornare il file hosts e successivamente il file aggiornato veniva distribuito a tutti. La crescita esponenziale di Arpanet obbligò a pensare a un metodo più efficiente di operare.

6 Map of the TCP/IP test network in January 1982

7 Paul Mockapetris Craig Partridge Jon Postel

8 Nel 1983 Paul Mockapetris, Jon Postel e Craig Partridge idearono il Domain Name System (DNS), le specifiche originali sono descritte nella RFC 882, (successivamente RFC 1034, RFC1035) questo metodo è quello tuttora utilizzato in quasi tutta la rete. L amministrazione Clinton successivamente costituì l ICAAN (Internet Corporation for Assigned Names and Numbers), questa organizzazione no-profit è responsabile del coordinamento che consente di gestire domini di primo livello e indirizzi ip distribuiti nel globo. Per esercitare questo ruolo ICAAN coordina i Root Server dove sono registrati i TLD (top level domain), la lista dei TLD è conservata e aggiornata dallo IANA (Internet Assigned Numbers Authority). Per comprendere meglio il ruolo dei root-server è necessario analizzare l architettura del database distribuito dei DNS e il meccanismo adottato per identificare un dominio.

9 I DOMINI Noi tutti siamo oramai abituati a collegarci ai siti web digitando l URL, per esempio: rappresenta il dominio di primo livello comunemente chiamato TLD.Telecomitalia rappresenta il secondo livello.www rappresenta il terzo livello rappresenta per intero il nome da digitare per collegarsi al sito, quando un indirizzo è completo di tutte le informazioni per arrivare a collegare la macchina finale prende il nome di FQDN (Full Qualified Domain Name).

10 Esistono vari tipi di TLD I DOMINI Generic (gtld): Com,edu,biz,org,gov,mil Country Code (cctld): It, jp, fr, au, eu Infranstructure (itld): ARPA La gestione di ogni TLD è affidata da ICAAN con delle concessioni, i domini che identificano gli Stati per esempio sono dati in gestione alle autorità governative delle Nazioni interessate, i domini generici sono affidati invece a diverse organizzazioni, l elenco dei domini e delle relative concessioni è disponibile sul sito:

11 DATABASE DISTRIBUITO DNS e SOA A-B M Root Server: ICAAN com org it 1 Livello: RA PISA tin telecomitalia alice 2 Livello: Telecomitalia in smtp www 3 Livello: Telecomitalia

12 Root-Server I Root-Server si trovano all apice della piramide della struttura dei DNS. In questi DNS Server sono registrati tutti i TLD e il relativo server DNS che se ne fa carico in base alla concessione fornita da ICAAN. Sono gestiti da ISC (internet Software Consortium, presidente Paul Vixie). Questi Server non hanno molti record ma ricevono migliaia di richieste da parte di altri server che hanno bisogno di ottenere informazioni sulla risoluzione del nome (Query Ricorsiva). (F answers more than 272 million DNS queries per day) Questi Servers ricoprono un ruolo di fondamentale importanza, per fare un esempio drastico, se questi server venissero spenti, nessuno potrebbe più navigare in Internet con una grave ricaduta sull'economia mondiale. Il 21 Ottobre del 2002 un particolare virus (ping-flooding DDOS Attack) tentava attacchi continui a questi Root Servers mettendone in ginocchio nove su tredici. Si trattò dell attacco distribuito più potente nella storia di internet, partito da USA e Sud Corea provocò un parziale blocco in alcune aree del globo.

13 Elenco Root-Server Lettera, Vecchio nome, Indirizzo IPv4, Operatore, Luogo geografico A ns.internic.net VeriSign Dulles, Virginia, USA B ns1.isi.edu Information Sciences Institute Marina del Rey, California, USA C c.psi.net Cogent distribuito in anycast D terp.umd.edu University of Maryland College Park, Maryland, USA E ns.nasa.gov NASA Mountain View, California, USA F ns.isc.org ISC distribuito in anycast G ns.nic.ddn.mil NIC del DoD USA Vienna, Virginia, USA H aos.arl.army.mil U.S. Army Research Lab Poligono di Aberdeen, Maryland, USA I nic.nordu.net Autonomica distribuito in anycast J VeriSign distribuito in anycast K RIPE NCC distribuito in anycast L ICANN Los Angeles, California, USA M Progetto WIDE distribuito in anycast

14 ROOT SERVER

15 L evoluzione: Root Server Anycast Status Come abbiamo visto. al momento esistono 13 root nameserver, i cui nomi hanno tutti la forma lettera.root-servers.net dove lettera può assumere i valori da A ad M. Alcuni di essi, già esistenti da tempo, avevano un altro nome prima che venisse stabilita la convenzione di nomenclatura vigente. Al momento non è possibile aggiungere altri server a causa di un problema di ottimizzazione del protocollo: la risposta infatti deve contenere tutti i nomi dei server, e aggiungerne un quattordicesimo supererebbe la dimensione massima di un singolo pacchetto dati. I server C, F, I, J, K ed M corrispondono però ciascuno a diversi computer fisici, situati in diversi continenti e in grado di fornire un servizio decentralizzato mediante annunci anycast. Pertanto la maggior parte dei root nameserver si trova fisicamente, anche se non formalmente, al di fuori degli Stati Uniti. In Internet, un indirizzo di tipo anycast è un indirizzo IP che può corrispondere a più di un host sulla rete. Quando un pacchetto viene inviato ad un indirizzo anycast, la rete lo consegnerà ad uno qualsiasi tra quelli associati all'indirizzo, tipicamente al più "vicino". Questa tecnica viene utilizzata per distribuire il carico ed aumentare l'affidabilità di servizi essenziali per il funzionamento della rete, come appunto il DNS.

16 L evoluzione: Root Server Anycast Status Server Operator Anycast? Sites Geographic Coverage A VeriSign no 1 B ep.net yes 4 Greater Los Angeles C Cogent yes 4 United States D University of Maryland no 1 E NASA Ames Research Ctr no 1 F ISC yes 30 Worldwide G US DoD NIC no 1 H US Army Research Lab no 1 I Autonomica/NORDUnet yes 27 Worldwide J VeriSign yes 16 Worldwide K RIPE NCC yes 13 Worldwide L ICANN no 1 M WIDE Project yes 3 Worldwide Dati al

17 K ROOT SERVER Se a qualcuno fosse venuta la curiosità di vedere come è fatto un rootserver eccolo accontentato.

18 Registration Authority Italiana La registration Authority 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.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.

19 Registration Autority Italiana 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. 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à.

20 Registration Autority Italiana 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.

21 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, potete visitare l'indirizzo

22 Record DNS Il Mantainer inserisce nel proprio DNS le registrazioni relative ad un nuovo dominio preso in carico, inserendo nel proprio database i seguenti tipi di record: Record A: indica la corrispondenza tra un nome ed uno (o più) indirizzi IPV4 Record MX: indicano a quali server debba essere inviata la posta elettronica per un certo dominio Record CNAME: sono usati per creare un alias, ovvero per fare in modo che lo stesso calcolatore sia noto con più nomi Record PTR: Il DNS viene utilizzato anche per realizzare la risoluzione inversa, ovvero per far corrispondere ad un indirizzo IP il corrispondente nome a dominio Record AAAA: utilizzato per la registrazione di indirizzi IPV6 Record SRV: servono ad identificare il server per un determinato servizio all'interno di un dominio. Possono essere considerati una generalizzazione dei record MX Record NS: sono utilizzati per indicare quali siano i server DNS autoritativi per un certo dominio, ovvero per delegarne la gestione. Record SOA: sono usati per la gestione delle zone DNS

23 Microsoft Windows XP [Versione ] (C) Copyright Microsoft Corp. C:\Documents and Settings\PValisi>nslookup > server Server predefinito: ns2.interbusiness.it Address: > set type=a > Server: ns2.interbusiness.it Address: Risposta da un server non di fiducia: Nome: Address: > Record DNS

24 > > > set type=mx > alice.it Server: ns2.interbusiness.it Address: Record MX Risposta da un server non di fiducia: alice.it MX preference = 15, mail exchanger = smtp.aliceposta.it smtp.aliceposta.it internet address = > > In risposta ottengo il server a cui tutti invieranno posta per il dominio in analisi, è interessante notare che la query si invia digitando il dominio e non l FQDN come avviene per i record A. L importanza di questo record è tale che vale la pena approfondire l argomento.

25 Record MX Quando un client di posta invia una mail in realtà esegue semplicemente un file transfert sulla porta TCP 25 del server SMTP configurato, delegando a quest ultimo l onere della consegna al destinatario. Il server smtp che deve consegnare la mail analizza l indirizzo del destinatario e ricava il dominio di appartenenza, interrogando il record mx del DNS che ha configurato deduce a chi spedire il messaggio. Inizia quindi una connessione sulla porta 25 del server smtp indicato, se vengono superati eventuali controlli del server destinatario la mail può essere recapitata. I server di posta fanno largo uso di tecniche antispamming quali Reverse DNS Lookup e RBL (Real-Time Black List) ma questa è tutta un altra storia, torniamo al nostro record MX e analizziamo qualche esempio per capire meglio quali siano le opzioni.

26 Record MX > nasa.gov Server: ns2.interbusiness.it Address: Risposta da un server non di fiducia: nasa.gov MX preference = 10, mail exchanger = ndjsbar01.jsc.nasa.gov nasa.gov MX preference = 20, mail exchanger = ndmsbar03.ndc.nasa.gov ndjsbar01.jsc.nasa.gov internet address = ndmsbar03.ndc.nasa.gov internet address = In questo caso vengono indicati più record MX, uno con preference 10 e uno con preference 20, il server scelto è sempre quello con priorità più bassa, il secondo server sarà utilizzato come backup in caso di mancata connessione verso il server mx primario.

27 > playboy.com Server: ns2.interbusiness.it Address: Record MX Risposta da un server non di fiducia: playboy.com MX preference = 5, mail exchanger = mx.la.playboy.com playboy.com MX preference = 5, mail exchanger = mx2.chi.playboy.com mx2.chi.playboy.com internet address = mx.la.playboy.com internet address = > In questo caso vengono indicati più record MX con preference uguale a 5. Ad ogni interrogazione il primo della lista varia, avendo preference uguale, il traffico è quindi distribuito equamente tra i due server. Questo processo di bilanciamento ottenuto con i dns è chiamato ROUND ROBIN.

28 > set type=ns > alice.it Server: ns2.interbusiness.it Address: Record NS Risposta da un server non di fiducia: alice.it nameserver = dnsti.interbusiness.it alice.it nameserver = dnsts.interbusiness.it alice.it nameserver = dns3.nic.it dnsts.interbusiness.it internet address = dns3.nic.it internet address = dnsti.interbusiness.it internet address = > In risposta ottengo il name server autoritativo per il dominio

29 Record NS > server Server predefinito: dnsti.interbusiness.it Address: > set type=a > Server: dnsti.interbusiness.it Address: Nome: Address: La query verso un server autoritativo per il dominio in analisi restituisce una risposta priva del commento risposta da un server non di fiducia, che contraddistingue le risposte ottenute analizzando la cache. Riassumendo il server conservava l informazione nella cache, il server ha analizzato i propri record dns per fornire la risposta.

30 > set debug > Server: dnsti.interbusiness.it Address: Got answer: HEADER: opcode = QUERY, id = 13, rcode = NOERROR header flags: response, auth. answer, want recursion questions = 1, answers = 1, authority records = 3, additional = 2 QUESTIONS: type = A, class = IN ANSWERS: -> internet address = ttl = 3600 (1 hour) (output omitted) Nome: Address:

31 > server > Set debug > SendRequest(), len 30 HEADER: opcode = QUERY, id = 20, rcode = NOERROR header flags: query, want recursion questions = 1, answers = 0, authority records = 0, additional = 0 (output omitted) ANSWERS: -> type = A, class = IN, dlen = 4 internet address = ttl = 2415 (40 mins 15 secs) Risposta da un server non di fiducia: Nome: Address: >

32 Commenti Con questi esempi abbiamo imparato ad usare un pochino meglio nslookup. E importante capire se l informazione ottenuta è sicuramente corretta o meno, solo l informazione ottenuta dal name server autoritativo è da ritenersi degna di fiducia. Utilizzando il debug invece si è potuto notare che è il name server autoritativo a decidere quanto tempo gli altri dns conserveranno l informazione in cache, nell ultimo esempio si è potuto notare quando l informazione scadrà dalla cache del server In questo caso (TTL=1ora) se il gestore del server web decidesse di cambiare l indirizzo IP indicandolo al mantainer avrebbe un disservizio di massimo 1 ora, o meglio sicuramente dopo 1 ora tutti i name server di internet avrebbero l informazione nuova in cache. Il disservizio si può calcolare anche per il cambio Mantainer, alla voce Authority Record alice.it si nota che il TTL in questo caso è di un giorno. E importante dire che se entrambi i mantainer hanno le stesse informazioni e non c è variazione di record A/MX il disservizio è nullo. Nel caso di variazioni sarebbe utile qualche giorno prima diminuire il TTL concordandolo con il cliente finale, al fine di ridurre gli impatti sul business.

33 Zone DNS Una zona DNS è una parte dello spazio dei nomi, costituita da un dominio e i suoi sottodomini che non sono a loro volta delegati, che è quindi sotto una stessa gestione amministrativa. La gestione di una zona è delegata dalla zona superiore tramite dei record di tipo NS. Ad esempio, nella zona.it ci sarà una delega per la zona alice.it ai server DNS che la gestiscono. Per ragioni di ridondanza, una delega è tipicamente costituita da più record NS, che indicano che ciascuno dei server indicati contiene le informazioni per quella zona (è "autoritativo" per la zona). All'interno di una zona possono essere delegate delle zone di livello inferiore, ad esempio in alice.it potrebbero esistere deleghe per server.alice.it o per web.server.alice.it. I diversi server che sono delegati per una zona dovrebbero contenere le stesse informazioni, in modo che uno qualsiasi di questi possa rispondere ad una query per un record della zona. La replica è tipicamente basata su un server master (primario), sul quale vengono aggiornate le informazioni e uno o più server slave (secondari), che copiano le informazioni dal master quando necessario. L'operazione di copia di tutti i record di una zona dal master ad uno slave è detta zone transfer.

34 > server Server predefinito: j.root-servers.net Address: > set type=ns > alice.it it nameserver = NAMESERVER.CNR.it it nameserver = DNS.NIC.it (output omitted) NAMESERVER.CNR.it internet address = C DNS.NIC.it AAAA IPv6 address = 2001:760:4000:1f5::5 DNS.NIC.it internet address = M.DNS.it internet address = NS-IT.RIPE.NET AAAA IPv6 address = 2001:610:240:0:53:cc:12:109 NS-IT.RIPE.NET internet address = J.DNS.it internet address = S.DNS.it internet address = R.DNS.it AAAA IPv6 address = 2001:760:ffff:ffff::ca R.DNS.it internet address = >

35 > server Server predefinito: [ ] Address: > set type=ns > alice.it Server: [ ] Address: alice.it nameserver = dnsti.interbusiness.it alice.it nameserver = dnsts.interbusiness.it alice.it nameserver = dns3.nic.it dns3.nic.it internet address = dnsti.interbusiness.it internet address = C dnsts.interbusiness.it internet address = > Nella prima schermata è stato interrogato un root server, nella seconda è stato interrogato in Nameserver del CNR autoritativo per il cctld.it

36 Il Dominio ARPA ICAAN ha assegnato la gestione degli indirizzi IP ai RIR (Regional internet Registries). Attualmente esistono 5 RIR: APNIC (Asia e Pacifico), ARIN (Nord America e Africa), LACNIC (America Latina e Caraibi) RIPE (Europa, Asia Centrale) AFRINIC (Africa). Nei DNS esiste la registrazione dell indirizzo IP: i Provider inseriscono nel dominio ARPA gli IP che gli sono sati assegnati. E possibile quindi eseguire delle interrogazioni per scoprire chi ha in gestione un determinato IP e di conseguenza verificare il Provider di appartenenza, attenzione a non confondere Mantainer con Provider, non sempre le due figure coincidono. Questo tipo di interrogazione prende il nome di risoluzione inversa in inglese reverse lookup. Questa registrazione è a carico del Provider e non del Mantainer. Chi possiede un server di posta deve chiedere al Mantainer la registrazione dei record A,MX,PTR e al Provider la registrazione del reverse lookup sul dominio ARPA. Il rischio è di non superare i controlli di reverse lookup e di conseguenza non riuscire a spedire mail verso i domini che eseguono i controlli.

37 > server Server predefinito: [ ] Address: > set debug > in-addr.arpa > Questo tipo di interrogazione è eseguita per scoprire chi ha assegnato la gestione dell indirizzo IP. La sintassi può sembrare complicata, ma è solo questione di prenderci un po la mano. Prima di tutto è preferibile attivare il debug per avere un output completo. L interrogazione è eseguita inserendo l indirizzo ip al contrario facendolo seguire da in-addr.arpa. In questo caso l IP è diventato in-addr.arpa Utile per scoprire il Provider l interrogazione sulla classe C o B dell IP per esempio in-addr.arpa

38 > server Server predefinito: [ ] Address: > set d2 > in-addr.arpa Output Omitted QUESTIONS: in-addr.arpa, type = A, class = IN AUTHORITY RECORDS: -> in-addr.arpa type = SOA, class = IN, dlen = 69 ttl = (3 hours) primary name server = dnsti.interbusiness.it responsible mail addr = staffdns.telecomitalia.it Output Omitted Nome: in-addr.arpa

39 > server Server predefinito: [ ] Address: > set d2 > in-addr.arpa Output Omitted QUESTIONS: in-addr.arpa, type = A, class = IN AUTHORITY RECORDS: -> in-addr.arpa type = SOA, class = IN, dlen = 50 ttl = (3 hours) primary name server = ns1.albacom.net responsible mail addr = hostmaster.albacom.net ome: in-addr.arpa

40 > server Server predefinito: [ ] Address: >set d2 > in-addr.arpa Output Omitted QUESTIONS: in-addr.arpa, type = A, class = IN AUTHORITY RECORDS: -> in-addr.arpa type = SOA, class = IN, dlen = 50 ttl = (3 hours) primary name server = ns.telemedia.ch responsible mail addr = postmaster.telemedia.ch Output Omitted Nome: in-addr.arpa

41 Query ricorsiva In generale, per ottenere la risoluzione di un nome è necessario partire dalla radice, interrogare uno dei root servers nel dominio di primo livello, ottenere il server che lo gestisce, interrogarlo nel dominio di secondo livello, fino a raggiungere il server autoritativo per il nome desiderato. Questa tecnica è detta "ricorsione". Nella prima schermata è stato interrogato un root-server. E stato chiesto chi è autoritativo per il dominio alice.it, nella risposta si possono visualizzare i NS della Registration Autority Italiana. Nella seconda schermata è stato collegato un NS della RA, a fronte della stessa query la risposta indica i NS autoritativi per quel dominio, infatti noi oramai sappiamo che i root-server indicano chi gestisce il TLD mentre i DNS della RA indicano chi ha in concessione il dominio di secondo livello.it Con un pochino di pratica e usando la testa è possibile arrivare a tutte le risposte che servono nel nostro lavoro. Per esempio interrogando direttamente i name server della Registration Autority è possibile sapere se le pratiche di cambio mantainer sono state eseguite.

42 Ruolo Server DNS Un server DNS può essere configurato per assolvere ad una o più delle seguenti funzioni: server autoritativo per una o più zone, ovvero il server su cui sono configurati i dati di una zona, e che è delegato a gestirla tramite record NS inseriti nella zona superiore. Normalmente sono presenti più server autoritativi per una zona. Molte implementazioni permettono di modificare i dati di una zona solo su un server: primario - server autoritativo su cui vengono modificati i dati di una zona secondario - server autoritativo che copia i dati di zona da un primario server ricorsivo - il server che viene configurato in una popolazione di client, che si occupa di risolvere le query che riceve interrogando i server originali, e mantenendo una cache delle risposte ricevute. query forwarder - un server che viene configurato in una popolazione di client, che risolve le loro query non direttamente ma interrogando un server ricorsivo.

43 Implementazione Server DNS Il protocollo DNS è implementato da diversi software. Di seguito alcuni dei più diffusi: BIND (Berkeley Internet Name Domain), il nome del più comune demone DNS usato sui sistemi Unix. DJBDNS (Dan J Bernstein's DNS implementation) MaraDNS NSD (Name Server Daemon) PowerDNS DDNS (Dynamic Domain Name System) Il servizio DNS alla base dei servizi di directory Microsoft incluso nelle versioni server da Windows_2000 in poi. Il DNS utilizza il protocollo di trasporto UDP e la porta 53 per soddisfare le richieste di risoluzione provenienti dagli host. I server DNS effettuano gli zone transfer usando il protocollo di trasporto TCP e la porta 53. Questa porta viene usata anche quando una query ha una risposta molto lunga.

44 Il Resolver Il client analizza la propria cache per trovare la risposta Il client esegue una query non ricorsiva verso il server dns configurato nel proprio stack tcp/ip, delegando completamente l onere di ottenere una risposta per l FQDN desiderato. Il server DNS controlla la propria cache per trovare la risposta Il server dns interroga i root-server per conoscere il server autoritativo per il tld Il server dns interroga il ns autoritativo per il tld per conoscere il server autoritativo per il secondo livello Il server dns interroga il name server autoritativo per il secondo livello ed ottiene la risposta Il server dns fornisce la risposta al resolver del client. Conoscendo il numero di operazioni che devono essere intraprese per visualizzare una pagina web, c è di che stupirsi per la velocità con cui queste operazioni sono compiute.

45 C:\Documents and Settings\PValisi>ipconfig /displaydns Configurazione IP di Windows in-addr.arpa Nome record..... : in-addr.arpa. Tipo record..... : 12 Durata (TTL)..... : Lunghezza dati.... : 4 Sezione : Risposta Record PTR..... : localhost Nome record..... : Tipo record..... : 5 Durata (TTL)..... : 11 Lunghezza dati.... : 4 Sezione : Risposta Record CNAME.... : Nome record..... : Tipo record..... : 5 Durata (TTL)..... : 184 Lunghezza dati.... : 4 Sezione : Risposta Record CNAME.... : toggle. Con questo comando è possibile visualizzare la cache DNS interna del PC

46 C:\Documents and Settings\PValisi>ipconfig /flushdns Configurazione IP di Windows Svuotata la cache del resolver DNS. C:\Documents and Settings\PValisi> Nella cache ci sono anche le risoluzioni negative, cioè i nomi per cui non verrà mai eseguita una richiesta verso i server DNS. Sono le interrogazioni fatte ai DNS per nomi che non esistono, bisogna stare attenti quando si verifica il funzionamento di un server dns in fase di implementazione. Può essere utile saper eliminare il contenuto della cache senza dover riavviare il PC, nella cache è anche possibile visualizzare i TTL delle informazioni contenute. Anche in questo caso il TTL è ricevuto dal server DNS che interrogo (non l autoritativo), non è quindi un valore standard che posso dedurre.