How DNSSEC Works

The domain name system (DNS) is the phone book of the Internet: it tells computers where to send and retrieve information. Unfortunately, it also accepts any address given to it, no questions asked.

Email servers use DNS to route their messages, which means they’re vulnerable to security issues in the DNS infrastructure. In September 2014 researchers at CMU found email supposed to be sent through Yahoo!, Hotmail, and Gmail servers routing instead through rogue mail servers. Attackers were exploiting a decades-old vulnerability in the Domain Name System (DNS)—it doesn’t check for credentials before accepting an answer.

The solution is a protocol called DNSSEC; it adds a layer of trust on top of DNS by providing authentication. When a DNS resolver is looking for blog.cloudflare.com, the .com name servers help the resolver verify the records returned for cloudflare, and cloudflare helps verify the records returned for blog. The root DNS name servers help verify .com, and information published by the root is vetted by a thorough security procedure, including the Root Signing Ceremony.

Una breve introduzione a DNSSEC

DNSSEC crea un sistema di nomi di dominio sicuro aggiungendo le firme crittografiche ai record DNS esistenti. Queste firme digitali vengono memorizzate nei nameserver DNS insieme a tipi di record più comuni, come A, AAAA, MX, CNAME, ecc. Controllando la firma associata, è possibile verificare che il record DNS richiesto provenga dal suo nameserver autoritativo e che non sia stato modificato durante il percorso, a differenza di un record falso iniettato in un attacco man-in-the-middle.

Per facilitare la convalida della firma, DNSSEC aggiunge alcuni nuovi tipi di record DNS:

  • RRSIG - Contiene una firma crittografica
  • DNSKEY - Contiene una chiave di firma pubblica
  • DS - Contiene l'hash di un record DNSKEY
  • NSEC e NSEC3 - Per il denial-of-existence esplicito di un record DNS
  • CDNSKEY e CDS - Per una zona figlio che richiede aggiornamenti ai record DS nella zona genitore.

L'interazione tra i record RRSIG, DNSKEY e DS, così come il modo in cui essi aggiungono un livello di fiducia al DNS, è ciò di cui parleremo in questo articolo.

RRSet

Il primo passo per proteggere un'area con DNSSEC consiste nel raggruppare tutti i record dello stesso tipo in un insieme di dati detto RRSet (Resource Record Set). Ad esempio, se nell'area sono presenti tre record AAAA dello stesso label (ad es. label.example.com), verrebbero tutti raggruppati in un unico RRSet "AAAA".

diagramma rrset

In realtà, è questo RRSet completo che viene firmato digitalmente, a differenza dei singoli record DNS. Naturalmente, questo significa anche che è necessario richiedere e convalidare tutti i record AAAA da una zona con lo stesso label, invece di convalidarne uno solo.

Zone-Signing Keys

Ciascuna zona in DNSSEC è munita di una coppia di chiavi, denominate Zone Signing Keys (ZSK): la parte privata della chiave firma digitalmente ogni RRRset nella zona, mentre la parte pubblica ha il compito di verificare la firma. Per abilitare DNSSEC, un operatore di zona crea delle firme digitali per ciascun RRset utilizzando la ZSK privata, e le archivia nel proprio nameserver come record RRSIG. Ciò equivale a dire: "Questi sono i miei record DNS, provengono dal mio server e dovrebbero apparire così".

diagramma zone signing keys 1

Tuttavia, questi record RRSIG sono inutili a meno che i resolver DNS non dispongano di un metodo per verificare le firme. L'operatore di zona deve inoltre rendere disponibile la propria ZSK pubblica aggiungendola al proprio nameserver in un record DNSKEY.

Quando un resolver DNSSEC richiede un particolare tipo di record (ad es. AAAA), il nameserver restituisce anche il corrispondente RRSIG. Il resolver può quindi estrarre il record DNSKEY contenente la ZSK pubblica dal nameserver. Insieme, RRSet, RRSIG e la ZSK pubblica possono convalidare la risposta.

diagramma zona signing keys 2

Se ci fidiamo della zone-signing key nel record DNSKEY, allora possiamo fidarci di tutti i record nella zona. E se invece questa chiave fosse compromessa? Abbiamo bisogno di trovare un modo per convalidare la ZSK pubblica.

Key Signing Keys

Oltre a una zone-signing key, i nameserver DNSSEC dispongono anche di una key-signing key (KSK). La chiave KSK convalida il record DNSKEY esattamente nello stesso modo in cui la nostra chiave ZSK ha protetto il resto dei nostri RRSet nella sezione precedente: firmando la chiave ZSK pubblica (memorizzata in un record DNSKEY) e creando un RRSIG per il DNSKEY.

