OVERVIEW DNSSEC

Il protocollo DNSSEC (Domain Name System Security Extension) fornisce un'ulteriore sicurezza al DNS. Il protocollo è progettato per far fronte agli attacchi MITM e di avvelenamento della cache autenticando l'origine dei dati DNS e verificandone l'integrità durante i vari spostamenti in Internet.


Perché il protocollo DNSSEC? Funzionamento Basi del successo Storia del protocollo DNSSEC

Il DNS (Domain Name System), il sistema di indirizzamento per Internet, è il componente più importante per l'infrastruttura Internet. Senza DNS, Internet potrebbe non funzionare. Tuttavia, il DNS non è stato sviluppato pensando alla sicurezza. Di conseguenza, è vulnerabile agli attacchi man-in-the-middle (MITM) e all'avvelenamento della cache. Queste minacce utilizzano dati manomessi per reindirizzare il traffico Internet a siti fraudolenti e indirizzi non desiderati. Ulteriori informazioni su DNS

Quando un utente o un dispositivo inattesi accedono a un sito fraudolento, i pirati informatici potrebbero riuscire a estrapolare dati relativi a carte di credito, rubare password personali, ascoltare le comunicazioni Voice over IP (VoIP), installare software nocivi, visualizzare immagini e contenuti di testo diffamanti per il marchio oppure fornire informazioni non veritiere. Dato che un singolo server dei nomi DNS può agire come punto di risoluzione da nome a indirizzo per migliaia di utenti, il potenziale impatto di un attacco MITM o di avvelenamento della cache risulta notevole.

VANTAGGI DEL PROTOCOLLO DNSSEC PER GLI UTENTI FINALI

Il protocollo DNSSEC offre opportunità a tutti i membri dell'ecosistema di Internet. L'impatto più ampio e diretto del protocollo riguarda gli utenti finali.

  • Attività affidabili: rafforzando la sicurezza DNS, il protocollo DNSSEC consente di incrementare la fiducia in diverse attività Internet, tra cui e-commerce, banking online, e-mail, VoIP e distribuzione di software online.
  • Tutela di clienti e marchio: il protocollo DNSSEC previene il rischio, per i clienti, di divenire vittime involontarie di attacchi di pirateria informatica quando tentano di accedere a una risorsa.
  • Nuovi tipi di transazioni sicure: il protocollo DNSSEC consente di utilizzare il sistema DNS per nuovi tipi di transazioni di dati sicure.

La Internet Engineering Task Force (IETF) ha lavorato per oltre 15 anni per sviluppare uno standard elaborabile per il protocollo DNSSEC. Il protocollo DNSSEC protegge la community di Internet dai dati DNS manomessi utilizzando la crittografia della chiave pubblica per eseguire la firma digitale di dati di zone autoritative nel momento in cui entrano all'interno del sistema e convalidando tali dati nella propria destinazione. Ulteriori informazioni sulla crittografia della chiave pubblica

La firma digitale garantisce agli utenti che i dati derivano dall'origine indicata e non sono stati modificati durante la transazione. Il protocollo DNSSEC consente inoltre di dimostrare che un nome di dominio non esiste. Tali funzionalità risultano essenziali per il mantenimento della fiducia in Internet.

Nel protocollo DNSSEC ciascuna zona è dotata di una coppia di chiavi pubblica/privata. La chiave pubblica della zona utilizza il sistema DNS, mentre la chiave privata della zona viene protetta e possibilmente archiviata offline. La chiave privata di una zona firma singoli dati DNS in quella zona, creando firme digitali che vengono anche pubblicate con il sistema DNS.

Il protocollo DNSSEC si avvale di un rigido modello di affidabilità che, secondo una catena gerarchica, passa dalla zona madre alla zona figlia. Le zone di livello alto (madri) sottoscrivono, o garantiscono per, le chiavi pubbliche delle zone di livello inferiore (figlie). I server dei nomi autoritativi per queste zone possono essere gestiti da società di registrazione, ISP, società di hosting Web o dagli operatori di siti Web (registranti) stessi.

Quando un utente finale desidera accedere a un sito Web, uno stub resolver sul computer dell'utente richiede l'indirizzo IP del sito Web da un server dei nomi ricorsivo. Dopo che il server ha richiesto questo record, richiede anche la chiave DNSSEC associata alla zona. Tale chiave consente al server di verificare che il record dell'indirizzo IP ricevuto risulti identico al record presente sul server dei nomi autoritativi.

