Che cos'è la tecnologia DNSSEC e come funziona?

È necessario abilitare DNSSEC sul proprio dominio?

DNSSEC vi aiuta a proteggere il vostro dominio dagli attacchi di cache poisoning e dalla falsificazione delle risposte È un'aggiunta cruciale al dominio, perché il clima digitale di oggi richiede che l'architettura del proprietario di un sito web sia protetta dall'inizio alla fine e un attacco DNS riuscito può danneggiare notevolmente la reputazione di un brand. La risoluzione DNS si verifica prima che un utente interagisca con l'applicazione di un sito web. Se il DNS viene intercettato da un utente malintenzionato, un utente che cerca di visitare un sito web può interfacciarsi con un sito falso (destinato a ingannare l'utente) anziché con il sito previsto L'aggressiva architettura di memorizzazione nella cache del protocollo rende difficile correggere rapidamente i record compromessi. 

Pertanto, anche se un sito web è rafforzato da firewall potenti, i dati e la tecnologia di un utente finale saranno a rischio se l'architettura DNS di un sito non è sufficientemente protetta con l'utilizzo di DNSSEC. 

Raggruppamento dei record DNS in RRSet

L'integrazione di DNSSEC con il vostro dominio inizia con il raggruppamento dei record DNS per nome e tipo di record in set di record di risorse (RRSet). Il DNS stesso è suddiviso in zone DNS. Una zona è una parte dello spazio dei nomi DNS complessivo che viene supervisionata dall'organizzazione generale del proprietario del DNS o da un amministratore di rete. Questa zona consente una manutenzione approfondita dei componenti DNS, come i server dei nomi autorevole. 

Ogni zona è firmata da una coppia di chiavi pubblica e privata nota come chiave ZSK (Zone Signing Key). La firma risultante viene pubblicata come record RRSIG nel file di zona stesso. Ad esempio, se il nome host "www.dsnsecexample.com" include sia un record A che un record AAAA, il file di zona pubblicizzerà un record RRSIG corrispondente per ogni versione IP.

Isolando le zone DNS l'una dall'altra, le zone adiacenti sono protette nell'eventualità che una zona venga infettata da un utente malintenzionato.

Firme record di risorsa

Un record RRSIG contiene una firma DNSSEC digitale di un RRSet. Queste firme digitali vengono utilizzate per autenticare tutti i dati che si trovano negli RRSet firmati. I resolver possono verificare la firma con una chiave pubblica memorizzata in un record DNSKEY.

Questi RRSet per i tipi di record e i nomi di dominio di proprietà vengono archiviati all'interno di una zona DNS firmata. Quando un server dei nomi di dominio utilizza la chiave privata di una coppia ZSK per firmare gli RRSet all'interno di una data zona, viene utilizzato un record RRSIG per memorizzare le firme digitali di ciascun RRSet. Pertanto, una zona firmata contiene un record RRSIG per ogni RRSet.

Un record RRSIG è costituito dai seguenti componenti:

• Tipo coperto: il tipo di record DNS coperto da RRSIG

• Algoritmo: un algoritmo crittografico che genera la firma finale

• Conteggio etichette: il numero di etichette nel nome del record RRSIG originale (utilizzato per convalidare i caratteri jolly)

• TTL originale: il valore TTL del set di record coperti

• Scadenza firma: l'ora in cui la firma scade

• Inizio validità firma: l'ora in cui la firma è stata inizialmente creata

• Tag chiave un valore numerico per identificare il record DNSKEY utilizzato per convalidare questa firma RRSIG

• Nome firmatario: il nome del record DNSKEY utilizzato per convalidare questa firma

• Firma: la firma crittografica utilizzata per verificare la trasmissione

Chiave ZSK (Zone Signing Key)

Una ZSK è una chiave per l'autenticazione dei dati trasmessi. La ZSK è un aspetto dello stesso RRSet della chiave KSK (Key Signing Key), che ha una chiave privata corrispondente per firmare questo DNSKEY RRSet. Ogni zona ha una coppia di ZSK e una zona abilitata per DNSSEC annuncerà la ZSK pubblica come record DNSKEY in modo che i resolver possano autenticare i valori RRSIG. 

La convalida DNSSEC non distingue tra ZSK e altre chiavi di autenticazione DNSSEC, rendendo possibile l'utilizzo di una chiave sia come chiave KSK che come ZSK. Una verifica riuscita indica che i record DNS non sono stati contraffatti né manipolati durante il transito, poiché solo l'amministratore di zona avrà accesso alla ZSK privata.

La ZSK corrisponde alla chiave privata utilizzata per firmare una zona e di solito fa parte dello stesso RRSet della chiave pubblica di firma che corrisponde alla chiave privata che firma questo RRSet. 

Chiave KSK (Key Signing Key)

KSK è una coppia di chiavi più costosa dal punto di vista informatico implementata per migliorare ulteriormente la posizione di sicurezza dei record DNSKEY. È stata introdotta per alleggerire il carico di gestione per l'amministratore di zona. La KSK corrisponde a una chiave privata e viene utilizzata per firmare altre chiavi di autenticazione per una data zona. In genere, la chiave privata corrispondente a una KSK firmerà una ZSK, che a sua volta ha una chiave privata corrispondente per firmare altri dati trovati all'interno della zona DNS. I resolver autenticheranno questa firma digitale con il record DNSKEY in chiaro pertinente che annuncia la KSK pubblica. 

Le KSK e i corrispondenti record firmatario delega vengono aggiornati solo periodicamente, a differenza delle ZSK, che si aggiornano più frequentemente. Pertanto, l'architettura ideale dal punto di vista della sicurezza e delle operazioni consiste nell'autofirmare una ZSK a rotazione frequente con una KSK separata e più duratura. Questa implementazione sarebbe più efficace per proteggere la zona DNS da potenziali minacce, riducendo al minimo anche la quantità di manutenzione DNSSEC in corso.

Record firmatario delega

DNSSEC ha stabilito il record firmatario delega (DS) per creare un modello di "catena di fiducia" con resolver DNS pubblici. In questi scenari, i malintenzionati potrebbero teoricamente falsificare le risposte DNS e restituire un record DNSKEY contraffatto che compromette l'integrità della zona. I record DS pubblicano un'impronta digitale della KSK pubblica nella zona principale.

Durante la convalida, il resolver assicurerà che il record DS della zona padre corrisponda al corrispondente record DNSKEY della zona figlio per autenticare la legittimità della coppia di chiavi del figlio. Questa catena di fiducia viene mantenuta fino alla zona radice, che include trust anchor integrati nella maggior parte dei resolver ricorsivi. 

NSEC e NSEC3

Il record NSEC (Next Secure) può essere utilizzato per determinare se esiste un nome all'interno di una determinata zona. È stato introdotto per risolvere il problema dei casi di record inesistenti in una zona, spesso noto come problema di autenticazione di "negazione dell'esistenza". Gli autori di attacchi potrebbero sfruttare questa vulnerabilità e rendere inutilizzabile un sito falsificando una risposta NXDOMAIN per il nome host del sito web. 

NXDOMAIN risolve questo difetto includendo un record NSEC che indica il successivo record canonico nella zona che esiste quando viene ricevuta una query per un nome inesistente e il tipo di record che appaiono con quel nome. 

Ad esempio, se la zona "example.com" venisse ordinata e "beta.example.com" fosse il primo record, una query per "alpha.example.com" risulterebbe in un record NXDOMAIN e in un record NSEC che punta a "beta. esempio.com." I record NSEC, come qualsiasi altro record, sono firmati dalla ZSK e hanno un RRSIG corrispondente. Di conseguenza, una risposta NXDOMAIN richiede che un record RRSIG NSEC autenticato sia valido.

NSEC3 è stato sviluppato per risolvere il problema dei record NSEC utilizzati per elencare tutti i record validi in una zona. NSEC3 si comporta in modo identico a NSEC, tranne per il fatto che il nome sicuro successivo nella zona è codificato con hashing, invece di essere visualizzato in chiaro. Ciò consente di proteggere le informazioni e impedire l'enumerazione della zona.

Modalità operative di DNSSEC

Firma offline delle zone statiche

Esistono molte modalità operative di DNSSEC, ciascuna con il proprio approccio univoco alla modalità di firma dei dati nella zona DNS. Di queste modalità, una delle più comuni è la firma offline delle zone statiche, che consente una solida protezione del sistema di firma dalle minacce esterne. Questo modello operativo conserva tutte le chiavi private trovate su un computer che non è attualmente connesso alla rete ed è efficace nei casi in cui le informazioni trovate nella zona DNS non vengono frequentemente alterate.

Firma online centralizzata

La firma online centralizzata è un'altra modalità operativa ricorrente di DNSSEC. Per i casi in cui gli amministratori firmano i dati in un DNS dedicato ad accesso limitato, la firma online centralizzata consente di modificare e pubblicare rapidamente i dati DNS nella zona. Come per la firma offline delle zone statiche, nella firma online centralizzata, un firmatario centrale singolo o replicato esegue tutta la firma dei dati. Quindi, i dati appena firmati circolano sui server DNS autorevoli.

Firma in tempo reale

La firma dei dati in tempo reale è una modalità operativa DNSSEC che consente ai server DNS autorevoli di firmare i dati quando necessario. Il problema con questo approccio è che può creare una situazione in cui la chiave esiste su una varietà di computer diversi, ciascuno con accesso diretto a Internet, introducendo così più vie per l'accesso esterno allo spazio dei nomi da parte degli autori di attacchi. Anche la distribuzione delle chiavi, quando un mittente sceglie un valore di chiave segreta e poi lo invia in modo sicuro al destinatario, è resa più complessa dalla firma in tempo reale e può aumentare inutilmente i requisiti di computing su ciascun nodo.

Rischi dell'integrazione di DNSSEC

Sebbene DNSSEC sia un modo essenziale per aumentare la sicurezza della rete, può introdurre involontariamente vulnerabilità critiche. DNSSEC può aumentare il rischio e amplificare gli effetti degli attacchi DDoS (Distributed Denial-of-Service), che causa l'interruzione di un server, un servizio o una rete tramite il traffico proveniente da più dispositivi contemporaneamente. DNSSEC aumenta il numero di risposte alle query DNS, poiché la tecnologia richiede campi aggiuntivi e informazioni crittografiche per verificare correttamente i record. Ciò significa che le risposte a elevato volume possono consentire ai malintenzionati un volume di attacco molto maggiore contro una zona rispetto a quello che potrebbero fare senza la tecnologia DNSSEC.

Handshake a tre vie richiesto

Poiché il TCP (Transmission Control Protocol) è un protocollo orientato alla connessione, è lento e richiede un handshake a tre vie. Pertanto, il DNS (e, quindi, la tecnologia DNSSEC) si basa sull'UDP (User Datagram Protocol), un protocollo più veloce ma più rischioso che non ha requisiti per aprire, mantenere o terminare una connessione, né può garantire la delivery dei dati firmati alla propria destinazione . UDP fornisce solo la funzionalità di controllo degli errori più basilare sotto forma di checksum e, poiché non richiede handshake, i dati trasmessi possono essere facilmente intercettati dagli autori di attacchi.

Lo spoofing UDP si verifica quando i malintenzionati creano un pacchetto di richiesta UDP valido che elenca l'indirizzo IP del loro obiettivo come indirizzo IP di origine UDP. L'autore di attacchi può quindi inviare l'IP di origine falsificato a un server intermedio, che invierà tutti i suoi pacchetti di risposta UDP, generando così una risposta molto più grande del pacchetto di richiesta. Questa risposta è sufficiente per incrementare l livello del traffico di attacco inviato all'indirizzo IP dell'obbiettivo.

Queste circostanze aumentano anche la lunghezza delle query DNS, il che amplifica la gravità degli attacchi. La misura in cui questi attacchi vengono amplificati può essere espressa come rapporto tra la dimensione della risposta e la dimensione della richiesta Ad esempio, se un utente malintenzionato invia una richiesta di 64 byte a un server DNS, può generare più di 3.400 byte di traffico dannoso da indirizzare verso una vittima prescelta. 

Descrizione della procedura di firma radice

Una procedura di firma radice DNS è una procedura rigorosa eseguita per firmare le informazioni della chiave pubblica della zona DNS radice per i mesi successivi. Questo processo garantisce che ci sarà meno di una possibilità su un milione  che un gruppo di cospiratori possa compromettere la chiave di firma radice. Si svolge in una delle due posizioni che salvaguardano la KSK radice. La chiave di firma privata utilizzata in questo processo è una chiave per sbloccare Internet protetto da DNSSEC.

Risoluzione dei problemi relativi alla zona DNS radice senza padre

Questa procedura risolve il problema delle zone DNS radice senza padre, ovvero una zona la cui integrità non può essere controllata da una zona padre. Richiede una serie di partecipanti, tra cui un amministratore della procedura, un testimone interno, un controllore della cassaforte delle credenziali, un controllore della cassaforte hardware e tre responsabili crittografici. Ogni membro è un membro del personale di ICANN (Internet Corporation for Assigned Names and Numbers), a parte i responsabili crittografici che sono volontari della comunità di Internet.

Accesso alla cassaforte delle credenziali

Ci sono due casseforti: la cassaforte delle credenziali e la cassaforte hardware. È necessario accedere ad entrambe per accedere alla chiave radice. Il controllore apre la cassaforte delle credenziali, che contiene cassette di sicurezza, ognuna delle quali richiede due chiavi detenute dall'amministratore della procedura e da un responsabile della crittografia. Queste casseforti contengono una scheda operatore e una scheda delle autorizzazioni di sicurezza necessarie per aprire il modulo di sicurezza hardware situato nella cassaforte hardware. Le schede sono conservate all'interno di custodie di plastica avvolte in buste anti-manomissione, che vengono lasciate nella cassaforte delle credenziali.

Apertura della cassaforte hardware

Il controllore della cassaforte hardware entra quindi nella stanza sicura e apre la cassaforte hardware contenente il modulo di sicurezza hardware. La cassaforte hardware contiene anche un laptop privo di batteria o disco rigido ed è designato per l'invio di comandi al modulo di sicurezza. Questo verrà utilizzato per firmare le chiavi DNS radice durante la procedura, ogni aspetto del quale viene meticolosamente registrato e trasmesso in streaming su Internet a beneficio dei posteri.

Coinvolgimento dei responsabili della crittografia

Una volta iniziata la procedura, i responsabili della crittografia devono consegnare le proprie schede operatore all'amministratore della procedura, che avvia il laptop da un DVD e inizializza l'USB che registra i registri della cerimonia. Tale amministratore utilizza quindi le tre schede operatore per attivare il modulo di sicurezza, che viene quindi collegato al laptop tramite cavo Ethernet. La richiesta di firma della chiave viene caricata nel laptop e viene calcolato un hash PGP della richiesta di firma della chiave, che viene quindi verificato per garantire che sia identico all'hash fornito. A questo punto, l'amministratore della procedura firma la richiesta di firma della chiave con la KSK privata, che crea una raccolta di firme digitali: il record RRSIG. 

Implementate oggi stesso la tecnologia DNSSEC per rafforzare la sicurezza del dominio 

È sufficiente un attacco DNS riuscito al vostro dominio per avere un impatto permanente sull'integrità del vostro ecosistema digitale e sulla reputazione complessiva del brand. Le firme crittografiche DNSSEC rafforzano il processo di risoluzione DNS per proteggere il vostro dominio da minacce informatiche come il cache poisoning e la falsificazione delle risposte. Infine, ciò consente la sicurezza end-to-end per i dati e la tecnologia della vostra organizzazione e dei vostri utenti finali. 

Scoprite le diverse soluzioni DNS di Akamai

Akamai continua a espandere la propria piattaforma per abilitare una gamma di servizi DNS di livello superiore per i proprietari di domini:

• Stabilità e resilienza del dominio con il servizio Edge DNS

• Bilanciamento del carico dei data center, implementazioni nel cloud e CDN con Global Traffic Management

• Ampia scalabilità delle applicazioni con il cloudlet ALB (Application Load Balancer)

• Assicuratevi che ogni dispositivo nella vostra rete controlli uno strumento di sicurezza DNS e consentite al resolver DNS di diventare uno strumento di sicurezza con Secure Internet Access Enterprise

• Accesso a una gamma di risorse DNS nella community Akamai

• Siete professionisti DevOps? Date un'occhiata alla nostra community degli sviluppatori

• Serve ulteriore assistenza? Contattateci oggi stesso. 

Pubblicato originariamente il 19 marzo 2021; aggiornato nel giugno 2022.