• Cloud, Guide, Sicurezza
• 29 Aprile 2026

Quando parlate di sicurezza nel DNS entrate in un ambito storicamente basato sulla fiducia implicita. Con DNSSEC (Domain Name System Security Extensions) introducete un livello di protezione fondamentale: la validazione crittografica delle risposte DNS. Non vi limitate più a ricevere una risposta, ma potete verificarne autenticità e integrità.

Il meccanismo si basa sulla firma digitale dei record DNS e su una catena di fiducia che parte dalla root e arriva fino alla vostra zona. Questo vi consente di prevenire attacchi come DNS cache poisoning e man-in-the-middle, garantendo che le informazioni non vengano alterate durante la risoluzione.

Adottando DNSSEC, aumentate in modo concreto la sicurezza dell’infrastruttura, riducete la superficie di attacco e migliorate la fiducia nei servizi esposti, soprattutto in ambienti distribuiti come Azure. Inoltre, vi allineate a best practice e requisiti di compliance sempre più richiesti.

Come funziona

Il funzionamento di DNSSEC è basato sull’idea che ogni risposta DNS debba essere verificabile crittograficamente. Quando interrogate una zona firmata, non ricevete solo il record richiesto, ma anche una firma digitale (RRSIG) che consente di validare l’integrità e l’origine del dato.

Questa firma viene generata utilizzando una coppia di chiavi, gestite nel caso di Azure direttamente dalla piattaforma. La chiave privata firma i record della zona, mentre la chiave pubblica viene pubblicata nel DNS e utilizzata dai resolver per eseguire la verifica. Non dovete quindi gestire manualmente il processo di firma, ma dovete assicurarvi che la catena sia correttamente configurata.

Il passaggio determinante è infatti la creazione della catena di fiducia (chain of trust). Azure vi fornisce i parametri necessari per pubblicare il record DS nella zona padre, collegando così la vostra zona al livello superiore. È questo collegamento che permette ai resolver di validare l’intero percorso, dalla root fino al dominio finale.

Quando una query viene risolta, il resolver verifica ogni passaggio della catena. Se tutte le firme risultano valide, la risposta viene accettata; in caso contrario viene scartata. In questo modo ottenete integrità, autenticità e protezione da attacchi di spoofing DNS, senza modificare il comportamento delle vostre applicazioni.

Trovate maggiori informazioni sul funzionamento di DNSSEC alla pagina Overview of DNSSEC – Azure Public DNS | Microsoft Learn

Cosa cambia quando abilitate DNSSEC in una zona DNS

Osservando la figura sotto vedete chiaramente cosa cambia tra una zona DNS tradizionale e una protetta con DNSSEC. Nella parte sinistra avete una zona “unsigned”, dove sono presenti solo i record classici come NS, SOA, MX, A, AAAA e CNAME. In questa configurazione non esiste alcun meccanismo per verificare che le risposte siano autentiche.

Nella parte destra, invece, vedete cosa viene effettivamente configurato quando abilitate DNSSEC. Ogni record DNS viene affiancato da un record di firma chiamato RRSIG, che rappresenta la firma digitale del contenuto. Questo è il primo elemento chiave: i dati non viaggiano più “in chiaro”, ma sono sempre verificabili.

Oltre alle firme, vengono introdotti nuovi record fondamentali. Il record DNSKEY contiene le chiavi pubbliche utilizzate dai resolver per validare le firme. Il record NSEC (o NSEC3 in altri scenari) serve invece a dimostrare in modo crittografico l’inesistenza di un record, evitando risposte false anche nei casi di query negative.

Quando abilitate DNSSEC state di fatto configurando tre elementi principali: la firma dei record (RRSIG), la pubblicazione delle chiavi (DNSKEY) e i meccanismi di prova dell’inesistenza (NSEC). Tutto questo trasforma la vostra zona DNS da un sistema basato sulla fiducia implicita a un’infrastruttura in cui ogni risposta è verificabile e attendibile.

Figura 1: Zona DNS senza DNSSEC (sinistra) e zona DNS firmata con DNSSEC (destra): ogni record viene accompagnato da firme crittografiche e vengono introdotti nuovi record per la validazione

Abilitazione di DNSSEC per una zona ospitata in Azure DNS