Se il server del nome ricorsivo determina che il record dell'indirizzo è stato inviato dal server del nome autoritativo e non è stato modificato durante il transito, il nome di dominio viene risolto e l'utente può accedere al sito. Tale procedura viene definita convalida. Se il record dell'indirizzo è stato modificato o non proviene dall'origine indicata, il server del nome ricorsivo non consente all'utente di raggiungere l'indirizzo fraudolento. Il protocollo DNSSEC consente inoltre di dimostrare che un nome di dominio non esiste. Come conseguenza di questo processo, le query e le risposte DNS vengono protette dagli attacchi man-in-the-middle (MITM) e dai tipi di falsificazioni in grado di reindirizzare gli utenti di Internet a siti di phishing e pharming.

Per garantire un successo globale del protocollo DNSSEC, Verisign adotta un approccio proattivo ma cauto in grado di risolvere tre principi chiave:

  • Il protocollo DNSSEC rappresenta una soluzione valida per una specifica vulnerabilità di Internet, ma deve essere integrato da altri livelli di sicurezza.
  • Un'implementazione controllata e metodica del protocollo DNSSEC è la soluzione migliore.
  • L'intero ecosistema Internet condivide le responsabilità relative al protocollo DNSSEC.

UNA SOLUZIONE VALIDA PER VULNERABILITÀ SPECIFICHE

Nonostante il protocollo DNSSEC migliori la sicurezza DNS, costituisce solamente un componente dell'approccio su più livelli alla sicurezza dell'infrastruttura Internet. Non protegge i server dei nomi da attacchi DDoS (Distributed Denial of Service), non garantisce la massima riservatezza negli scambi di dati, né consente di crittografare i dati di siti Web o di prevenire spoofing e phishing di indirizzi IP. Anche altri livelli di protezione, tra cui mitigazione DDoS, security intelligence, crittografia e convalida SSL (Secure Sockets Layer), e autenticazione a due fattori, sono indispensabili per garantire una maggiore sicurezza di Internet. Tali meccanismi dovrebbero essere utilizzati in abbinamento al protocollo DNSSEC.

IMPLEMENTAZIONE MISURATA E CONTROLLATA

L'implementazione ad ampio spettro del protocollo DNSSEC introduce una serie di modifiche complesse che influenzano l'intero ecosistema di Internet e richiedono un'ampia gamma di risorse, documentazione, testing e coordinazione di settore. Ogni processo di implementazione del protocollo DNSSEC deve avvenire per fasi, specialmente per il funzionamento affidabile dei domini di primo livello (TLD) importanti in tutto il mondo, quali .com e .net. Operazioni di sviluppo di strategie, pianificazione e collaborazione a lungo termine, non solo all'interno e tra le organizzazioni e i settori ma anche a livello internazionale, costituiscono una solida base per un corretto processo di implementazione.

RESPONSABILITÀ CONDIVISA

Poiché l'avvelenamento della cache può verificarsi in qualsiasi punto di Internet, il protocollo DNSSEC risulta più efficace se implementato universalmente, a partire dalla zona radice e dai domini di primo livello (TLD) e spostandosi verso il basso ai nomi di dominio individuali. Registri, società di registrazione, registranti, società di hosting, sviluppatori di software, produttori di hardware, governi, attività e agenzie presenti in Internet e coalizioni e tecnici di Internet sono tutti responsabili del successo di questa attività globale.

L'adozione del protocollo DNSSEC è in costante aumento, poiché enti pubblici, istituti finanziari, ISP, aziende e altre organizzazioni sono sempre più consapevoli delle minacce relative al sistema DNS.

La zona radice di Internet, i domini di primo livello (TLD) come .net, .com, .gov, .org, .museum e .edu nonché una serie di TLD con codice di paese (ccTLD) hanno completato una completa distribuzione del protocollo DNSSEC. I TLD hanno iniziato ad accettare nomi di dominio a firma DNSSEC di secondo livello. Alcuni ISP hanno preannunciato la propria intenzione di attivare la convalida sui server dei nomi ricorsivi in grado di rispondere alle query degli utenti e alcune società di registrazione hanno incluso l'implementazione DNSSEC nelle proprie agende. Inoltre, ICANN ha allestito applicazioni per i nuovi TLD ed è probabile che richiederà a nuovi richiedenti TLD di pianificare l'implementazione DNSSEC.

TIMELINE DNSSEC

