DNSSEC con Cloudflare: cosa protegge, cosa non protegge e come attivarsi senza problemi

La confusione più comune riguardo DNSSEC è descriverlo come “crittografia DNS”. I team che partono da questa premessa sbagliata giungono a due conclusioni ugualmente sbagliate: o accantonano la funzionalità perché "abbiamo già TLS", oppure la attivano senza comprendere la dipendenza operativa che hanno appena introdotto. DNSSEC firma le risposte DNS per dimostrare l'autenticità: non crittografa nulla. L'attacco che ferma, la conseguenza di una configurazione mal gestita e ciò che semplicemente non copre sono tre argomenti distinti che meritano un trattamento separato.

Cosa fa realmente DNSSEC

Quando un risolutore ricorsivo interroga un server autorevole e riceve una risposta, nel DNS tradizionale non esiste alcun meccanismo per verificare che tale risposta sia legittima. L'attacco di avvelenamento della cache descritto da Dan Kaminsky nel 2008 - e varianti successive - sfrutta esattamente questo: un utente malintenzionato inserisce record falsi nella cache di un risolutore, reindirizzando il traffico agli IP sotto il suo controllo senza che il proprietario del dominio lo sappia. Gli utenti interrogano il risolutore compromesso, ricevono un IP dannoso con una risposta apparentemente normale e vanno avanti. TLS da solo non risolve questo problema: se l’utente è stato portato su un server che ha un certificato valido per il dominio – ottenuto, ad esempio, tramite DV in un’altra CA – la catena HTTPS appare intatta anche se la destinazione è fraudolenta.

DNSSEC risolve il problema a livello DNS, prima di qualsiasi connessione TCP. Ogni risposta DNS trasporta record RRSIG: firme crittografiche generate con la chiave privata della zona. Il risolutore che supporta la convalida DNSSEC verifica la firma utilizzando la chiave pubblica pubblicata nella zona (record DNSKEY) e verifica che questa chiave pubblica sia legittima controllando il record DS nella zona genitore: la catena di fiducia discende dalla radice, passa attraverso la zona TLD (.com, .com.br) e arriva nella tua zona. Un record con firma non valida o mancante, in una zona che dichiara il supporto DNSSEC, risulta in SERVFAIL: il risolutore rifiuta la risposta anziché trasmettere dati potenzialmente manomessi.

Cosa non copre DNSSEC

DNSSEC non crittografa le query DNS. Un osservatore sulla rete può comunque vedere quali domini stai interrogando: per questo esistono DNS su HTTPS (DoH) e DNS su TLS (DoT), protocolli separati che crittografano il trasporto. DNSSEC inoltre non protegge il contenuto del tuo servizio, non mitiga gli attacchi DDoS contro i tuoi server autorevoli e non impedisce il typosquatting o il phishing su domini che assomigliano semplicemente al tuo. La garanzia è ristretta e specifica: le risposte DNS per la tua zona, se firmate correttamente, arrivano al risolutore senza manomissioni.

Attivazione su Cloudflare

Il processo tecnico in Cloudflare è semplice: un pulsante sul pannello DNS della zona genera la coppia di chiavi, inizia a firmare tutti i record nella zona e inizia a servire automaticamente i record RRSIG. La funzionalità è disponibile su tutti i piani, compreso quello gratuito. Ciò che farai dopo determinerà se DNSSEC funzionerà o interromperà la produzione.

Dopo l'attivazione nella dashboard, Cloudflare visualizza il record DS di cui hai bisogno per registrarti presso il tuo registrar. Questo record DS, pubblicato nella zona TLD dal registrar, è il collegamento che collega la fiducia del TLD alla tua zona: senza di essa, la catena di fiducia è incompleta e i risolutori convalidati DNSSEC trattano la tua zona come non firmata, non valida. Il processo di registrazione DS varia a seconda del registrar: alcuni hanno un'interfaccia grafica sul pannello di controllo, altri richiedono l'inserimento manuale dei campi: Key Tag, Algorithm, Digest Type e Digest. Cloudflare visualizza tutti questi valori formattati dopo aver abilitato DNSSEC.

Il problema della rotazione delle chiavi

Il rischio operativo di DNSSEC non sta nell'attivazione, ma nella manutenzione. Cloudflare ruota periodicamente le chiavi DNSSEC della zona. Quando ciò accade, il record DS registrato presso il registrar deve essere aggiornato per riflettere la nuova chiave. Se il registrar supporta l'aggiornamento DS automatico tramite API, come nel caso di Cloudflare Registrar, Amazon Route 53 in modalità dominio registrato e Namecheap con API abilitata, la rotazione avviene senza intervento manuale. Se il registrar non lo supporta, Cloudflare ti invia un avviso e hai una finestra di tempo per aggiornare manualmente.

La mancanza di questa finestra ha una conseguenza diretta: il DS nel registro punta ad una chiave che la zona non utilizza più. I risolutori convalidati DNSSEC iniziano a ricevere RRSIG firmato da una chiave diversa rispetto al DS pubblicato, concludono che si è verificata una manomissione e restituiscono SERVFAIL per qualsiasi query al tuo dominio. Dal punto di vista dell'utente, il dominio semplicemente smette di risolversi. La correzione richiede l'aggiornamento del DS nel registrar e l'attesa della propagazione del TTL della zona TLD, il che è spesso lungo, dell'ordine di ore, perché non controlli quel TTL.

Attivarsi in sicurezza: cosa controllare prima e dopo

Prima di abilitare DNSSEC, conferma che il tuo registrar accetta i record DS per il dominio in questione. Per .com.br domini, Registro.br ora supporta DNSSEC, ma il supporto storico è stato incoerente: vale la pena controllare direttamente nella dashboard per vedere se l'opzione DS è disponibile per il tuo dominio specifico prima di attivarla su Cloudflare. L'attivazione di Cloudflare senza poter registrare il DS presso il registrar lascia la zona firmata ma senza la catena di fiducia completa, che non offre alcuna protezione aggiuntiva e crea inoltre uno stato che può generare confusione nella diagnostica futura.

Dopo aver attivato e registrato il DS, testare la convalida con strumenti come dnssec-analyzer.verisignlabs.com o dnsviz.net prima di considerare il processo completato. Questi strumenti mostrano ogni anello della catena di fiducia e identificano i record RRSIG non validi, scaduti o mancanti. Imposta avvisi per la rotazione delle chiavi (il dashboard di Cloudflare offre notifiche e-mail) e documenta il processo di aggiornamento DS nel runbook delle operazioni DNS. Una rotazione mal gestita alle tre del mattino, con il dominio principale dell'azienda che restituisce SERVFAIL, è il tipo di incidente che dovrebbe essere nel runbook prima che si verifichi, non dopo.