DNS Spoofing Cache Poisoning

Transcript

1 Università degli Studi G. d Annunzio Facoltà di Economia Corso di Laurea Specialistica in Economia Informatica SEMINARIO PER IL CORSO DI RETI DI CALCOLATORI DNSS EC: cos è? Auttore: Fabrizio ROSSI Proffessore: Stefano BISTARELLI 1

2 Introduzione Il Domain Name System (DNS) è un database gerarchico distribuito, che associa nomi degli host a indirizzi IP. Esso permette ad un utente di trovare un sistema senza conoscere il suo indirizzo IP, risolvendo nomi di host in indirizzi IP, e organizzando l'interrete in domini. Ad esempio "pippo.sci.unich.it" è la specifica completa della macchina di nome pippo, "sci.unich.it" è il dominio sci, e "unich.it" è il dominio dell' Università di Chieti-Pescara. Sfortunatamente il DNS non è immune a problemi di sicurezza e l'esattezza delle informazioni contenute nel DNS è vitale per molti aspetti delle comunicazioni basate sul protocollo IP. Uno dei punti deboli per la sicurezza del DNS è il cosiddetto concetto del "dirottamento del dominio". Il problema è che gli indirizzi IP nel database del DNS vengono cambiati da host non autorizzati. Vi sono principalmente due modi per fare ciò: DNS Spoofing - "Ingannare" il server DNS con informazioni ritenute sicure, ma che in realtà non lo sono. Cache Poisoning - Falsare l' IP con un alto TTL, cosicchè il server DNS lo conserverà in cache per molto tempo. Le minacce che insidiano il DNS sono dovute in parte alla mancanza dell'autenticazione e al controllo dell'integrità dei dati mantenuti dal DNS e in parte ad altri protocolli che usano nomi di host come meccanismo di controllo di accesso. Per risolvere questi problemi, l' IETF formò un gruppo di lavoro (DNSSEC Working Group) per inserire nel protocollo esistente delle estensioni per la sicurezza e il nuovo protocollo risultante venne chiamato DNSSEC. L' architettura DNSSEC può aiutare a contrastare i due attacchi appena introdotti. Le estensioni di tale 2

3 architettura hanno come obiettivo quello di garantire la protezione del trasferimento dei dati del DNS, con l'ausilio della crittografia a chiave pubblica. Per comprendere la strategica rilevanza della sicurezza del DNS riferiamoci ad un ben noto caso di attacco al DNS. Nel Giugno del 1997, il dominio internic.net (il principale dominio per la registrazione dei nomi in Internet) venne rediretto al sito (Alternic è una associazione che si batte contro il monopolio dei domini in rete). Tutto iniziò dal fatto che molti utenti di Internet sentivano che il controllo dei domini di alto livello era contro lo spirito naturale di Internet. Eugene Kashpureff - il fondatore dell'alternic - dichiarò che era in corso una protesta contro la pretesa di Internic, ad avere il controllo dei domini.com,.org,.net ecc.., quando si supponeva invece che fossero di dominio pubblico. Conseguentemente nell'ottobre del 1997 Kasphureff fu arrestato per frode dalle autorità Canadesi e venne estradato negli Stati Uniti. Egli rappresentava la mente che organizzò l'attacco che provvedeva alla programmazione dei server di Internic ad instradare le informazioni verso il sito Alternic. Sostanzialmente era un tipo di attacco alla cache con informazioni contraffatte. Fino ad allora, nessun cambiamento essenziale era stato fatto per la sicurezza del DNS cosicchè questi tipi di attacchi sono tuttora possibili. Per di più il DNS è usato dalla maggior parte delle applicazioni e dei protocolli coinvolti nella comunicazione sulla rete. Indirizzi IP e Nomi mnemonici La famiglia di protocolli TCP/IP usa interi a 32 bit chiamati indirizzi IP (Internet Protocol) per identificare le macchine. Sebbene tali indirizzi forniscano una rappresentazione compatta e utile per specificare la sorgente e la destinazione nei pacchetti inviati attraverso un' interrete, gli utenti preferiscono assegnare alle macchine nomi facili da ricordare. 3

4 Lo schema di denominazione è interessante per due motivi: innanzitutto è stato usato per assegnare i nomi delle macchine in tutta l'internet mondiale; secondariamente, poiché usa un insieme geograficamente distribuito di server per tradurre i nomi in indirizzi, l'implementazione del meccanismo di traduzione dei nomi fornisce un esempio su vasta scala del paradigma client-server. I primi sistemi di elaborazione imponevano agli utenti di interpretare gli indirizzi numerici corrispondenti a oggetti come tabelle di sistemi e dispositivi periferici. I sistemi a condivisione di tempo portarono un miglioramento, consentendo di inventare nomi simbolici significativi sia per oggetti fisici (ad esempio, periferiche) sia per oggetti astratti (ad esempio, file). Un modello simile è emerso nel collegamento in rete dei computer. I primi sistemi supportavano le connessioni punto a punto e usavano indirizzi hardware di basso livello per specificare le macchine; il collegamento tra reti diverse ha introdotto l'indirizzamento universale e l'uso del software dei protocolli per tradurre indirizzi universali in indirizzi hardware di basso livello. Poiché la maggior parte degli ambienti di calcolo contiene più macchine, agli utenti servono nomi simbolici significativi per identificarle. La differenza fra indirizzo e nome è interessante. Un nome è semplicemente un identificatore che consiste in una sequenza di caratteri scelti da un alfabeto finito. I nomi sono utili solo se il sistema può tradurli in modo efficace nell'oggetto che rappresentano; per questo si pensa ad un indirizzo IP come a un nome di basso livello e si dice che gli utenti preferiscono i nomi di alto livello per le macchine. 4

5 Gestione dello Spazio dei Nomi Si deve garantire che ogni nome mnemonico identifichi univocamente un host, per cui si fissa una politica di gestione dello spazio dei nomi con un'autorità che garantisce l'applicazione della politica. Vi sono due possibili soluzioni: - Spazio dei nomi piatto (flat) - Spazio dei nomi gerarchico Spazio dei Nomi Piatto L'insieme originale dei nomi delle macchine usato in Internet formava uno spazio di denominazione piatto in cui ciascun nome consisteva in una sequenza di caratteri senza alcuna ulteriore struttura. Nello schema iniziale, un sito centrale, il NIC (Network Information Center) amministrava lo spazio di denominazione e stabiliva se un nuovo nome era appropiato (cioè proibiva i nomi osceni o nomi nuovi in conflitto con quelli esistenti). Il vantaggio principale di uno spazio di denominazione piatto è che i nomi sono brevi, mentre lo svantaggio è che non si può generalizzare questo schema a molte macchine per motivi sia tecnici che amministrativi. In primo luogo, poichè i nomi sono creati da un unico insieme di identificatori, le potenzialità di conflitti aumentano quando cresce il numero dei siti. In secondo luogo, poichè l'autorità di aggiungere nuovi nomi deve restare in un singolo sito, il carico amministrativo nel 5

