DNSSEC
Le limitazioni e le vulnerabilità associate all’attuale architettura del servizio DNS possono essere utilizzate da un attaccante per compromettere le applicazioni Internet che di tale architettura fanno regolarmente uso.
Considerata la rilevanza del problema, nel 1994 è stato formato un gruppo di lavoro con l’obiettivo di revisionare completamente l’architettura DNS, introducendo meccanismi capaci di assicurare l’integrità e verificare la fonte delle informazioni scambiate tra client e server DNS.
Il processo di revisione del DNS è stato condotto cercando di mantenere completa la compatibilità con gli elementi DNS della preesistente architettura (client e server DNS nuovi devono poter coesistre con quelli già installati).
Per rendere possibile questa coesistenza la nuova architettura DNS (generalmente indicata con la sigla DNSSEC) non descrive un nuovo protocollo/servizio alternativo a quello in uso, ma semplicemente definisce nuovi tipi di Record e nuove modalità di interazione client/server attraverso le quali le nuove risorse possono essere utilizzate per assicurare integrità dei dati e autenticare l’origine dei messaggi.
Questo risultato viene ottenuto tramite uso di segnature digitali prodotte con algoritmi crittografici asimmetrici.
Le segnature digitali sono prodotte utilizzando la chiave privata dell’origine. Una singola chiave privata viene utilizzata per segnare tutte le informazioni relative a una zona (Record A, MX, NS, PTR).
Lo schema DNSSEC prevede anche la possibilità di autenticare i messaggi scambiati tra client e server per ogni singola risoluzione. In tal caso per la segatura viene utilizzata la chiave privata del nameservice coinvolto.
Le segnature vengono allegate a una DNS reply sfruttando il fatto che ogni campo del messaggio può contenere più valori.
Le segnature vengono ignorate da una componente non abilitata all’uso di DNSSEC, altrimenti sono utilizzate per verificare le informazioni contenute nel messaggio.
Per la verifica delle informazioni il client DNS deve disporre della chiave pubblica corrispondente alla chiave privata utilizzata nel processo di segnatura.
La chiave pubblica può essere veicolata all’interno del protocollo DNSSEC e può essere oggetto di certificazione.
L’architettura DNSSEC definisce i seguenti nuovi tipi di Record: KEY, CERT, SIG e NXT.
Un KEY Record definisce l’associazione tra un FQDN e la sua chiave pubblica.
Un CERT Record definisce l’associazione tra un FQDN e il certificato della chiave pubblica.
La segnatura di un qualsiasi Record viene mantenuta in un Record di tipo SIG.
Il Record NXT definisce invece uno speciale Record che permette di stabilire la non esistenza di un’informazione.
Attraverso elementi NXT, un server DNS può restituire al richiedente, evidenza esplicita della non disponibilità dell’associazione richiesta, che può essere memorizzata in cache locale al fine di evitare il ripetersi di altre DNS query con lo stesso oggetto.
L’architettura DNSSEC stabilisce che è preferibile, quando il messaggio di risposta non eccede la massima lunghezza prevista dal protocollo, inviare tutte le informazioni in un’unica DNS reply.
Se la risposta non può essere contenuta in un’unica DNS reply, è responsabilità diretta del client richiedere gli elementi informativi mancanti tramite DNS query successive.
In presenza di sistemi abilitati DNSSEC, gli elementi software che utilizzano il vecchio standard continuano a lavorare normalmente grazie al fatto che client e server DNS semplicemente ignorano il valore del campo RDATA associato a Record non riconosciuti.
