#main-nav-header { display:none; }

Come funziona DNSSEC

Il DNS (Domain Name System) può essere considerato l'elenco telefonico di Internet: indica ai computer dove inviare e recuperare le informazioni. Purtroppo, accetta anche qualsiasi indirizzo gli venga dato, e senza fare domande.

I server di posta elettronica utilizzano il DNS per indirizzare i messaggi e questo significa che sono esposti a problemi di sicurezza nell'infrastruttura del DNS. Nel settembre del 2014 i ricercatori della CMU scoprirono che delle email che si presumeva fossero state inviate tramite i server di Yahoo!, Hotmail e Gmail, passavano invece attraverso server di posta non autorizzati. Gli autori degli attacchi avevano sfruttato una antica vulnerabilità nel DNS (Domain Name System), cioè il fatto che esso non controlla le credenziali prima di accettare una risposta.

La soluzione è un protocollo denominato "DNSSEC", che aggiunge un livello di fiducia al DNS fornendo un servizio di autenticazione. Quando un resolver DNS cerca blog.cloudflare.com, i nameserver .com aiutano il resolver a verificare i record restituiti per "cloudflare" e cloudflare aiuta a verificare i record restituiti per "blog". I nameserver del DNS root aiutano a verificare .com, e le informazioni pubblicate dal root vengono controllate tramite una procedura di sicurezza approfondita, che include la cosiddetta cerimonia di firma dei certificati di root.

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.

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.

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.

Summary

Similar to HTTPS, DNSSEC adds a layer of security by enabling authenticated answers on top of an otherwise insecure protocol. Whereas HTTPS encrypts traffic so nobody on the wire can snoop on your Internet activities, DNSSEC merely signs responses so that forgeries are detectable. DNSSEC provides a solution to a real problem without the need to incorporate encryption.

Cloudflare’s goal is to make it as easy as possible to enable DNSSEC. All Cloudflare customers can add DNSSEC to their web properties by flipping a switch to enable DNSSEC and uploading a DS record (which we'll generate automatically) to their registrar.: Learn more about how to get DNSSEC.

We’ve also published an Internet Draft outlining an automated way for registries and registrars to upload DS records on behalf of our customers. This will enable Cloudflare to automatically enable DNSSEC for our entire community. Stay tuned for updates.

Milioni di proprietà Internet si affidano a noi

Vedi i case study