6 sito centrale aumenta con il numero dei siti. Per capire la gravità del problema, si immagini un'interrete che cresce rapidamente con migliaia di siti, ciascuno dei quali è composto da centinaia di personal computer e stazioni di lavoro; ogni volta che qualcuno acquista e connette un uovo personal computer, il suo nome deve essere approvato dall'autorità centrale. Infine, poichè i collegamenti tra nomi e indirizzi cambiano spesso, il costo per mantenere copie corrette dell'elenco intero in ciascun sito è elevato e cresce se aumenta il numero dei siti; se invece il database dei nomi si trova in un singolo sito, è il traffico di rete verso quel sito ad aumentare. Una funzione associa ogni nome univocamente ad un indirizzo IP. Soluzione semplice ma con problemi. E' una gestione centralizzata e la tabella di conversione deve essere nota a tutti i computer della rete. Di conseguenza è difficile da gestire e da consultare quando la rete è grande 6

7 Spazio dei Nomi Gerarchico Lo spazio dei nomi viene diviso in zone dette domini e per ogni dominio viene definita un'autorità di dominio. Tutto ciò consente la decentralizzazione della gestione della tabella. L'autorità centrale si occupa solo di coordinare le autorità di zona. Ogni autorità di dominio è delegata a gestire l'assegnazione dei nomi della sua zona ed effettuare le corrispondenze tra indirizzi e nomi mentre ogni dominio può essere diviso in sottodomini affidati ad autorità di sottodominio. Le autorità di dominio sono autonome e lo stesso nome può essere usato in domini diversi. Idea della Struttura Gerarchica Per capire come dovrebbe essere diviso lo spazio di denominazione, si prenda in considerazione la struttura interna delle grandi organizzazioni. Al vertice, un direttore generale ha la piena responsabilità, ma poichè egli non può controllare tutto, l'organizzazione può essere divisa in vari reparti con un direttore a capo di ciascuno. Il direttore generale garantisce a ogni reparto un'autonomia all'interno di limiti specificati. Il responsabile di un particolare reparto può assumere o licenziare dipendenti, assegnare incarichi e delegare la sua autorità, senza ottenere l'autorizzazione diretta dal direttore generale. 7

8 Struttura dei Nomi Gerarchici Il DNS usa uno schema di denominazione gerarchico che rappresenta il nome gerarchico sotto forma di nome di dominio. Un nome gerarchico è formato da vari campi, detti etichette. Esse sono separate da punti e ognuna è assegnata da un'autorità ed identifica una zona. L'autorità garantisce che nella sua zona quel nome è unico. Ad esempio in si ha che: it è unico a livello globale unich è unico nel dominio it sci è unico nel dominio unich.it generale 1 Livello 2 Livello 3 Livello DNS Il Domain Name System implementa uno spazio dei nomi gerarchici per le interreti TCP/IP. Esso è utilizzato su Internet da molte altre applicazioni e protocolli che interagiscono con la comunicazione in un interrete (Web browsing, Ftp, Telnet, utilitiy TCP/IP su internet). E' basato su un database distribuito e provvede a specificare la sintassi dei nomi e le regole per delegare l'autorità sulle zone e ad implementare il sistema di calcolo distribuito per convertire nomi in indirizzi e viceversa. Le etichette dei vari livelli gerarchici sono separate con un "." e non c'è differenza fra maiuscole e minuscole. 8

9 I livelli gerarchici sono ordinati da destra a sinistra e il primo livello in genere è omesso (Es. sci.unich.it._) Struttura Gerarchica del DNS 9

10 Domini Top Level L'autorità centrale ha individuato un insieme di domini di primo livello. Essi sono stati individuati su base geografica o in base alla funzione: COM Organizzazioni commerciali EDU GOV MIL NET ORG INT Istituzioni didattiche Istituzioni statali (americane) Gruppi militari (americani) Centri di supporto di Internet Altre organizzazioni Organizzazioni internazionali IT, US, UK, DE, RU Codici di nazione (due lettere) Recentemente sono stati introdotti nuovi domini di primo livello che sono necessari per soddisfare esigenze commerciali e risolvere problemi di esaurimento dei nomi: BIZ INFO COOP attività commerciali siti informativi siti di cooperative 10

11 AERO attività aerospaziali MUSEUM musei NAME EU siti personali codice dell'unione Europea Name Server Oltre alle regole per la sintassi dei nomi e la delega dell'autorità, lo schema dei nomi di dominio include un sistema distribuito efficace, affidabile e di uso generale per la traduzione dei nomi in indirizzi. Distribuito in senso tecnico, il che significa che un insieme di server che funzionano insieme in più siti risolvono il problema della traduzione. Efficace nel senso che la maggior parte dei nomi può essere tradotta localmente, mentre solo pochi richiedono di generare traffico d'interrete. Di uso generale perchè non è limitato ai nomi delle macchine. Infine, affidabile per il fatto che nessun guasto di nessuna macchina impedirà al sistema di funzionare correttamente. Il meccanismo per la traduzione dei nomi in indirizzi consiste in sistemi cooperativi indipendenti chiamati Name Server. Un Name Server è un programma server che fornisce la traduzione da nome a indirizzo, traducendo da nomi di dominio in indirizzi IP. Spesso il software dei server è eseguito su un processore dedicato e la macchina stessa è chiamata Name Server. Ogni applicazione deve contattare un Name Server per risolvere un nome, e ogni autorità deve avere almeno un Name Server che gestisce la risoluzione dei nomi per 11

