Cos'è DNSSEC? Una guida chiara alla sicurezza DNS

DNSSEC — abbreviazione di DNS Security Extensions — è l'unica difesa ampiamente implementata contro l'avvelenamento della cache DNS, l'attacco che permette a un avversario di rete di mentire ai resolver su dove punta il tuo dominio. È uno standard dal 2005, ogni grande TLD firma ora la sua zona, e ogni grande fornitore DNS gestito lo supporta. Se DNSSEC non è attivato sul tuo dominio pubblico, stai confidando che nessuno tra i tuoi utenti e il tuo server di nomi autoritativo abbia i mezzi o la motivazione per reindirizzarli a un luogo malevolo. È una scommessa che non è più ragionevole.

Questa guida è il punto d'ingresso in linguaggio chiaro: cosa fa realmente DNSSEC, perché esiste, come funziona la catena di fiducia ad alto livello, e cosa aspettarti dal tuo fornitore DNS. Per la meccanica operativa — ruoli KSK vs ZSK, rotazioni di chiavi, scelte di algoritmi — leggi la guida più approfondita Gestione delle chiavi DNSSEC una volta che hai le basi.

Cosa fa DNSSEC (e cosa non fa)

DNSSEC aggiunge firme digitali ai record DNS. Quando il tuo server autoritativo restituisce un record A che dice che example.com si trova a 192.0.2.1, restituisce anche una firma crittografica su quel record. Un resolver che supporta la validazione DNSSEC può controllare la firma rispetto alla chiave pubblica della tua zona — e controllare quella chiave pubblica rispetto a una catena che porta fino a un'ancora di fiducia codificata — e rifiutare di accettare la risposta se le firme non sono valide.

Questo è tutto il suo lavoro. DNSSEC:

• ✅ Dimostra che la risposta proviene dal server autoritativo corretto. Un attaccante man-in-the-middle non può falsificare un record senza rompere la firma.
• ✅ Rileva la manomissione sul cavo o in una cache. Anche se la cache di un resolver è avvelenata, le firme non validano.
• ✅ Dimostra che un record non esiste (anche le risposte negative sono firmate, tramite record NSEC/NSEC3).

DNSSEC non:

• ❌ Cifra le query o le risposte DNS. Chiunque osservi la rete può ancora vedere cosa stai cercando. Usa DNS over HTTPS o DNS over TLS per quello.
• ❌ Nasconde la struttura della tua zona. Le firme DNSSEC sono pubbliche; chiunque può recuperarle.
• ❌ Sostituisce TLS o HTTPS. DNSSEC protegge il DNS stesso; una volta che hai un indirizzo IP, la sicurezza della connessione spetta al protocollo dell'applicazione.
• ❌ Difende contro server autoritativi compromessi. Se un attaccante controlla il tuo server di nomi, può firmare ciò che vuole con le chiavi private della tua zona. DNSSEC si fida del titolare della chiave.

Perché esiste DNSSEC — Il problema dell'avvelenamento della cache

Il protocollo DNS originale degli anni '80 fu progettato per una rete dove nessuno cercava attivamente di imbrogliare. I resolver chiedevano ai server autoritativi risposte in UDP in chiaro e si fidavano di qualsiasi cosa tornasse purché l'IP di origine e un identificatore di transazione a 16 bit corrispondessero.

Quel modello di fiducia ha tenuto fino al 2008, quando Dan Kaminsky dimostrò l'avvelenamento della cache pratico su larga scala. L'attacco funziona così:

1. L'attaccante induce un resolver ricorsivo a cercare un nome che controlla (anything.example.com).
2. Mentre il resolver attende una risposta dal server autoritativo, l'attaccante lo inonda di risposte falsificate indovinando l'ID di transazione a 16 bit.
3. Se una risposta falsificata vince la corsa, il resolver memorizza nella cache la risposta dell'attaccante — un falso record A per example.com — e la serve a ogni query successiva per l'intero TTL.

