DNSSEC: uno standard per la ri­so­lu­zio­ne cer­ti­fi­ca­ta del nome di dominio

Ogni utente e ogni indirizzo del World Wide Web pos­sie­do­no un proprio e unico indirizzo IP, composto da una serie di numeri. Per evitare di vi­sua­liz­za­re l’indirizzo IP e inserire al suo posto sem­pli­ce­men­te 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 è re­spon­sa­bi­le per la ri­so­lu­zio­ne del nome di dominio ed è perciò uno dei più im­por­tan­ti 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 de­si­de­ra­to. La co­mu­ni­ca­zio­ne tra i name server e il client nasconde però un grave rischio per la sicurezza: non venendo ve­ri­fi­ca­ta l’identità del mittente, il de­sti­na­ta­rio non può de­ter­mi­na­re se la risposta DNS ricevuta provenga davvero dal server in­ter­ro­ga­to. Se un hacker si infiltra tra il name server e il client, può at­tri­bui­re al de­sti­na­ta­rio un indirizzo IP falso. Per con­tra­sta­re questa pro­ble­ma­ti­ca, è stato svi­lup­pa­to DNSSEC, che è attivo ad esempio per le esten­sio­ni di dominio .com.

Con Domain Name System Security Ex­ten­sions (DNSSEC) si indicano diversi standard di rete, che ag­giun­go­no al Domain Name System un’au­ten­ti­fi­ca­zio­ne della sorgente, ga­ran­ten­do così l’au­ten­ti­ci­tà e l’integrità dei dati. Dopo che la versione ori­gi­na­ria del DNSSEC del 1999 risultò inadatta per le reti di grandi di­men­sio­ni, ci sono voluti solo pochi anni, prima che le esten­sio­ni per la sicurezza del DNS venissero infine ri­la­scia­te nel 2005 nei tre RFC (Requests for Comments), cioè RFC 4033, RFC 4034 e RFC 4035, e di­ven­tas­se­ro quindi degli standard. Nel 2010 si è co­min­cia­to ad uti­liz­za­re questa tecnica anche per il livello di root, cioè sui 13 root name server re­spon­sa­bi­li per la ri­so­lu­zio­ne dei Top Level Domain.

DNSSEC si basa su un crip­to­si­ste­ma a chiave pubblica, un pro­ce­di­men­to di crit­to­gra­fia asim­me­tri­ca, in cui le parti coinvolte non si scambiano alcuna chiave segreta comune, ri­cor­ren­do 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 in­for­ma­zio­ni DNS, chiamate Resource Records, vengono dotate di una firma digitale. Grazie alla chiave pubblica, invece, i client ve­ri­fi­ca­no la firma e con­fer­ma­no così l’au­ten­ti­ci­tà della sorgente dati.

Ogni name server nel Domain Name System è re­spon­sa­bi­le per una precisa zona. Nel file apposito è enunciata una lista completa di tutti i Resource Records, che ne de­scri­vo­no 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 in­for­ma­zio­ne. In questo modo nascono i RRSIG Resource Records, che vengono così con­se­gna­ti ai Resource Record di base. Questa com­bi­na­zio­ne rimane invariata, in­di­pen­den­te­men­te venga salvata nella cache o trasmessa su un altro name server. Infine arriva al client ri­chie­den­te, che riesce a validare la firma con l’aiuto di un ri­so­lu­to­re DNS e di una chiave pubblica.

Per fa­ci­li­ta­re 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 sin­tat­ti­ca­men­te identica, che conferma l’au­ten­ti­ci­tà della ri­spet­ti­va chiave di zona. Un valore di hash della chiave per la firma viene me­mo­riz­za­to in una risorsa DNS della zona so­vraor­di­na­ta in qualità di Trusted Key, dove at­tra­ver­so il ri­so­lu­to­re viene resa nota solo la chiave pubblica della zona superiore, il livello di root.