12 quel dominio ed essere totalmente responsabile del funzionamento dei suoi name server. I name server sono programmi server che mantengono informazioni sulla struttura ad albero del DNS e possono settare tali informazioni. Un Name Server puo' memorizzare in una cache qualsiasi informazione dell'albero dei domini ma in generale ha informazioni complete su una specifica parte del DNS. Questo significa che il Name Server ha autorità per quel sottodominio dello spazio dei nomi. Per tale motivo è chiamato authorative. Struttura Gerarchica dei Name Server I name server possono essere classificati secondo l'albero dei domini. Due name server collegati nell'albero si conoscono e si scambiano informazioni. I name server collegati possono comunicare in vari modi: possono risiedere sullo stesso host oppure essere collegati tramite un'interrete. Le relazioni nell'albero sono logiche e non fisiche. I name server associati alla radice dell'albero sono detti root name server. Per ogni nome conoscono un name server in grado di convertire quel nome. 12

13 I Root Name Server L' elenco dei 13 root name server attaccati l'11 Settembre dall'organizzazione di Bin Laden può essere ottenuto utilizzando il comando dig che è un evoluto comando di interrogazione DNS. L'output è il seguente: i.root-servers.net. 5d22h39m28s IN A e.root-servers.net. 5d22h39m28s IN A d.root-servers.net. 5d22h39m28s IN A a.root-servers.net. 5d22h39m28s IN A h.root-servers.net. 5d22h39m28s IN A c.root-servers.net. 5d22h39m28s IN A g.root-servers.net. 5d22h39m28s IN A f.root-servers.net. 5d22h39m28s IN A b.root-servers.net. 5d22h39m28s IN A j.root-servers.net. 5d22h39m28s IN A k.root-servers.net. 5d22h39m28s IN A l.root-servers.net. 5d22h39m28s IN A m.root-servers.net. 5d22h39m28s IN A Il tempo indicato è la validità della corrispondenza Nome <->Indirizzo IP. 13

14 Zone di Autorità Il sottoalbero di domini gestito da un name server costituisce la sua zona di autorità. Per ottenere una zona di autorità un'organizzazione deve soddisfare alcuni vincoli fissati dall'autorità centrale. Deve supportare tutti i protocolli standard per le interrogazioni e le risposte dal DNS, supportare tutti i protocolli standard per le interrogazioni e le risposte dal DNS e conoscere almeno un root name server. Inoltre l'organizzazione deve conoscere un name server per ciascuno dei suoi sottodomini e almeno due name server attivi che non hanno punti di guasto comune: un name server primario ed uno di backup. Un file di zona mantiene informazioni (che saranno rappresentate dai cosiddetti Resource Record- RR) per tutti i nomi di dominio associati con la zona. Più avanti vedremo il formato considerando un esempio. 14

15 Name Server per.unich.it Utilizzando il comando dig si ha il seguente output: ; <<>> DiG P1 <<>> ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 2574 ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ; IN A ;; ANSWER SECTION: IN CNAME settebbello.unich.it. settebbello.unich.it IN A ;; Query time: 23 msec ;; SERVER: #53( ) ;; WHEN: Fri Nov 28 11:57: ;; MSG SIZE rcvd: 72 ; <<>> DiG 8.3 <<>> Il tempo indicato è la validità della corrispondenza Nome <->Indirizzo IP. 15

16 Tipi di Nomi nomi. Il DNS consente di incorporare nello stesso sistema diverse gerarchie di Ad ogni elemento denominato, memorizzato nel sistema è associato un tipo: - Host - Casella postale - Un utente Quando si interroga il DNS si deve specificare che tipo di informazione si sta cercando e la famiglia di protocolli da utilizzare. Per default si assume che si stanno cercando i nomi degli host e che si usano i protocolli TCP/IP. 16

17 Risoluzione di un Nome La comunicazione con il NS è gestita dal Resolver. I Resolver sono programmi che estraggono le informazioni dai Name Server in risposta alle richieste del Client. Esso puo' variare dalla semplice System call (gethostbyname() gethostbyaddress()) a più complesse applicazioni con capacità di memorizzare informazioni in cache (nslookup, dig, host). Quando un programma utente deve risolvere un nome, esso richiama il Resolver che formula una query e contatta il suo Name Server locale che è preconfigurato (ad esempio in un file resolve.config). Questa query può essere sia Iterativa che Ricorsiva. Il Resolver fa parte dell'applicazione ed è invocato prima di contattare il livello di trasporto. Esempio : Un utente su A lancia il comando ftp B 1. A richiede al name server su S l'indirizzo di B 2. S risponde con l'indirizzo 3. A invia un messaggio FTP all'indirizzo di B 17

18 Non esiste per gli host un metodo standard per individuare un Name Server sulla rete locale. In genere il nome del name server è memorizzato in un file di configurazione oppure Il Name Server accetta solo richieste per nomi completamente qualificati. Il resolver permette all'utente di specificare nomi parziali provando ad estenderli per ottenere nomi completamente qualificati. Esso aggiunge al nome i suffissi specificati nel file di configurazione. Ad esempio a "ftp pippo" corrisponde "ftp pippo.sci.unich.it". Modalità di Risoluzione Il Name Server può utilizzare due diverse modalità per rispondere ad una interrogazione. - modalità ricorsiva: se non conosce la risposta interroga altri name server e poi passa la risposta al client. E' usata dai name server locali. - modalità iterativa: se non conosce la risposta passa al client l'indirizzo di un altro Name Server. E' usata dai name server di livello superiore. Il client sceglie la modalità di risposta settando un flag nel messaggio di richiesta. 18

19 Funzionamento del DNS L'applicazione interroga il name server locale: se il nome appartiene alla sua zona di autorità il Name Server locale risponde direttamente, altrimenti il Name Server locale interroga un root Name Server ottenendo in risposta il nome di un Name Server che ha l'autorità sul dominio di primo livello del nome richiesto. A questo punto il Name Server locale interroga il name server di primo livello e se il nome non può essere risolto si ottiene in risposta il nome di un Name Server di secondo livello. Si procede così, ricorsivamente fino alla risoluzione del nome. 19

20 Cache Ogni Name Server mantiene in una cache tutte le corrispondenze tra nomi e indirizzi di cui viene a conoscenza. Nell'esempio il Name Server locale mette in cache i name server di it, unich.it e sci.unich.it. Ogni corrispondenza viene mantenuta nella cache per un periodo fissato. Il tempo di validità è fissato dal Name Server che ha l'autorità su quel nome nel messaggio inviato agli altri name server. Per default il timeout è 2 giorni. 20