Ogni utente di quel resolver — potenzialmente milioni di persone — è ora silenziosamente reindirizzato dove l'attaccante ha scelto. Traffico web, email, aggiornamenti software: tutto instradato al server dell'attaccante fino a quando la voce di cache errata scade.

La community DNS ha risposto con tre livelli di mitigazione:

1. Randomizzazione della porta sorgente ai resolver (RFC 5452, 2009) — ha reso la corsa molto più difficile aggiungendo 16 bit in più di imprevedibilità.
2. DNS over HTTPS / DNS over TLS sull'hop resolver-to-client — ha cifrato la conversazione in modo che un attaccante sulla rete locale non possa né vedere né alterare le query.
3. DNSSEC sull'hop autoritativo-to-resolver — ha aggiunto firme crittografiche in modo che una cache avvelenata produca firme non valide che un resolver validante rifiuta.

DNSSEC è l'unico dei tre che effettivamente risolve il problema sottostante a livello autoritativo. La randomizzazione della porta sorgente rende l'attacco più difficile; DoH/DoT cambia chi può vedere la query ma non chi può mentire sulla risposta. DNSSEC verifica la risposta stessa.

La catena di fiducia — Una vista ad alto livello

Ciò che fa funzionare DNSSEC su scala Internet è che i resolver non hanno bisogno di conoscere in anticipo la tua chiave pubblica specifica. Invece, percorrono una catena di fiducia da una chiave radice codificata fino alla tua zona:

Zona radice (.)
    │  firma con KSK radice
    │  pubblica record DS per .com nella radice
    ▼
TLD .com
    │  firma con KSK .com
    │  pubblica record DS per example.com in .com
    ▼
example.com
    │  firma tutti i record con le proprie chiavi
    │  firma sul record richiesto
    ▼
Record A: example.com → 192.0.2.1

Un resolver validante segue questa catena al contrario:

1. Riceve il record A firmato dal tuo server autoritativo.
2. Recupera il record DS per example.com dai server di nomi .com e controlla che l'hash corrisponda alla KSK della tua zona.
3. Recupera il record DS per .com dai server radice e controlla l'hash rispetto alla KSK della zona .com.
4. Controlla la firma della zona radice rispetto all'ancora di fiducia codificata (la KSK radice, anche pubblicata da IANA su https://data.iana.org/root-anchors/).

Se qualsiasi anello della catena non riesce a verificare, la risposta viene trattata come non affidabile. La maggior parte dei resolver validanti restituirà SERVFAIL piuttosto che servire una risposta potenzialmente manomessa.

Non è necessario comprendere la meccanica per usare DNSSEC. Il tuo fornitore DNS genera e ruota le chiavi per te; il tuo unico compito è pubblicare un pezzo — il record DS — presso il tuo registrar in modo che la catena raggiunga la tua zona.

Per la suddivisione meccanica completa — ruoli KSK vs ZSK, record RRSIG, NSEC/NSEC3 per la negazione autenticata — vedi Come funziona DNSSEC.

Come capire se un dominio ha DNSSEC

Esegui dig con il flag +dnssec contro un resolver validante:

dig +dnssec example.com @1.1.1.1

Cerca due cose:

1. Record RRSIG nella sezione risposta, abbinati a ciascun set di record interrogato. Quelle sono le firme.
2. Il flag AD (Authenticated Data) nell'intestazione della risposta, che indica che il resolver ha validato con successo la catena.

;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
                                ^^
                                 │
                          flag AD impostato = validazione riuscita
 
;; ANSWER SECTION:
example.com.         300  IN  A      192.0.2.1
example.com.         300  IN  RRSIG  A 13 2 300 20260601000000 ...
                                         ^^
                                          │
                                   record di firma

Se vedi gli RRSIG ma nessun flag AD, il resolver non sta validando — prova 1.1.1.1 o 9.9.9.9, entrambi validano per impostazione predefinita. Se non vedi RRSIG, la zona non è firmata.