1990 Viene rilevato un grave errore nel DNS e inizia il dialogo sulla sicurezza del DNS.
1995 Il DNSSEC diventa formalmente un argomento di IETF.
1999 Il protocollo DNSSEC (RFC2535) viene concluso e BIND9 viene sviluppato come prima implementazione compatibile con DNSSEC.
2001 La gestione delle chiavi crea problemi operativi che impediscono la distribuzione di DNSSEC su reti di grandi dimensioni. IETF decide di riscrivere il protocollo.
2005 Gli standard DNSSEC vengono riscritti in più RFC 4033, 4034, 4035. A ottobre, la Svezia (.se) abilita DNSSEC nella zona di competenza.
2007 A luglio, ccTLD.pr (Porto Rico) abilita DNSSEC, seguito da .br (Brasile) a settembre e da .bg (Bulgaria) a ottobre.
2008 Lo standard NSEC3 (RFC 5155) viene pubblicato. A settembre, ccTLD .cz (Repubblica Ceca) abilita DNSSEC.
2009 Verisign ed EDUCAUSE ospitano un banco di prova DNSSEC per registranti .edu selezionati. Zona radice firmata per uso interno da Verisign e ICANN. ICANN e Verisign esercitano la firma della chiave ZSK con la chiave KSK.
2010 Il primo server root inizia a servire la zona radice firmata, utilizzando la metodologia DURZ (deliberately unvalidatable root zone). Tutti i server root iniziano a servire la zona radice firmata, utilizzando la metodologia DURZ. L'ICANN organizza il primo evento di cerimonia KSK a Culpeper, VA, USA. L'ICANN pubblica la trust anchor della zona radice e gli operatori della zona radice iniziano a servire la zona radice firmata con chiavi effettive - La zona radice firmata è disponibile. Verisign e EUDCAUSE abilitano il protocollo DNSSEC per il dominio .edu. Verisign abilita il protocollo DNSSEC per il dominio .net.
2011 A febbraio, il registro .gov con abilitazione DNSSEC passa a Verisign. A marzo, .com viene firmato e il servizio Managed DNS di Verisign viene ottimizzato con il supporto completo per la conformità DNSSEC. Vengono firmati 59 TLD con trust anchor nella zona radice.
2012 A gennaio, Comcast ha annunciato che i propri clienti stanno utilizzando resolver con convalida DNSSEC. Da marzo, il numero di TLD firmati è salito a 90.

RUOLO DI VERISIGN

Verisign è stata coinvolta nel processo di sviluppo del protocollo DNSSEC a partire dal 2000 e i nostri ingegneri hanno svolto un ruolo di spicco nello sviluppo del protocollo NSEC3. Continuiamo a collaborare con la community tecnica di Internet anche durante le fasi di testing, implementazione e adozione del protocollo DNSSEC. Per esempio, Verisign è stato membro attivo della DNSSEC Coalition, un'organizzazione di settore che si dedica alla semplificazione dell'adozione del protocollo DNSSEC. Inoltre, per garantire l'impiego delle migliori tecniche consigliate, condividiamo quanto appreso durante i processi di distribuzione del protocollo DNSSEC e supportiamo un approccio solido al DNSSEC tra i registri.

Nel luglio 2010, Verisign, in collaborazione con l'Internet Assigned Numbers Authority (IANA) e il Dipartimento del Commercio statunitense (DoC), ha completato la distribuzione del protocollo DNSSEC nella zona radice (punto di inizio della gerarchia DNS). Verisign ha inoltre abilitato il protocollo DNSSEC .edu a luglio, in collaborazione con EDUCAUSE e il Dipartimento del Commercio, su .net a dicembre del 2010 e su .com a marzo del 2011. Inoltre, svariati domini di primo livello (TLD) sono stati assegnati da altri registri, tra cui .gov, .org, e nomi di TLD con codice di paese per Brasile, Bulgaria, Repubblica Ceca, Puerto Rico e Svezia.

Abbiamo inoltre intrapreso diverse attività per fornire assistenza ai membri dell'ecosistema Internet per sfruttare a pieno il protocollo DNSSEC. Queste attività prevedono la pubblicazione di risorse tecniche, la disponibilità di un ambiente di test funzionale (Operational Test, OT), la creazione di sessioni di formazione, la partecipazione a forum di settore, lo sviluppo di strumenti che semplifichino la gestione del protocollo DNSSEC, nonché l'assistenza della comunità con un interoperability lab.