21 Formato dei messaggi Il formato dei messaggi consente a un client di porre più richieste in un singolo messaggio. Ogni domanda consiste nel nome di dominio per cui il client cerca l'indirizzo IP e il tipo di oggetto desiderato (ad esempio, indirizzo). Il server risponde restituendo un messaggio simile che contiene le risposte alle domande. Se non può soddisfare tutte le richieste, la risposta conterrà informazioni su altri name server che il client può contattare per ottenere le risposte. In un messaggio dei name server, ogni Answer Section, Authority Section e Additional I. Section consiste in un insieme di Resource Record (RR) che descrivono i nomi di dominio e le traduzioni (ogni record descrive un nome). Il formato di queste sezioni sarà mostrato più avanti. 21

22 I Resource Record quindi rappresentano l'associazione fra la struttura ad albero dello spazio dei nomi e i dati associati a questi nomi. Parametri IDENTIFICATION: consente di far corrispondere le risposte alle richieste. richiesta. PARAMETER: contiene vari flag per specificare il tipo di operazione - Richiesta/Risposta - Corrispondenza indirizzo/nome o viceversa - Messaggio troncato - Risposta proveniente dalla autorità o indiretta - Modalità ricorsiva disponibile - Modalità ricorsiva richiesta Gli altri campi specificano quanti record sono contenuti nelle quattro sezioni del messaggio. 22

23 Formato della Question Section QUERY DOMAIN NAME: contiene il nome da risolvere, rappresentato come sequenza di caratteri di lunghezza variabile. - Es. sci.unich.it 3 s c i 5 u n i c h 2 i t 0 QUERY TYPE: specifica il tipo di informazione richiesta. QUERY CLASS: specifica la classe di indirizzi. 23

24 Formato della Answer Section I primi tre campi sono uguali alla Question Section TIME TO LIVE: tempo di validità della risposta RESOURCE DATA: contiene la risposta del Name Server formata da vari record di risorse Stesso formato per le altre due sezioni Authority Section e Additional I. Section. 24

25 Tipi degli Oggetti Il DNS può essere utilizzato per implementare un qualsiasi spazio gerarchico dei nomi. Può implementare corrispondenze arbitrarie come ad esempio corrispondenze tra nomi e indirizzi IP e tra nomi e caselle di posta. Il tipo di un oggetto definisce il tipo di corrispondenza a cui si riferisce. Perché la Sicurezza del DNS è importante? Il DNS è utilizzato radicalmente da applicazioni Internet e sorgono quindi i problemi di sicurezza del DNS: I name server possono essere "truffati" facilmente e sono vulnerabili a molti tipi di attacchi (DoS, buffer overrun, replay). false. I Resolver possono essere indotti a "credere" in informazioni Misure di sicurezza (per esempio, ACLs) e altri meccanismi, rendono l'inganno, più difficile da compiere, ma non impossibile! Nel Giugno del 1997, Eugene Kashpureff (fondatore dell'alternic) ha reindirizzato il dominio internic.net ad alternic.net, mettendo in cache informazioni false, sul Name Server di Internic. 25

26 Destinazione errata indotta: Credere in false informazioni Si supponga il seguente scenario: un utente vuole connettersi ad un host A mediante un telnet client. Il telnet client chiede, attraverso un resolver, il Name Server locale per risolvere il nome A in un indirizzo IP. Esso riceve una informazione falsa e inizia una connessione TCP al server telnet sulla macchina A (almeno così crede). L'utente manda la sua login e password all'indirizzo falso. Ora la connessione salta, e l'utente ritenta l'intera procedura questa volta al corretto indirizzo IP dell'host A. Egli puo' ignorare ciò che è appena successo ma l'attaccante malizioso che si e' spacciato con il nome dell'host A, ha ora il controllo della login e della password dell'utente. Ciò è accaduto poichè i router attuali non hanno la capacità di respingere i pacchetti con falsi indirizzi sorgenti. Cosi' se l'attaccante può instradare pacchetti a chiunque, egli può indurre a farli considerare come pacchetti provenienti da un host fidato. Quindi, nel nostro caso, l'attaccante prevede il momento in cui viene mandata una query e inizia ad inondare il resolver con le sue false risposte. Con un firewall per la rete dell'utente, il resolver non sarebbe raggiungibile dal mondo esterno, ma il suo Name Server locale si. Cosi' se il Name Server locale può essere corrotto nel modo come descritto, allora l'attaccante può ridirezionare tali applicazioni con informazioni vitali, verso host sotto il suo controllo e catturare queste informazioni. Attenendosi a queste assunzioni, osserviamo che contemporaneamente a ciò, c'è la possibilità di un attacco Denial of Service (DoS). Nel caso di un tale attacco, se il Name Server può essere ingannato e l'host dell'attaccante può spacciarsi per il vero 26

27 Name Server, allora puo' maliziosamente imporre che alcuni nomi nel dominio, non esistano. Autenticazioni e Autorizzazioni basate sui nomi Alcune applicazioni diffuse su Internet, sfortunatamente, fanno uso di un meccanismo estremamente insicuro: L' Autenticazione e Autorizzazione basate sui nomi. Ad esempio : L'utente "joe" può loggarsi come l'utente "doe" al computer "host.mydomain.com" dal computer"otherhost.mydomain.com", se il file /etc/hosts.equiv contiene l'equivalenza tra l'utente locale "doe" e l'utente "joe@otherhost.mydomain.com" semplicemente sulla base dei loro nomi. I comandi Remoti sono stati progettati quando nacque Internet, per l'uso di reti locali fidate, dove tutti gli utenti erano conosciuti dall'amministratore di sistema, e la rete non era connessa al grande Internet. Sfortunatamente, i comandi remoti sopravvissero alla crescita di Internet e essi sono ancora presenti e usati in molte reti. 27

28 Se viene usata l'autenticazione basata sul nome, è possibile accedere ad una macchina remota semplicemente truffando il nome di un host. Anche se la rete locale è protetta da un firewall, tutti gli host che usano l'autenticazione basata sui nomi, rischiano poichè un attaccante può prendere il controllo di una singola macchina della rete protetta dal firewall. L'attaccante può monitorare il traffico di rete venendo a conoscenza dell'equivalenza usata in quella rete, e operare con l'indirizzo IP di un host equivalente (ad esempio compiendo un attacco DoS, o semplicemente aspettando lo shutdown della macchina).a questo punto l'host dell'attaccante è completamente equivalente all'host attaccato per tutti i computer che usano l'equivalenza remota. Attacco alle informazioni supplementari Questo è un altro lato della debolezza del DNS. Per motivi di efficienza il DNS fu progettato in modo da avere una sezione addizionale nel suo formato standard dei messaggi. Di conseguenza in alcuni casi quando un' informazione supplementare è considerata urgente da spedire, per velocizzare la risposta per una data query, essa è inclusa nella sezione addizionale. Per esempio, se viene interrogato il Name Server ns.mydomain.com, per recuperare il mail exchanger per il dominio comp-craiova.ro, il server risponde con un messaggio contenente mail.gate.comp-craiova.ro Nella sezione answer del messaggio e nella sezione additional viene incluso il nome e l'ip del Name Server autoritativo per il dominio comp-craiova.ro. Questa 28