I ri­so­lu­to­ri DNS sono dei moduli software del client, che possono ri­chia­ma­re le in­for­ma­zio­ni dai name server. Per ogni richiesta procedono in modo iterativo o ricorsivo. Nel primo caso il ri­so­lu­to­re riceve l’in­for­ma­zio­ne de­si­de­ra­ta o rimanda al name server suc­ces­si­vo e procede così fino a quando non avrà risolto l’indirizzo. I ri­so­lu­to­ri che lavorano ri­cor­si­va­men­te, chiamati anche Stub-Resolver, e che sono ge­ne­ral­men­te dei client comuni come i browser, inviano una richiesta ai ri­spet­ti­vi name server nella rete locale o nella rete del provider. Se l’in­for­ma­zio­ne richiesta non si trova nel database, la ri­so­lu­zio­ne completa dell’indirizzo rimane sotto la re­spon­sa­bi­li­tà di questo server, che invia a sua volta delle richieste iterative.

Per poter trarre vantaggio dal DNSSEC, è ne­ces­sa­rio un ri­so­lu­to­re da con­va­li­da­re, che può valutare le in­for­ma­zio­ni ag­giun­ti­ve generate. A questo scopo il resolver deve sup­por­ta­re il pro­to­col­lo per le esten­sio­ni Extension Me­cha­ni­sms for DNS (EDNS), perché solo così viene attivata la va­li­da­zio­ne nell’header del DNS. 

Fino ad ora la dif­fu­sio­ne del DNSSEC risulta ancora com­pli­ca­ta, so­prat­tut­to per via dei pre­re­qui­si­ti complessi, infatti la tecnica ne­ces­sa­ria deve essere sup­por­ta­ta sia sulle pagine del fornitore del servizio sia su quelle del vi­si­ta­to­re. I pro­prie­ta­ri dei domini dipendono stret­ta­men­te dal fatto che il registrar supporti e autorizzi la crit­to­gra­fia. Gli utenti non possono però incidere sulla pro­te­zio­ne di un sito tramite firme DNSSEC e hanno inoltre bisogno di un ri­so­lu­to­re per la convalida. Per poter uti­liz­za­re un DNS sicuro, è ne­ces­sa­rio gestire un proprio ri­so­lu­to­re come Bind, uti­liz­za­re un’esten­sio­ne per il browser come DNSSEC Validator o ricercare un provider che verifichi le firme DNSSEC. In ogni caso va sempre con­si­de­ra­to l’aspetto che DNSSEC firma e autentica solamente la ri­so­lu­zio­ne del nome di dominio, mentre i dati trasmessi non di­spon­go­no di alcuna pro­te­zio­ne. Una com­bi­na­zio­ne con i pro­to­col­li di tra­sfe­ri­men­to crit­to­gra­fa­ti, come il TLS, sarebbe quindi ob­bli­ga­to­ria.

In aggiunta si ri­scon­tra­no i seguenti problemi, che spiegano la ragione dell’ac­cet­ta­zio­ne ri­lut­tan­te di questa tecnica di sicurezza per il DNS:

• Per via dell’elevato sfrut­ta­men­to di un name server vengono fa­ci­li­ta­ti gli attacchi Denial-of-Service, che provocano la non di­spo­ni­bi­li­tà di un servizio.
• La Chain of Trust del DNSSEC è messa in pericolo dal fatto che ci sia la pos­si­bi­li­tà di di­stri­bui­re le chiavi pubbliche anche tramite il Domain Name System.
• Senza un proprio ri­so­lu­to­re DNS per la convalida, c’è l’even­tua­li­tà che avvenga un attacco tra il client e il name server del provider, anche nel caso in cui vengano ve­ri­fi­ca­te queste firme DNSSEC.

Ad altre vul­ne­ra­bi­li­tà, come il DNSSEC Walking, dove l’hacker riusciva a carpire il contenuto completo di una zona cer­ti­fi­ca­ta da DNSSEC, si è reagito ri­no­mi­nan­do le versioni più nuove del ri­so­lu­to­re non con un’etichetta di testo in chiaro per i diversi Resource Records, ma con un valore di hash.