diagramma key signing keys 1

Proprio come la ZSK pubblica, il nameserver pubblica la KSK pubblica in un altro record DNSKEY, che ci dà il RRSet DNSKEY mostrato sopra. Sia la KSK che la ZSK pubbliche sono firmate dalla KSK privata. I resolver possono quindi utilizzare la KSK pubblica per convalidare la ZSK pubblica.

La convalida per i resolver ora si configura in questo modo:

  • Richiedere il RRSet desiderato, che restituisce anche il record RRSIG corrispondente.
  • Richiesta dei record DNSKEY contenenti la ZSK pubblica e la KSK pubblica, che restituisce anche il RRSIG per il DNSKEY RRSet.
  • Verifica del RRSIG del RRSet richiesto con la ZSK pubblica.
  • Verifica del RRSIG del RRSet DNSKEY con la KSK pubblica.
diagramma key signing keys 2

Naturalmente, il RRSet DNSKEY e i corrispondenti record RRSIG possono essere memorizzati nella cache, in modo che i namserver DNS non vengano costantemente bombardati da richieste superflue.

Perché usiamo chiavi separate di zone-signing e key-signing? Come discuteremo nella prossima sezione, è difficile sostituire una chiave KSK obsoleta o compromessa. Cambiare la ZSK, invece, è un'operazione molto più semplice. Questo ci permette di utilizzare una chiave ZSK più piccola senza compromettere la sicurezza del server, riducendo al minimo la quantità di dati che quest'ultimo deve inviare assieme ad ogni risposta.

Ora abbiamo stabilito la fiducia all'interno della nostra zona, ma il DNS è un sistema gerarchico, e le zone raramente operano in modo indipendente. A complicare ulteriormente le cose, la chiave di key-signing si firma da sola, e ciò non apporta alcuna fiducia addizionale. Abbiamo pertanto bisogno di un modo per collegare la fiducia nella nostra zona con la sua zona genitore.

Record di delegazione del firmatario

DNSSEC introduce un record di delegazione del firmatario (DS) per consentire il trasferimento di fiducia da una zona genitore a una zona figlio. Un operatore di zona esegue l'hash del record DNSKEY contenente la KSK pubblica e lo assegna alla zona genitore per la pubblicazione come record DS.

diagramma record delegation signer

Ogni volta che un resolver viene ridirezionato a una zona figlio, la zona genitore fornisce a sua volta un record DS. Questo record DS è il modo in cui i resolver sanno che la zona figlio è abilitata al DNSSEC. Per verificare la validità della KSK pubblica della zona figlio, il resolver esegue l'hash e lo confronta con il record DS del genitore. Se corrispondono, il resolver può presumere che la KSK pubblica non sia stata manomessa, il che significa che può considerare attendibili tutti i record nella zona figlio. Questo è il modo in cui viene stabilita una catena della fiducia in DNSSEC.

Si noti che qualsiasi modifica nella KSK richiede anche una modifica nel record DS della zona genitore. La modifica del record DS è un processo in più fasi che può finire per corrompere la zona, se viene eseguito in modo errato. Innanzitutto, il genitore deve aggiungere il nuovo record DS, quindi deve attendere che il TTL per il record DS originale scada, prima di rimuoverlo, ed è questo il motivo per cui è molto più facile cambiare le chiavi zone-signing key rispetto alle key-signing keys.

Denial of Existence esplicito

Se al DNS viene chiesto l'indirizzo IP di un dominio che non esiste, esso restituisce una risposta vuota. Non c'è modo di dire esplicitamente: "sono spiacente, la zona richiesta non esiste". Ciò rappresenta problema se si desidera autenticare la risposta, poiché non è presente alcun messaggio da firmare. DNSSEC corregge questo problema aggiungendo i tipi di record NSEC e NSEC3. Entrambi, infatti, consentono un denial of existence autenticato.

NSEC opera restituendo il record "next secure". Ad esempio, si consideri un nameserver che definisce i record AAAA per api, blog e www. Se si richiedesse un record per "store", esso restituirebbe un record NSEC contenente "www", il che significa che non ci sono record AAAA tra "store" e "www" quando i record sono ordinati alfabeticamente. Questo comunica efficacemente che "store" non esiste. E, poiché il record NSEC è firmato, è possibile convalidare il corrispondente RRSIG proprio come qualsiasi RRSet.