29 informazione non era stata esplicitamente chiesta, piuttosto era stata messa in cache, per evitare una lunga ricerca per il name server autoritativo per quel dominio. Cosa è il DNSSEC? Cominciamo col vedere che cosa DNSSEC non è. DNSSEC non è la soluzione totale per la sicurezza. Non è una robusta difesa contro tutte le forme di attacco verso server e client. DNSSEC è la specifica di una estensione del DNS attraverso la definizione di Resource Records DNS aggiuntivi che possono essere usati dai client DNS per valicare l autenticità di una risposta del DNS, l integrità dei dati di una risposta DNS e dove la risposta indica che non esiste un tal dominio o una tale risorsa, anche questa informazione negativa può essere autenticata. In altre parole, DNSSEC è inteso proteggere client DNS da dati DNS falsi. Questa protezione non elimina la potenziale immissione di dati contraffatti in una transazione che coinvolge DNS, ma aggiunge informazioni addizionali alle risposte DNS per permettere al client di controllare che la risposta sia autentica. Per ottenere ciò, DNSSEC definisce alcuni nuovi records DNS (RR), ad esempio DNSKEY, RRSIG, NSEC, DS. Con il DNSSEC un amministratore di zona firma digitalmente una Resource Record Set (RRSet), e pubblica questa firma digitale. Per controllare una risposta DNS, un client DNSSEC può recuperare la relativa firma digitale del RRSet e controllare questa firma, usando la chiave pubblica, con il valore hash del RRSet calcolato localmente, quindi convalida la chiave pubblica dell amministratore di zona con un percorso gerarchico di firme che conduce alla fine ad un punto fidato. Se tutti questi controlli hanno successo allora il client ha una qualche convinzione che la risposta del DNS è completa ed autentica. DNSSEC implica differenti azioni per differenti ruoli. Per un amministratore di zona DNS, DNSSEC è essenzialmente il 29

30 processo di firma del RRSet con una chiave privata, pubblicando queste firme per ogni RRSet nel file di zona e pubblicando la chiave pubblica di zona nel file di zona. Inoltre l amministratore di zona deve avere la chiave pubblica di zona firmata dall amministratore padre di zona. Per un client DNS il DNSSEC è la capacità di eseguire un numero di controlli aggiuntivi sulle risposte DNS (controlli di autenticità e accuratezza). Per il DNS stesso il DNSSEC rappresenta essenzialmente un certo numero di RR addizionali che contengono le firme digitali delle informazioni DNS. DNS Record Resource Il DNSSEC introduce Quattro RRs addizionali allo scopo di assicurare sicurezza delle informazioni. Questi records sono: DNSKEY: Ogni zona DNS assicurata dal DNSSEC ha associata una coppia di chiavi privata e pubblica, così come generate dall amministratore di zona. La chiave privata rimane il segreto dell amministratore di zona. La chiave pubblica associata alla zona viene pubblicata nel file di zona nella forma di un RR DNSKEY. Un esempio di record DNSKEY per la zona example.com è (da RFC 4034): example.com IN DNSKEY ( AQPSKmynfzW4kyBv015MUG2DeIQ3 Cbl+BBZH4b/0PY1kxkmvHjcZc8no kfzj31gajiqky+5cptlr3buxa10h WqTkF7H6RfoRqXQeogmMHfpftf6z Mv1LyBUgia7za6ZEzOJBOztyvhjL 742iU/TpPSEDhm2SNKLijfUppn1U anvv4w== ) 30