Per la visualizzazione, DNSViz e il DNSSEC Debugger di Verisign disegnano la catena di fiducia completa ed evidenziano qualsiasi rottura.

Quando attivare DNSSEC

In breve: sempre, per qualsiasi dominio pubblico.

Casi specifici dove è particolarmente importante:

• Servizi ad alta fiducia — banche, e-commerce, fornitori di identità, governo — dove un attacco di avvelenamento della cache riuscito ha conseguenze dirette.
• Email — DNSSEC è prerequisito per DANE/TLSA, che protegge il TLS SMTP contro gli attacchi di downgrade. MTA-STS è un'alternativa parziale per le organizzazioni non ancora pronte per DANE.
• Soggetti UE regolati ai sensi di NIS2 — l'Articolo 21(2)(h) richiede "politiche e procedure sull'uso della crittografia". Un fornitore DNS che non offre DNSSEC, o un deployment che non l'ha attivato, rischia di essere giudicato non conforme. Vedi la guida NIS2 e DNS per la mappatura completa.
• Ambienti guidati dalla conformità — PCI DSS, HIPAA, ISO 27001 e vari framework nazionali elencano DNSSEC come controllo raccomandato o atteso.

Essenzialmente non ci sono situazioni in cui DNSSEC sia una cattiva idea per una zona pubblica. Le obiezioni storiche — complessità operativa, rischio di gestione delle chiavi, compatibilità del resolver — sono in gran parte risolte dai fornitori DNS gestiti che gestiscono automaticamente generazione, rotazione e pubblicazione DS.

Cosa cercare in un fornitore DNS abilitato DNSSEC

Quando valuti il supporto DNSSEC di un fornitore DNS, chiedi:

Attivare DNSSEC su DNScale

DNScale attiva DNSSEC con un clic per zona:

1. Dalla dashboard, apri la zona.
2. Clicca su Attiva DNSSEC. DNScale genera una CSK (Combined Signing Key) usando ECDSA P-256.
3. Copia il record DS visualizzato presso il tuo registrar. Alcuni registrar lo accettano direttamente; alcuni via API; alcuni richiedono ancora inserimento manuale.
4. Attendi 24–48 ore affinché il DS si propaghi al TLD.
5. Verifica con dig +dnssec tuodominio @1.1.1.1 e conferma il flag AD.

La rotazione delle chiavi, il refresh delle firme e la sincronizzazione con la zona padre avvengono automaticamente. Gli aggiornamenti degli algoritmi sono roll coordinati che DNScale esegue senza downtime visibile al cliente.

Per il passo-passo completo incluse le istruzioni specifiche per registrar, vedi Guida all'installazione DNSSEC per DNScale. Per la meccanica sottostante, vedi Come funziona DNSSEC e Gestione delle chiavi DNSSEC.

Riferimenti

• RFC 4033 — Introduzione e requisiti DNS Security
• RFC 4034 — Resource Records per le DNS Security Extensions
• RFC 4035 — Modifiche al protocollo per le DNS Security Extensions
• RFC 5155 — DNS Security (DNSSEC) Hashed Authenticated Denial of Existence (NSEC3)
• RFC 6781 — DNSSEC Operational Practices, Version 2
• RFC 8901 — Modelli DNSSEC multi-firmatario
• Ancore di fiducia radice IANA
• DNSViz — visualizzatore per catene di fiducia DNSSEC
• DNSSEC Debugger di Verisign

Letture correlate

• Come funziona DNSSEC — meccanica KSK/ZSK/DS/DNSKEY
• Gestione delle chiavi DNSSEC — procedure operative di rotazione
• Guida all'installazione DNSSEC per DNScale — passo-passo del prodotto
• DNSSEC vs DNS over HTTPS — integrità vs privacy
• NIS2 e conformità DNS — mappatura normativa
• Avvelenamento della cache DNS — l'attacco che DNSSEC sconfigge