Cos'è DNSSEC?
DNSSEC (Domain Name System Security Extensions) aggiunge firme digitali agli insiemi di record DNS. Un resolver che convalida DNSSEC può usare firme valide e una catena di fiducia per autenticare i dati firmati e rilevare modifiche non autorizzate. DNSSEC non cifra le query o le risposte DNS.Come funziona DNSSEC
Catena di fiducia (esempio con chiavi separate):
Zona radice (.)
├── KSK della zona radice (trust anchor) firma l'RRset DNSKEY della zona radice
└── ZSK della zona radice firma gli RRset autoritativi della zona radice, incluso l'RRset DS per .com pubblicato nella zona padre
└── Il digest del DS corrisponde alla KSK di .com
├── KSK di .com firma l'RRset DNSKEY di .com
└── ZSK di .com firma gli RRset autoritativi di .com, incluso l'RRset DS per example.com pubblicato nella zona padre
└── Il digest del DS corrisponde alla KSK di example.com
├── KSK di example.com firma l'RRset DNSKEY di example.com
└── ZSK di example.com firma gli RRset autoritativi di example.com
Il resolver convalida le firme e i digest DS partendo dal trust anchor della zona radice
Tipi di record DNSSEC
| Record | Funzione | Descrizione |
|---|---|---|
| RRSIG | Firma digitale | Firma digitale di un insieme di record (RRset) |
| DNSKEY | Chiave pubblica | Contiene le chiavi pubbliche della zona usate per verificare le firme |
| DS | Autenticazione della delegazione | Digest della DNSKEY della zona figlia, pubblicato nella zona padre |
| NSEC/NSEC3 | Negazione autenticata | Fornisce una prova autenticata che un nome o un record non esiste |
Tipi di chiave
| Chiave | Funzione | Frequenza di rotazione |
|---|---|---|
| KSK (Key Signing Key) | Firma i record DNSKEY | Dipende dalla policy; vedi la nota seguente |
| ZSK (Zone Signing Key) | Firma gli altri RRset autoritativi, incluso l'RRset NS all'apice della zona; gli RRset NS delle deleghe nella zona padre e gli RRset di indirizzi glue associati non sono firmati ([RFC 4035 §2.2](https://www.rfc-editor.org/rfc/rfc4035.html#section-2.2)) | Dipende dalla policy; vedi la nota seguente |
La cadenza del rollover dipende dal ruolo della KSK e dalla policy dell'operatore. Per una KSK collegata a un record DS nella zona padre, la [sezione 3.3 di RFC 6781](https://www.rfc-editor.org/rfc/rfc6781.html#section-3.3) descrive un anno come intervallo ragionevole quando si sceglie un rollover regolare. Una KSK usata come trust anchor richiede coordinamento con i resolver che la convalidano e può avere un periodo di validità molto più lungo ([RFC 6781, §3.2.2](https://www.rfc-editor.org/rfc/rfc6781.html#section-3.2.2)).
Anche la durata della ZSK dipende dalla policy dell'operatore e dai vincoli del rollover. Per una ZSK online in un contesto a rischio più elevato, [RFC 6781 §3.3](https://www.rfc-editor.org/rfc/rfc6781.html#section-3.3) indica che può essere ragionevole prevedere una durata di un mese. Si tratta di un'indicazione condizionata, non di un intervallo universale. La pianificazione del rollover della ZSK deve considerare i TTL dei record DNSKEY e delle RRSIG, i tempi di propagazione della zona e l'intervallo necessario perché le vecchie RRSIG siano sostituite nella zona e le copie già presenti nelle cache dei resolver vi restino solo fino all'esaurimento del rispettivo TTL ([RFC 7583 §3.2.1](https://www.rfc-editor.org/rfc/rfc7583.html#section-3.2.1)).
Rollover della KSK della zona radice dell'11 ottobre 2026
ICANN indica che il rollover della KSK della zona radice è programmato per l'11 ottobre 2026. Gli operatori dei resolver che convalidano DNSSEC dovrebbero verificare che KSK-2024 (key tag 38696) sia presente nella configurazione dei trust anchor. Non dare per scontato che gli aggiornamenti automatici dei trust anchor siano riusciti. Se la chiave manca, verificare che gli aggiornamenti automatici siano abilitati e seguire le indicazioni del fornitore del resolver. Per i dettagli aggiornati, consulta [le indicazioni di ICANN sul rollover della KSK della zona radice](https://www.icann.org/resources/pages/ksk-rollover-en).
Processo di convalida DNSSEC
1. Il client chiede a un resolver DNS il record A di example.com
2. Il resolver recupera il record A con la relativa firma RRSIG
3. Il resolver recupera il record DNSKEY per verificare la firma RRSIG
4. Il resolver verifica la DNSKEY confrontandola con il record DS
5. La catena di fiducia prosegue fino alla zona radice, verificando ogni livello
6. Se tutte le firme sono valide, la risposta è autenticata
Cosa può rilevare la convalida DNSSEC
Questi controlli richiedono RRset firmati e un resolver che convalidi DNSSEC con una catena di fiducia integra. I dati non firmati o considerati insicuri non possono essere autenticati.
| Minaccia | Esempio | Protezione DNSSEC |
|---|---|---|
| Avvelenamento della cache | Inserimento di dati DNS falsificati nella cache di un resolver | Un resolver che convalida DNSSEC può rifiutare i dati che non superano la verifica della firma o della catena di fiducia. |
| Manomissione della risposta | Modifica in transito di un insieme di record DNS firmato | I dati modificati non superano la verifica della firma. |
| Falsificazione DNS | Fornitura di una risposta falsificata per una zona firmata | Un resolver che convalida DNSSEC può rifiutare una risposta che non supera la convalida. |
Considerazioni di attuazione
- Performance: risposte più grandi a causa delle firme (~1000-4000 byte vs ~100 byte)
- Gestione delle chiavi: richiede la generazione sicura delle chiavi, la loro conservazione e rotazione
- Firma della zona: La zona va firmata di nuovo quando cambiano i record
- Supporto dei resolver: Per usare DNSSEC, i client hanno bisogno di resolver che convalidino DNSSEC.
Migliori Pratiche
1. Scegliere un algoritmo di firma DNSSEC: il [registro IANA degli algoritmi DNSSEC](https://www.iana.org/assignments/dns-sec-alg-numbers) raccomanda ECDSAP256SHA256 (algoritmo 13) per la firma e la convalida. ECDSAP384SHA384 (14) può essere adatto alle applicazioni che richiedono un livello di sicurezza di 192 bit; verifica il supporto dei resolver prima di cambiare algoritmo ([RFC 9904](https://www.rfc-editor.org/rfc/rfc9904.html), [RFC 8624 §3.1](https://www.rfc-editor.org/rfc/rfc8624.html#section-3.1)).
2. Automatizzare la rotazione delle chiavi: usa strumenti come OpenDNSSEC per gestirne il ciclo di vita
3. Monitorare la scadenza delle firme RRSIG: ogni firma ha un periodo di validità
4. Testare prima della distribuzione: convalida la zona con strumenti come dnsviz.net
5. Pianificare le emergenze: documenta le procedure di rollover delle chiavi
La convalida DNSSEC autentica i dati DNS firmati, ma non dimostra che il sito web o il server raggiunto sia affidabile.