31 Il TTL ha valore 1 giorno (86400 secondi). I flags hanno valore 256, indicando che si tratta di una chiave di zona. Il valore del protocollo è la costante 3. Il campo successivo rappresenta l algoritmo della chiave pubblica, ed il valore 5 indica cha si tratta di RSA/SHA1. Il valore RR è la codifica Base64 del valore della chiave pubblica. RRSIG: Un Resource Record set ((RRSet) è un insieme di RR in una zona DNS che condivide un nome comune, una classe comune e un tipo comune. Nel DNSSEC gli RRSet sono firmati digitalmente dall amministratore di zona. Questa firma è prodotta dalla generazione di un hash del RRSet, e poi criptando la hash usando la chiave privata dell amministratore di zona. Per una zona cha contiene dei resource record SOA, NS, A, MX, DNSKEY esistono almeno 5 distinti RRSet, ed ogni RRSet potrebbe avere il suo resource record RRSIG. Un esempio di record RRSIG per la zona example.com è: (da RFC 4034): ( host.example.com IN RRSIG A example.com. ojb1w6wngv+ldvq3wdg0mqkg5iehjrip8wtr PYGv07h108dUKGMeDPKijVCHX3DDKdfb+v6o B9wfuh3DTJXUAfI/M0zmO/zz8bW0Rznl8O3t GNazPwQKkRN20XPXV6nwwfoXmJQbsLNrLfkG J5D6fwFm8nN+6pBzeDQfsS3Ap3o= ) 31

32 I primi quattro campi specificano il nome del proprietario, TTL, Classe e tipo RR (RRSIG). Il campo successivo è il campo tipo covered ed il valore di A indica che questo è una firma di RRs A per host.example.com. Il campo successivo è l algoritmo di firma, ed il valore 5 indica che questo è firmato usando RSA/SHA1. Il valore 3 è il numero di etichette nel nome del proprietario originario. Il valore nel RRSIG RDATA è il valore originario del TTL per il RRSet A covered and sono le date di scadenza e iunizio, indicando che la firma RRSet è stata creata alle 17:31:03 del 20/02/2003. Il tag della chiave è 2642 e il nome del firmatario è example.com. Il rimanente del valore RR è l hash criptato del RRSet. NSEC: I records DNSKEY e RRSIG possono essere usati per testare l autenticità di una risposta DNS, dove esiste una risposta DNS, ma dove non ci sono dati autoritativi da ritornare allora l autenticazione richiede informazioni aggiuntive. Il RR NSEC può essere considerato come un record che copre un gap a scopi di autenticazione. L intero file di zona è organizzato in una forma canonica ed allora gli RR NSEC sono aggiunti per coprire questo gap. Se la zona contiene i nomi alpha e beta, allora ci sarà un record RR NSEC per alpha e uno per beta, indicando che non ci sono nomi definiti tra alpha e beta. In aggiunta il record NSEC definisce l insieme di tipi RR per questo nome di dominio. In risposta a una query se il nome non esiste nel file di zona, o il tipo RR non esiste per il nome in questione, allora viene restituito un record NSEC che evidenzia il fatto che il tipo RR non esiste. La ragione di questa forma di dati spanning, diverso da una più generica risposta no such name, è che questa forma di risposta può essere usata in caso di un attacco di tipo replay, affermando in maniera falsa che un nome non esiste, da momento che il record NSEC zinforma esplicitamente il client di questo gap. 32

33 4034): Un esempio di record NSEC per la zona example.com è il seguente (RFC alfa.example.com IN NSEC host.example.com. ( A MX RRSIG NSEC TYPE1234 ) I primi 4 campi testo specificano il nome, TTL, classe e tipo RR (NSEC). L elemento host.example.com è il successivo nome autoritativo dopo alfa.example.com in ordine canonico. I codici A, MX, RRSG, NSEC e TYPE1234 indicano che ci sono RRSet A, MX, RRSIG, NSEC e TYPE1234 associati con il nome alfa.example.com. I records NSEC possono essere usati per enumerare l intero contenuto di un file di zona. DS: Il punto cruciale nella crittografia delle chiavi pubbliche è quello del mezzo di validazione della chiave pubblica. Il problema della validazione della chiave pubblica di zona rimane aperto con i primi tre tipi di RR appena esaminati. Quindi il problema è: come può un client validare il record DNSKEY? L approcio usato dal DNSSEC è quello di usare una chain of trust all interno della struttura di delegazione gerarchica dello stesso DNS. Esclusa la zona root, ogni zona DNS ha una zona padre. Il RR del firmatario delegato (DS) contiene la hash della chiave pubblica della zona figlio. Questo record è firmato dalla chiave privata del padre di zona con un RR RRSIG. Per validare un DNSKEY di zona, vengono recuperati gli associati record DS, RRSIG e DNSKEY della zona padre. Il record DS è validato usando il DNSKEY per criptare il record RRSIG(DS) e quindi verificando che il risultato combacia con il record DS. Questa è la chiave pubblica di zona. Può essere confrontata con il record DNSKEY della zona in questione. La domanda ora è: come può essere validata questa chiave? Si applica lo stesso processo. Il processo di validazione ha termine nel momento in cui il client incontra una chiave fidata. La chiave fidata ideale dovrebbe essere il DNSKEY della zona root, ma in assenza di un tale punto fidato ogni client 33

34 DNSSEC deve configurare il suo sistema di validazioni fidate con punti di fiducia noti dove non esiste validazione padre. Un esempio di record DS per la zona example.com è il seguente (RFC 4034). dskey.example.com IN DS ( 2BB183AF5F A53B0A 98631FAD1A ) I primi 4 campi specificano il nome, TTL, classe e tipo RR (DS). Il valore è il tag chiave per il corrispondente RR DNSKEY dskey.example.com e il valore 5 denota l algoritmo usato da questo RR DNSKEY dskey.example.com. il valore 1 è l algoritmo usato per costruire l indice, e il resto del testo RDATA è l indice in esadecimale. Come lavora DNSSEC Quando richiesto dal client, DNSSEC aggiunge ulteriori dati alle risposte del protocollo DNS in modo da fornire dati addizionali per permettere al client DNS di autenticare i RRSet in risposta. Dal punto di vista della transazione tra un agente di query e un nameserver autoritativo, la variazione riguarda l aggiunta di una parte RRSIG ai dati in risposta dove c è una risposta che può essere generata e l uso di un RR NSEC oltre al RRSIG se non esiste un nameserver autoritativo per la risposta alla richiesta. Il client preleva la risposta in RRSet ed usa l algoritmo indicato nel record 34

35 RRSIG per generare l hash dei dati. Il client deve anche avere il record DNSKEY di zona. Questa operazione permette al client di verificare che l hash dei dati RRSet coincidono con l hash del RRSIG decriptato. Risultati dall utilizzo di DNSSEC Il DNSSEC comporta alcune variazioni sostanziali nell organizzazione del DNS soprattutto a livello di performance. La grandezza media del messaggio di rispota del DNS aumenta, dovuto all aggiunta dei record di firma collegati ai records di risposta. Inoltre quando un messaggio va oltre l ampiezza di un messaggio UDP deve essere troncato, causando quindi perdita della query e rivolgersi pertanto al TCP. Il numero delle transazioni DNS aumenta dovuto al fatto che vengono effettuate ulteriori query per ottenere i records relativi alle chiavi pubbliche di zona per costruire le chain of trust. Il file di zona aumenta in grandezza dovuto all aggiunta di records addizionali DNSSEC. Il maggior contributo a questo fenomeno è dovuto ai records NSEC e RRSIG. Il client spende tempo aggiuntivo per validare i dati firmati e le chiavi pubbliche. Il server deve generare nuove firme relativamente ad ogni variazione di RRSet. RFC 3383 fa notare che il comportamento di una piccola richiesta che genera una risposta corposa è stato usato per apportare un denial of service. 35

36 In realtà un DNS con DNSSEC può diventare un veicolo ideale per questa forma di attacco. Con l'rfc 2065 e dopo con la sua successiva 2535, l'estensione per la sicurezza del DNS fu ammessa e standardizzata in maniera formale, con il gruppo di lavoro DNSSEC IETF. Il primo passo è provvedere all'autenticazione dei dati per gli RR che vanno avanti e indietro in Internet. Con l'autenticazione si ottenne anche integrità dei dati e l'autenticazione dei dati sorgenti. L'autenticazione è ottenuta per via della firma digitale crittografica. Gli algoritmi a chiave pubblica usati per l'autenticazione nel DNSSEC sono MD5/RSA e DSA. Le firme digitali generate con gli algoritmi a chiave pubblica hanno il vantaggio che chiunque, avendo la chiave pubblica le può verificare. Ogni messaggio di RR nel DNS scambiato può essere firmato digitalmente provvedendo così all' autenticazione dei dati origine e all'integrità del messaggio. In aggiunta, DNSSEC definisce nuovi RR per la memorizzazione delle chiavi pubbliche nel DNS. Questi RR possono essere usati per distribuire le chiavi coinvolte per la sicurezza del DNS stesso e anche per distribuire chiavi associate con nomi per supportare altri protocolli come IPSEC. Negli esempi riportati sono ancora indicati RR KEY (ora utilizzato solo per TKEY), RR NXT ora obsoleto (in pratica sostituito da NSEC) e RR SIG sostituito da RRSIG. Per il DNS standard, abbiamo gli RR nel file dati di zona (figura 1). 36

37 Abbiamo un semplice file dati di zona nel quale sono presenti gli RR che specificano l'inizio dei parametri (SOA), il Name Server (NS), il mail exchanger (MX) per il dominio mydomain.com (linee 1-9). Abbiamo anche l'ip per il Name Server, l'ip del mail exchanger e l'ip di un host in mydomain.com dato dal RR di tipo A. Quando DNSSEC è usato, il file di zona è modificato come presentato in figura 2. 37

38 Line 1: 2: 3: 4: 5: 6: 7: 8: 9: 10: 11: 12: 13: 14: 15: 16: 17: 18: 19: 20: 21: 22: 23: 24: 25: 26: 27: 28: 29: 30: 31: 32: 33: 34: 35: 36: 37: 38: 39: 40: 41: 42: 43: 44: 45: 46: 47: 48: 49: 50: 51: 52: 53: mydomain.com. mydomain.com. mydomain.com. mydomain.com. mydomain.com. mydomain.com. mydomain.com. mydomain.com. mydomain.com. host securens servmail IN IN IN IN IN IN IN IN IN IN IN IN IN IN IN IN IN IN IN IN IN IN IN SOA SIG SIG NS SIG MX SIG NXT SIG A SIG NXT SIG A SIG KEY SIG NXT SIG A SIG NXT SIG Zone Data File securens.mydomain.com. sysadmin.mydomain.com. ( ;serial number ;refresh time 1800 ;retry time ;expire time ;TTL ) ;Cl = 2 SOA (;RR type, alg. type, TTL ;SIG expiration time ;SIG inception time mydomain.com. ;key tag, signer s name ama12lanfghi/ukl... );the signature AXFR (;zone transfer signature mydomain.com. rema121anfasdc... );the signature securens.mydomain.com. NS ( mydomain.com. BmmAR12LenCDFsS... );the signature 10 servmail.mydomain.com. MX ( mydomain.com. kjldfievdsl... ) host.mydomain.com. NS SOA MX SIG NXT NXT ( mydomain.com. LfDS5Almcds21... ) A ( mydomain.com. securens.mydomain.com. A SIGNXT NXT mydomain.com. LdSD+/34mCDGfy... ) A ( mydomain.com. HgfT4K08VBDliv... ) KmOP/sd7REvb3Kii... ;the securens public key KEY ( mydomain.com. OrT2M09/xZE... ) servmail.mydomain.com. A SIG KEY NXT NXT mydomain.com. TmBP/ = s4hrvevbla A ( mydomain.com. mydomain.com. A SIG NXT NXT ( mydomain.com. Al0Va/fuT23mRs... ) Figura 2 : Lo stesso file di zona nel DNSSEC RR in figura 2. Prima di tutto possiamo vedere che per ogni RR di figura 1 abbiamo un SIG 38

39 zona. Ogni RR nel vecchio file di zona è firmato mediante la chiave privata della L' RR SIG lega crittograficamente un insieme di RR al firmatario e ad un intervallo di validità. Nel nostro esempio, l'intervallo di validità della firma è segnato dai valori (il tempo di scadenza 13:30:34 del 23 Ottobre 1999) e (il tempo in cui venne firmata la zona 13:30:46 del 23 Settembre 1999). Notiamo anche il differente RR SIG che appare in linea 13 di figura 2. Si riferisce al RR AXFR. Questo record non era presente in figura 1. Questo SIG permette di assicurare efficientemente l'integrità e la sicurezza dei trasferimenti della zona. La firma AXFR deve essere calcolata dopo che tutti gli RR nel file di zona sono firmati e inseriti. Infatti esso appartiene a tutta la zona non solo al nome della zona. La firma AXFR è recuperata come parte di un trasferimento di zona. Le firme degli RR e dei file di dati di zona, sono generati da uno speciale programma: The zone signer (il firmatario di zona). Il compito di fare la firma è demandato all' amministratore di zona. Il programma legge tutti i dati nel file di zona, li organizza in un ordine canonico, sistema i relativi record in gruppi, li firma e aggiunge i RR SIG e NXT nei loro posti appropriati. Infine questa informazione è scritta in un file che sarà usato dopo dal name server primario di zona. L'uso del RR NXT serve per autenticare la non esistenza di un RR. Come si può vedere, la struttura del file diventa circolare, in modo che se qualcuno guarda 39

40 l'ultimo NXT RR nella zona, vedrà che punta all' RR del nome mydomain.com che è nella parte iniziale del file. E' anche importante osservare che i nomi nella zona sono sistemati in un ordine canonico (con una sola eccezione: il nome di zona). Il NXT RR gioca il ruolo di linkare i nomi successivi nel file di zona. Come si vede in fig.2, per ogni nome nel file di zona abbiamo un NXT RR che punta al prossimo nome nella zona e nell'ultima colonna c'è anche un elenco (un riepilogo) di tipi di RR disponibili per quel nome. Per esempio, il NXT RR per mydomain.com punta a host.mydomain.com (prossimo nome nella zona) e specifica come tipi esistenti di RR per mydomain.com i tipi NS, SOA, MX, SIG e NXT. Questo è necessario per fornire un meccanismo mediante il quale tutti possono verificare la non-esistenza di un nome in una zona o la non-esistenza di un tipo per un nome esistente. Se un Resolver chiede un nome che non esiste nel file di zona, il Server DNSSEC autoritatrivo per quel dominio, ritornerà una SOA RR firmata e anche una NXT RR che autenticherà la non-esistenza di quel nome. Per esempio, se un resolver chiede per il nome newhost.mydomain.com la A RR(indirizzo), il name server autoritativo per il dominio mydomain.com, cioè securens.mydoamin.com, ritornerà una SOA RR firmata, insieme con il NXT RR di host.mydomain.com (cioè host IN NXT securens.mydomain.com A SIG NXT). Cosa significa ciò? L'interpretazione è che tra host.mydomain.com e securens.mydomain.com non ci sono altri nomi nel file di zona e solo A, SIG e NXT RR sono disponibili per quel nome (cioè host.mydomain.com) 40

41 Quindi il resolver verificando la firma di NXT RR può facilmente dedurre che il nome richiesto non esiste e solo questi tre tipi sono disponibili per quel nome. In breve il NXT RR è usato per indicare in modo sicuro che gli RR con un nome proprietario in un determinato intervallo di nomi non esiste in una zona e per indicare quali RR sono associati ad un'esistente nome nella zona. Il NXT RR deve essere automaticamente elaborato e aggiunto quando si firma la zona e devono essere firmati con la chiave della zona. Integrità dei dati ed autenticazione dell origine L autenticazione è effettuata associando le firme digitali, generate crittograficamente, con insiemi di Recource Record [ RRset ] nel DNS. Una singola chiave privata viene, generalmente, utilizzata per autenticare un intera zona, ma potrebbero esistere chiavi private multiple per differenti algoritmi, differenti firme e così via. Se un resolver sicuro ottiene una chiave pubblica della zona di cui si fida può autenticare i dati autenticati, letti a partire da quella zona, se è autorizzato a farlo. Il metodo più sicuro per garantire che una zona sia sicura è tenere le chiavi private off-line e rifirmare tutti i record della propria zona periodicamente, anche se questa operazione non è sempre possibile. Nel caso, ad esempio, in cui si dovessero fare aggiornamenti dinamici le chiavi private devono essere necessariamente on-line. Ogni informazione è identificata come resource record. Tale risorsa è distinguibile in base ad un campo che ne identifica il tipo associato. Le chiavi per l autenticazione dell origine dei dati sono associate ad una zona e non al server che mantiene le copie dei dati. Questo metodo è necessario perché qualora il server secondario risultasse compromesso o persino quello primario, se le 41

42 chiavi fossero tenute off-line, il resolver non potrebbe determinare se un dato è genuino. Un resolver può apprendere la chiave pubblica di una zona sia leggendola dal DNS sia avendola configurata staticamente. Per potersi fidare di una chiave pubblica letta dal DNS, la chiave stessa deve essere firmata con una chiave di cui il resolver si fida. Il resolver deve essere configurato con almeno una chiave pubblica che autentica una zona come punto d'inizio. A questo punto può leggere le chiavi pubbliche delle altre zone, se le zone intermedie nell'albero del DNS sono sicure e le loro chiavi (firmate) accessibili. Il fatto di aggiungere l autenticazione dell origine dei dati e l'integrità non richiede cambiamenti al protocollo DNS presente al di là di aggiungere il contrassegno del tipo di risorsa necessario per la distribuzione della chiave. Questo servizio può essere supportato dal resolver esistente e dall'implementazione di un server di caching fatta in modo che possano supportare i tipi di risorsa addizionali. L'unica eccezione è che i CNAME2 riferiti in una zona sicura non possono essere autenticati se provengono da un server non sicuro. Autenticazione sulle transazioni e sulle risposte Il servizio di autenticazione dell'origine dei dati, fornisce garanzia sulla correttezza dei resource record [RR] o, se non dovessero esistere, sulla non esistenza di questi. 42

43 Se i campi dell'intestazione di una risposta sono falsati da un server non autorizzato, non c'è molto da fare, ma è possibile aggiungere autenticazione alle transazioni. Questa autenticazione garantisce ad un resolver almeno di ricevere il messaggio dal server che ha effettivamente interrogato e che la risposta è relativa alla richiesta che ha effettivamente spedito. La risposta può essere accompagnata da un SIG resource record, aggiunto alla fine della risposta, che è la firma digitale. Questa, firma tutta la catena di risoluzioni e la richiesta del resolver. Anche le richieste possono essere autenticate includendo uno speciale SIG resource record alla fine della stessa. Per quanto riguarda l'autenticazione delle richieste, non essendo ancora implementato ovunque DNSSEC, potrebbero verificarsi degli errori o non funzionare affatto con servizi DNS obsoleti. É comunque presente nel protocollo DNSSEC questa sintassi per poter effettuare richieste di update dinamico sicure oppure per utilizzi futuri che richiederanno una forma di autenticazione. CACHE POISONING Consideriamo ora l' attacco che evidenzia sempre più la necessità di un meccanismo di autenticazione più forte. Esso viene chiamato : "Cache poisoning" (Avvelenamento della cache). 43

44 44

45 45

46 46

47 47

48 DNSSEC Chain of Trust Quando un resolver riceve una risposta dal DNSSEC name server, deve iniziare la verifica delle firme associate agli RR ricevuti come risposta. Ma la verifica della firma dice solo che il messaggio è stato correttamente firmato. Non dice nulla circa la falsità dei dati. Così, abbiamo solo l'integrità dei dati, ma non l'autenticazione dell'origine dei dati. Il resolver deve in qualche modo determinare se la chiave KEY con cui sono stati firmati gli RR è sicura e se è autorizzato a firmare questi RR. Per fare questo deve costruire una catena verificata crittograficamente di KEY e SIG RR verso un punto di fiducia. 48

49 Ogni KEY RR è firmato con la chiave del padre di zona. Quindi per verificare il SIG RR di una KEY, il resolver deve recuperare informazioni sul padre delle zone. Vediamo un esempio. Supponiamo di voler recuperare l'indirizzo RR di host.mydomain.com. Il resolver dovrebbe fare una query al name server per il nome e il tipo richiesto. Quando riceve la risposta, si ha un A RR per il nome host.mydomain.com e anche un SIG RR per l'a RR insieme con un KEY RR contenente la chiave pubblica che verifica la firma. Il problema è: si puo' aver fiducia in quella chiave pubblica? Il processo di autenticazione è basato sul fatto che la chiave pubblica Root è sicura dal momento che è preconfigurata nel resolver. Assumiamo che gli RR di mydomain.com (posti sulla macchina securens.mydomain.com) erano firmati con la chiave privata di mydomain.com. La chiave pubblica (memorizzata in KEY RR recuperata da noi) è anche firmata, ma dal dominio padre, cioè con la chiave privata di com. Per verificarla, si deve recuperare anche la chiave pubblica di "com". Nella stessa maniera, la chiave pubblica di com è firmata dalla chiave privata root. Dopo le verifiche della chiave pubblica di com (con la chiave pubblica root in possesso), si deve raggiungere un punto nell'albero di cui ci si può fidare. Quindi, si può concludere che la pubblic KEY di mydomain.com può essere sicura. In questo modo, un resolver dovrebbe "imparare" a fidarsi delle chiavi verificando le loro firme passando attraverso queste catene di KEY e SIG RR. 49