DNSSEC: uno standard per la risoluzione certificata del nome di dominio

Ogni utente e ogni indirizzo del World Wide Web possiedono un proprio e unico indirizzo IP, composto da una serie di numeri. Per evitare di visualizzare l’indirizzo IP e inserire al suo posto semplicemente un nome di dominio come ionos.it per visitare un sito o inviare un’e-mail, è stato creato il Domain Name System (DNS). Il DNS è responsabile per la risoluzione del nome di dominio ed è perciò uno dei più importanti servizi di rete basati sull’IP. Composto da diversi name server (chiamati anche DNS Server), converte i nomi testuali in chiaro in indirizzi IP e permette così al client di stabilire il contatto desiderato. La comunicazione tra i name server e il client nasconde però un grave rischio per la sicurezza: non venendo verificata l’identità del mittente, il destinatario non può determinare se la risposta DNS ricevuta provenga davvero dal server interrogato. Se un hacker si infiltra tra il name server e il client, può attribuire al destinatario un indirizzo IP falso. Per contrastare questa problematica, è stato sviluppato DNSSEC, che è attivo ad esempio per le estensioni di dominio .com.

Con Domain Name System Security Extensions (DNSSEC) si indicano diversi standard di rete, che aggiungono al Domain Name System un’autentificazione della sorgente, garantendo così l’autenticità e l’integrità dei dati. Dopo che la versione originaria del DNSSEC del 1999 risultò inadatta per le reti di grandi dimensioni, ci sono voluti solo pochi anni, prima che le estensioni per la sicurezza del DNS venissero infine rilasciate nel 2005 nei tre RFC (Requests for Comments), cioè RFC 4033, RFC 4034 e RFC 4035, e diventassero quindi degli standard. Nel 2010 si è cominciato ad utilizzare questa tecnica anche per il livello di root, cioè sui 13 root name server responsabili per la risoluzione dei Top Level Domain.

DNSSEC si basa su un criptosistema a chiave pubblica, un procedimento di crittografia asimmetrica, in cui le parti coinvolte non si scambiano alcuna chiave segreta comune, ricorrendo invece ad una coppia di chiavi, composta da una chiava pubblica (Public key) e da una privata (Private key). Tramite le chiavi private, tutte le informazioni DNS, chiamate Resource Records, vengono dotate di una firma digitale. Grazie alla chiave pubblica, invece, i client verificano la firma e confermano così l’autenticità della sorgente dati.

Ogni name server nel Domain Name System è responsabile per una precisa zona. Nel file apposito è enunciata una lista completa di tutti i Resource Records, che ne descrivono la zona. Per questo motivo, ogni name server possiede anche una propria chiave di zona, con la quale riesce a rendere sicuri i Resource Records. La chiave pubblica della chiave di zona è integrata nel file di zona come DNSKEY Resource Record, mentre con la chiave pubblica viene firmata ogni singola informazione. In questo modo nascono i RRSIG Resource Records, che vengono così consegnati ai Resource Record di base. Questa combinazione rimane invariata, indipendentemente venga salvata nella cache o trasmessa su un altro name server. Infine arriva al client richiedente, che riesce a validare la firma con l’aiuto di un risolutore DNS e di una chiave pubblica.

Per facilitare la gestione del sistema di chiavi e generare una Chain of Trust (una catena di fiducia), oltre alla chiave di zona, esiste una chiave per la firma sintatticamente identica, che conferma l’autenticità della rispettiva chiave di zona. Un valore di hash della chiave per la firma viene memorizzato in una risorsa DNS della zona sovraordinata in qualità di Trusted Key, dove attraverso il risolutore viene resa nota solo la chiave pubblica della zona superiore, il livello di root.

I risolutori DNS sono dei moduli software del client, che possono richiamare le informazioni dai name server. Per ogni richiesta procedono in modo iterativo o ricorsivo. Nel primo caso il risolutore riceve l’informazione desiderata o rimanda al name server successivo e procede così fino a quando non avrà risolto l’indirizzo. I risolutori che lavorano ricorsivamente, chiamati anche Stub-Resolver, e che sono generalmente dei client comuni come i browser, inviano una richiesta ai rispettivi name server nella rete locale o nella rete del provider. Se l’informazione richiesta non si trova nel database, la risoluzione completa dell’indirizzo rimane sotto la responsabilità di questo server, che invia a sua volta delle richieste iterative.

Per poter trarre vantaggio dal DNSSEC, è necessario un risolutore da convalidare, che può valutare le informazioni aggiuntive generate. A questo scopo il resolver deve supportare il protocollo per le estensioni Extension Mechanisms for DNS (EDNS), perché solo così viene attivata la validazione nell’header del DNS. 

Fino ad ora la diffusione del DNSSEC risulta ancora complicata, soprattutto per via dei prerequisiti complessi, infatti la tecnica necessaria deve essere supportata sia sulle pagine del fornitore del servizio sia su quelle del visitatore. I proprietari dei domini dipendono strettamente dal fatto che il registrar supporti e autorizzi la crittografia. Gli utenti non possono però incidere sulla protezione di un sito tramite firme DNSSEC e hanno inoltre bisogno di un risolutore per la convalida. Per poter utilizzare un DNS sicuro, è necessario gestire un proprio risolutore come Bind, utilizzare un’estensione per il browser come DNSSEC Validator o ricercare un provider che verifichi le firme DNSSEC. In ogni caso va sempre considerato l’aspetto che DNSSEC firma e autentica solamente la risoluzione del nome di dominio, mentre i dati trasmessi non dispongono di alcuna protezione. Una combinazione con i protocolli di trasferimento crittografati, come il TLS, sarebbe quindi obbligatoria.

In aggiunta si riscontrano i seguenti problemi, che spiegano la ragione dell’accettazione riluttante di questa tecnica di sicurezza per il DNS:

• Per via dell’elevato sfruttamento di un name server vengono facilitati gli attacchi Denial-of-Service, che provocano la non disponibilità di un servizio.
• La Chain of Trust del DNSSEC è messa in pericolo dal fatto che ci sia la possibilità di distribuire le chiavi pubbliche anche tramite il Domain Name System.
• Senza un proprio risolutore DNS per la convalida, c’è l’eventualità che avvenga un attacco tra il client e il name server del provider, anche nel caso in cui vengano verificate queste firme DNSSEC.

Ad altre vulnerabilità, come il DNSSEC Walking, dove l’hacker riusciva a carpire il contenuto completo di una zona certificata da DNSSEC, si è reagito rinominando le versioni più nuove del risolutore non con un’etichetta di testo in chiaro per i diversi Resource Records, ma con un valore di hash.