Sfortunatamente, questa soluzione consente a chiunque di attraversare la zona e raccogliere ogni singolo record senza sapere quali sono quelli che sta cercando. Questo può rappresentare una potenziale minaccia per la sicurezza, se l'amministratore della zona contava sul fatto che i contenuti della zona fossero privati. Maggiori dettagli su questo problema in DNSSEC: complessità e considerazioni, nonché nella soluzione unica di Cloudflare in Il DNSSEC fatto come si deve.

La catena della fiducia

Ora disponiamo di un metodo per stabilire la fiducia all'interno di una zona e collegarla alla sua zona genitore, ma come possiamo fidarci del record DS? Il record DS viene firmato proprio come qualsiasi altro RRSet, il che significa che ha un RRSIG corrispondente nel genitore. L'intero processo di convalida si ripete fino a quando non arriviamo alla KSK pubblica del genitore. Per verificarlo, dobbiamo andare al registro DS di quel genitore, e salire man mano la catena di fiducia.

diagramma la catena di fiducia

Tuttavia, quando finalmente arriviamo alla zona root del DNS, ci troviamo davanti a un problema: non c'è nessun record DS genitore da convalidare. È proprio qui che possiamo vedere un lato molto umano dell'Internet globale.

Nella cerimonia della firma del dominio root, alcune persone designate, provenienti da tutto il mondo, si incontrano per firmare il dominio root DNSKEY in modo pubblico e altamente controllato. La cerimonia produce un record RRSIG che può essere utilizzato per verificare le chiavi KSK e ZSK pubbliche del nameserver del root. Invece di fidarci della chiave KSK pubblica in ragione del record DS del genitore, supponiamo che sia valida perché ci fidiamo delle procedure di sicurezza messe in piedi per l'accesso alla chiave KSK privata.

La capacità di stabilire la fiducia tra le zone genitore e figlio è parte integrante del protocollo DNSSEC. Se una qualsiasi parte della catena si rompe, non possiamo fidarci dei record che stiamo chiedendo perché un man-in-the-middle potrebbe alterare i record e indirizzarci su qualsiasi indirizzo IP desiderato.

Riassunto

Similmente a HTTPS, DNSSEC aggiunge un livello di sicurezza abilitando risposte autenticate su un protocollo altrimenti non sicuro. Mentre HTTPS crittografa il traffico in modo che nessuno sulla rete possa curiosare nelle attività Internet, DNSSEC firma semplicemente le risposte in modo che i falsi siano rilevabili. DNSSEC fornisce una soluzione a un problema reale senza necessità di incorporare la crittografia.

L'obiettivo di Cloudflare è quello di rendere il più semplice possibile abilitare il protocollo DNSSEC. In questo momento, i clienti con piani a pagamento Cloudflare possono aggiungere DNSSEC alle loro proprietà Web premendo semplicemente un pulsante per abilitare DNSSEC e caricando un record DS (che verrà generato automaticamente) nel registrar. Ulteriori informazioni su come ottenere DNSSEC.

Abbiamo inoltre pubblicato una bozza Internet che delinea un metodo automatizzato per consentire ai registri e ai registrar di caricare i record DS per conto dei nostri clienti. Ciò consentirà a Cloudflare di abilitare automaticamente il protocollo DNSSEC per la nostra intera comunità. Rimani sintonizzato per gli aggiornamenti.

Configurare Cloudflare è facile



Configura un dominio in meno di 5 minuti mantenendo il tuo provider di hosting e senza dover modificare il codice.


Prezzi di Cloudflare

Internet può ricevere vantaggi dall'uso di Cloudflare.Scegli un piano adatto alle tue esigenze.


Free

Per siti Web personali, blog e per tutti coloro che desiderano scoprire i servizi di Cloudflare.



Learn More


Pro

Per siti Web, blog e portfolio professionali che richiedono sicurezza e prestazioni di base.


$ 20 / mese

per dominio


Learn More


Business

Per piccoli siti di e-commerce e imprese che richiedono sicurezza e prestazioni avanzate, conformità PCI e supporto prioritario via e-mail.


$ 200 / mese

per dominio


Learn More


Enterprise

Per aziende che richiedono sicurezza e prestazioni di alto livello, supporto via telefono, chat o e-mail 24 ore su 24, 7 giorni su 7 tutto l'anno, con uptime garantito.


Contattaci


Learn More

Oltre 25 milioni di proprietà Internet si affidano a noi