Accedete al portale Azure e posizionatevi sulla DNS zone su cui volete abilitare DNSSEC. Dal menu laterale entrate nella sezione DNSSEC, che rappresenta il punto di gestione dedicato alla firma della zona. Qui trovate lo stato corrente e le opzioni per attivare la funzionalità.

Abilitate l’opzione Enable DNSSEC e confermate l’operazione. Con questa azione avviate il processo di firma della zona: Azure prende in carico la configurazione e prepara automaticamente tutti gli elementi necessari senza richiedere interventi manuali sulla parte crittografica.

Una volta abilitato DNSSEC, Azure genera e gestisce in autonomia le chiavi KSK (Key Signing Key) e ZSK (Zone Signing Key). Queste chiavi vengono utilizzate per firmare i record della zona e creare i relativi record RRSIG e DNSKEY, che saranno poi utilizzati dai resolver per la validazione.

Figura 2: Abilitazione di DNSSEC su una zona DNS in Azure tramite il portale: attivando l’opzione, Azure avvia automaticamente il processo di firma della zona

Terminata la fase di abilitazione, dovete recuperare le informazioni del record DS generate da Azure. Questo record è fondamentale perché rappresenta il collegamento tra la vostra zona e quella superiore, permettendo di costruire la catena di fiducia necessaria alla validazione DNSSEC.

La zona risulta correttamente firmata (Signed), ma lo stato indica “Signed but not delegated”, il che significa che la configurazione non è ancora completa.

Azure ha già fatto la sua parte: ha generato le chiavi, firmato la zona e pubblicato tutte le informazioni necessarie. Tuttavia, manca ancora il passaggio fondamentale per rendere effettiva la validazione, ovvero la creazione del record DS nella zona padre.

Nella sezione DNSSEC delegation information trovate proprio il valore del record DS che dovete copiare e configurare presso il registrar o il provider DNS che gestisce il dominio a livello superiore. Il messaggio in alto a destra evidenzia chiaramente questo punto: senza il record DS, la catena di fiducia non è completa.

Finché non eseguite questo passaggio, i resolver non saranno in grado di validare le firme e DNSSEC non sarà realmente operativo, anche se la zona risulta già firmata.

Figura 3: Zona DNS firmata ma non ancora delegata: è necessario configurare il record DS nella zona padre per completare DNSSEC

Configurazione del record DS presso il registrar (Aruba)

Nella figura sotto vedete il passaggio finale, che avviene lato registrar, in questo caso Aruba. Dopo aver recuperato i dati dal portale Azure, dovete inserirli manualmente nel pannello di gestione DNS del dominio per completare la configurazione di DNSSEC.

Il form richiede esattamente i parametri che Azure vi ha fornito nella sezione di delega: algoritmo, key tag, digest type e digest. Questi valori rappresentano il record DS e devono essere riportati fedelmente, senza modifiche, perché sono ciò che permette di collegare la vostra zona DNS alla catena di fiducia globale.

È importante notare che, a seconda del registrar, l’interfaccia può cambiare, ma i dati richiesti restano sempre gli stessi. In questo caso Aruba vi guida esplicitamente nell’inserimento, permettendovi di selezionare l’algoritmo e incollare i valori generati da Azure.

Una volta confermata l’operazione con Attiva, il record DS viene pubblicato nella zona padre.

Figura 4: Configurazione del record DS nel pannello Aruba: inserimento dei parametri DNSSEC forniti da Azure per completare la delega

Figura 5: DNSSEC attivo e catena di fiducia completata

A questo punto tornate nel portale Azure e verificate lo stato della zona DNS. Dopo aver configurato il record DS presso il registrar, è necessario attendere la propagazione: nel mio caso sono stati sufficienti circa 5 minuti, ma i tempi possono variare.

Quando la replica è completata, lo stato cambia in “Signed and delegation established”, indicando che la catena di fiducia è attiva e DNSSEC è correttamente operativo. Da questo momento, le risposte DNS della vostra zona possono essere validate dai resolver e considerate affidabili.

Figura 6: Verifica finale in Azure: stato “Signed and delegation established” indica che DNSSEC è attivo e la catena di fiducia è completa

Come posso verificare che tutto funzioni correttamente?

Per verificare che DNSSEC sia configurato correttamente potete utilizzare alcuni strumenti online.

Il più immediato è DNSViz: inserendo il vostro dominio ottenete una rappresentazione completa della catena di fiducia, con evidenza di eventuali errori o configurazioni mancanti. È molto utile perché vi mostra esattamente dove si interrompe la validazione.

Un’alternativa più semplice e diretta è Verisign DNSSEC Debugger, che esegue un controllo automatico e vi restituisce un esito chiaro sulla validità della configurazione, evidenziando eventuali problemi.

In generale, se tutto è configurato correttamente, vedrete che la chain of trust risulta valida e non vengono segnalati errori nella validazione DNSSEC.

La figura sotto mostra il risultato della verifica tramite DNSViz, uno degli strumenti più completi per analizzare DNSSEC. Quello che state vedendo è la rappresentazione grafica della catena di fiducia, dalla root fino al vostro dominio.

Ogni blocco rappresenta un livello della gerarchia DNS e include i record DNSKEY e DS utilizzati per la validazione. Le frecce indicano il collegamento tra una zona e quella superiore, ovvero il passaggio che consente di costruire la fiducia lungo tutta la catena.

L’elemento più importante è lo stato: nella colonna a sinistra vedete che tutto è marcato come “Secure”, il che significa che ogni passaggio della catena è valido e che le firme DNSSEC sono corrette. Anche il dettaglio in basso conferma lo stato SECURE, indicando che i resolver possono verificare senza problemi l’autenticità delle risposte DNS.

Figura 7: Verifica DNSSEC con DNSViz: la catena di fiducia risulta completa e lo stato è “Secure”

Qui di seguito vedete il risultato dell’analisi eseguita con il tool di Verisign. A differenza di DNSViz, qui l’approccio è più diretto: viene effettuata una serie di controlli sulla configurazione DNSSEC e ogni passaggio viene validato.

Tutti i check risultano contrassegnati in verde, il che indica che la zona è correttamente configurata. In particolare, vengono verificati i record DNSKEY, DS e le firme RRSIG, oltre alla coerenza tra zona figlia e zona padre.

Il fatto che non vengano segnalati errori conferma che la catena di fiducia è integra e che i resolver possono validare correttamente le risposte DNS. In pratica, avete la conferma operativa che DNSSEC è attivo e funziona come previsto.

Figura 8: Verifica DNSSEC con Verisign DNSSEC Debugger: tutti i controlli risultano validi e la configurazione è corretta

Cosa cambia per i client? sono tutti compatibili?

Per i client cambia meno di quanto possiate pensare, ed è proprio questo uno dei punti di forza di DNSSEC. Dal punto di vista operativo, le applicazioni e gli utenti continuano a fare query DNS esattamente come prima: non dovete modificare configurazioni lato client né adattare i vostri servizi.

La differenza reale sta nel fatto che, se il resolver utilizzato supporta DNSSEC, le risposte vengono validate automaticamente. In presenza di firme valide, tutto funziona in modo trasparente; se invece la validazione fallisce, il resolver scarta la risposta. Questo introduce un comportamento più sicuro, ma anche più rigoroso.

Non tutti i client “parlano” direttamente DNSSEC, ma questo non è un problema. La compatibilità è garantita perché DNSSEC è progettato per essere retrocompatibile: i resolver che non supportano la validazione ignorano semplicemente le firme e continuano a funzionare come sempre. Al contrario, resolver moderni come quelli di Google (8.8.8.8) o Cloudflare (1.1.1.1) eseguono la validazione e beneficiano della protezione.

L’unico aspetto da considerare è che, in caso di configurazioni errate, i client che utilizzano resolver con validazione attiva potrebbero non riuscire a risolvere il dominio, mentre altri continueranno a farlo. È quindi fondamentale che la configurazione DNSSEC sia corretta, perché introduce un modello “fail closed”: o è valido, o viene bloccato.

Conclusioni

In definitiva, DNSSEC aggiunge un livello di sicurezza fondamentale a un servizio spesso dato per scontato come il DNS. Anche se l’implementazione richiede qualche passaggio in più, soprattutto lato delega con il record DS, il risultato è una zona DNS verificabile e protetta da manipolazioni.