Come funziona DNSSEC — KSK, ZSK, DS, DNSKEY, RRSIG, NSEC spiegati

DNSSEC autentica i dati DNS attraverso una gerarchia di firme crittografiche che si concatenano da un record nella tua zona fino a un'ancora di fiducia codificata in ogni resolver validante. Questa guida percorre i pezzi mobili — DNSKEY, DS, RRSIG, NSEC/NSEC3, e i ruoli KSK/ZSK — a un livello che ti permette di ragionare sui deployment reali senza essere un crittografo.

Per le procedure operative di rotazione (pre-publish ZSK, double-signature KSK, rotazione algoritmo), continua con Gestione delle chiavi DNSSEC. Per l'introduzione ad alto livello senza la meccanica, la pagina Cos'è DNSSEC? è un punto di partenza migliore.

I record coinvolti

DNSSEC introduce quattro tipi di record in una zona firmata, più i record DS pubblicati nella zona padre:

Chiavi di firma: KSK, ZSK, CSK

DNSSEC ha storicamente usato una divisione a due chiavi: una KSK per operazioni ad alto valore e bassa frequenza e una ZSK per operazioni ad alta frequenza e cerimonia inferiore. La motivazione è puramente operativa — crittograficamente, entrambe le chiavi fanno la stessa cosa (firmare dati con una chiave privata, verificare con una pubblica).

Zone-Signing-Key (ZSK)

La ZSK firma tutto nella tua zona eccetto il set di record DNSKEY. Quando un resolver chiede i record A di example.com, la risposta torna con un RRSIG corrispondente firmato dalla ZSK. Ogni set di record firmato ha il suo RRSIG.

Le ZSK sono tipicamente:

• Più piccole (RSA 1024 bit era comune nei primi deployment; ECDSA P-256 / 256 bit è la norma moderna)
• Ruotate relativamente spesso (ogni 1–3 mesi storicamente; alcuni operatori ora saltano rotazioni programmate con stoccaggio chiavi forte)
• Più facili da ruotare perché il record DS della zona padre non deve cambiare

Key-Signing-Key (KSK)

La KSK firma solo il set di record DNSKEY. Quel set contiene la parte pubblica di ogni chiave di firma attiva nella zona. Firmando il set DNSKEY con la KSK, leghi ogni altra chiave nella zona (specificamente, ogni ZSK attiva) a una chiave il cui hash è pubblicato presso il padre.

Le KSK sono tipicamente:

• Più grandi (RSA 2048 bit, ECDSA P-256 o Ed25519 sono tutti comuni)
• Ruotate raramente (ogni 1–5 anni, o solo in caso di sospetto compromesso)
• Più costose da ruotare perché il record DS presso il padre deve essere aggiornato, il che coinvolge il registrar e i tempi del TLD

Combined Signing Key (CSK)

Una CSK ricopre entrambi i ruoli in un'unica chiave. La stessa chiave firma DNSKEY (ruolo KSK) e altri set di record (ruolo ZSK). I deployment moderni usano sempre più CSK con ECDSA P-256 o Ed25519, perché:

• Le firme sono abbastanza piccole che il costo per query è trascurabile
• La complessità operativa è inferiore (una chiave da gestire, una rotazione da coordinare)
• Lo stoccaggio basato su HSM riduce l'argomento di sicurezza per separare KSK e ZSK

DNScale di default usa CSK con ECDSA P-256 per le nuove zone, che è lo standard per la maggior parte dei fornitori gestiti moderni.

DNSKEY: Pubblicare chiavi pubbliche nella zona

Ogni chiave di firma attiva ha la sua parte pubblica pubblicata come record DNSKEY all'apice della zona:

example.com.   3600   IN   DNSKEY   257 3 13 oJMR...                        ; KSK
example.com.   3600   IN   DNSKEY   256 3 13 mZXp...                        ; ZSK

Decodifica dei campi:

• Flag (257 o 256): il bit 7 (SEP — Secure Entry Point) è impostato sulla KSK, dando 257. La ZSK ha 256. Entrambi i formati condividono il bit 8 (Zone Key) che è sempre impostato in DNSKEY.
• Protocollo (3): sempre 3 in DNSSEC valido.
• Algoritmo (13 qui): 13 = ECDSA P-256, 8 = RSA SHA-256, 15 = Ed25519. Vedi algoritmi DNSSEC IANA per la lista completa.
• Chiave pubblica (codificata base64): il materiale di chiave reale.

Un resolver validante recupera il set DNSKEY quando valida qualsiasi record dalla tua zona, e usa la chiave appropriata (KSK per il RRSIG del DNSKEY stesso, ZSK per tutto il resto).

RRSIG: Le firme

Ogni set di record firmato nella tua zona è accompagnato da uno o più record RRSIG — uno per chiave di firma attiva per quel ruolo. Un RRSIG appare così:

example.com.   3600   IN   A      192.0.2.1
example.com.   3600   IN   RRSIG  A 13 2 3600 20260601000000 20260501000000 12345 example.com. 4kQp...

I campi RRSIG:

• Tipo coperto (A): il tipo di set di record che viene firmato.
• Algoritmo (13): deve corrispondere all'algoritmo DNSKEY.
• Etichette (2): numero di etichette nel nome firmato originale.
• TTL originale (3600): il TTL che il set di record aveva quando è stato firmato.
• Scadenza firma (20260601000000) e inizio (20260501000000): timestamp UTC. La firma è valida solo in questa finestra.
• Tag chiave (12345): identificatore corto di quale DNSKEY nella zona ha prodotto questa firma. Corrisponde al tag chiave del record DNSKEY corrispondente.
• Nome firmatario (example.com.): la zona la cui chiave ha firmato questo.
• Firma (codificata base64): la firma crittografica reale.

Le finestre di scadenza delle firme sono il motivo per cui DNSSEC è non banale operativamente. Se il tuo server autoritativo smette di re-firmare la zona — anche brevemente —, le firme inizieranno a scadere, i resolver validanti inizieranno a restituire SERVFAIL, e il tuo dominio andrà effettivamente offline. I fornitori DNS gestiti re-firmano automaticamente; il DNSSEC self-hosted richiede una pipeline di firma funzionante.

Record DS: Il collegamento con il padre

Il record DS (Delegation Signer) è il cardine che collega la tua zona alla catena di fiducia globale. Vive nella zona padre (.com, .eu, .de, ecc.) e contiene un hash della tua KSK. Non lo aggiungi alla tua zona — lo pubblichi presso il tuo registrar, che lo passa al registry del TLD.

Un record DS nella zona padre appare così:

example.com.   86400   IN   DS   12345 13 2 7c89...

Campi:

• Tag chiave (12345): identificatore di quale KSK questo DS hasha (corrisponde al tag chiave DNSKEY).
• Algoritmo (13): deve corrispondere all'algoritmo DNSKEY.
• Tipo digest (2): SHA-256 (2) o SHA-384 (4) — SHA-1 (1) è deprecato.
• Digest (codificato hex): l'hash reale.

Quando un resolver validante vuole autenticare la tua zona, recupera il record DS dal padre (es. dai server di nomi .com), poi recupera il tuo set DNSKEY, calcola l'hash della KSK corrispondente, e controlla che eguagli il digest nel DS. Se corrispondono, il resolver si fida del set DNSKEY della tua zona, e per estensione dei RRSIG firmati con quelle chiavi.

Questo è l'unico collegamento automatizzato dall'esterno della tua zona al materiale chiave della tua zona. Sbaglia il DS e la validazione DNSSEC fallisce — o peggio, il tuo dominio diventa irrisolvibile per i client validanti.

NSEC e NSEC3: Negazione autenticata

Un problema sottile ma importante: DNSSEC non può solo firmare i record che esistono. Deve anche dimostrare, quando un resolver chiede nonexistent.example.com, che il nome realmente non esiste piuttosto che la risposta venga silenziosamente persa o falsificata.

Il meccanismo è NSEC (RFC 4034) o NSEC3 (RFC 5155).

NSEC

I record NSEC sono ordinati alfabeticamente e si concatenano attraverso i nomi che esistono nella zona. Per esempio:

alpha.example.com.    NSEC  gamma.example.com.   A NSEC RRSIG
gamma.example.com.    NSEC  zulu.example.com.    A NSEC RRSIG
zulu.example.com.     NSEC  alpha.example.com.   A NSEC RRSIG     ; ricomincia dall'inizio

Un resolver che chiede beta.example.com riceve indietro l'NSEC firmato per alpha.example.com, che dimostra che non c'è nulla tra alpha e gamma — quindi beta non esiste. La firma sull'NSEC autentica la risposta negativa.

L'inconveniente: i record NSEC enumerano pubblicamente ogni nome nella zona. Chiunque cammini lungo la catena NSEC può costruire un elenco completo di ogni nome di record. Questo è "zone walking" e talvolta è considerato una fuga di privacy.

NSEC3

NSEC3 registra la stessa catena ma usa nomi hashati invece di nomi in chiaro, più un conteggio di iterazioni e un sale:

< hash di alpha >.example.com.    NSEC3 1 0 10 abcd123...    < hash di gamma > A RRSIG NSEC3

I resolver possono verificare la negazione come prima (calcolare l'hash del nome interrogato, trovare quale NSEC3 lo copre), ma un attaccante non può banalmente camminare attraverso la zona — dovrebbe rompere ogni hash. NSEC3 supporta anche l'opt-out, che permette ai registry di saltare la firma di delegazioni non firmate per evitare di dover NSEC3-firmare ogni sottozona inesistente.

Raccomandazione moderna: NSEC3 con iterazioni=0 e un sale fisso (o nessun sale). Conteggi di iterazioni alti aggiungono costo CPU senza significativo beneficio di privacy perché gli attaccanti con GPU possono rompere qualsiasi conteggio non zero. L'approccio "white lies" (RFC 4470) è un altro modo per ridurre il rischio di zone walking mantenendo la semplicità di NSEC.

Il flusso di validazione — Passo per passo

Cosa succede effettivamente quando un resolver validante riceve una risposta firmata DNSSEC? Percorrendo dig +dnssec example.com @1.1.1.1:

1. Il resolver riceve il record A + RRSIG dal tuo server autoritativo.
2. Il resolver recupera il set DNSKEY della tua zona + RRSIG. Ora ha sia i dati che le chiavi (in forma pubblica) necessarie per verificare tutto.
3. Il resolver verifica il RRSIG dei dati rispetto alla ZSK nel set DNSKEY. Se la firma non è valida, la validazione fallisce immediatamente.
4. Il resolver verifica il RRSIG del DNSKEY rispetto alla KSK nel set DNSKEY. La KSK ha firmato il set di record DNSKEY, inclusa la ZSK. Questo passaggio blocca la ZSK alla KSK.
5. Il resolver recupera il record DS dalla zona padre (es. dai server di nomi .com). Il DS contiene un hash della KSK.
6. Il resolver calcola l'hash della KSK e lo confronta con il DS. Se corrispondono, il padre ha confermato quale KSK è autoritativa per la tua zona.
7. Il resolver ripete la catena al padre. Il record DS stesso è firmato dalla ZSK della zona padre; il set DNSKEY del padre è firmato dalla KSK del padre; la KSK del padre è hashata nel DS della zona nonna, e così via, fino alla radice.
8. Alla radice, il resolver confronta l'hash della KSK radice con l'ancora di fiducia che ha codificato (o auto-aggiornato tramite RFC 5011). La KSK radice attuale è pubblicata su https://data.iana.org/root-anchors/.

Se ogni firma verifica e la radice si concatena fino all'ancora di fiducia, il resolver restituisce la risposta con il flag AD (Authenticated Data) impostato. Qualsiasi fallimento lungo il percorso e il resolver restituisce SERVFAIL — meglio rompere che servire una risposta potenzialmente manomessa.

Cosa può andare storto

I primi due — DS obsoleto e firme scadute — causano la grande maggioranza delle interruzioni DNSSEC reali. I fornitori gestiti gestiscono automaticamente la re-firma; il record DS presso il registrar è il punto di fallimento toccabile dall'umano.

Mettendo tutto insieme — Un modello mentale

L'apparente complessità di DNSSEC è per lo più contabilità. La vera domanda crittografica è semplice: questa risposta proviene da qualcuno che controlla la chiave privata della zona? La catena di fiducia è una serie di vincoli a chiave pubblica, ognuno un normale passaggio "chiave A firma chiave B" o "chiave A firma dati D":

• La KSK radice firma il set DNSKEY radice (che include la ZSK radice).
• La ZSK radice firma i record DS dei TLD.
• La KSK di un TLD firma il set DNSKEY del TLD (che include la ZSK del TLD).
• La ZSK del TLD firma i record DS delle zone registrate.
• La KSK della tua zona firma il tuo set DNSKEY (che include la tua ZSK).
• La tua ZSK firma ogni set di record nella tua zona — inclusi i record NSEC/NSEC3 che gestiscono la negazione.

Ogni anello è solo una firma; la magia è che il resolver ha bisogno solo della chiave radice per verificarli tutti.

Riferimenti

• RFC 4033 — Introduzione e requisiti DNS Security
• RFC 4034 — Resource Records per le DNS Security Extensions (DNSKEY, DS, NSEC, RRSIG)
• RFC 4035 — Modifiche al protocollo per le DNS Security Extensions
• RFC 5155 — DNSSEC Hashed Authenticated Denial of Existence (NSEC3)
• RFC 6781 — DNSSEC Operational Practices, Version 2
• RFC 7344 / 8078 — Automating DNSSEC Delegation Trust Maintenance (CDS / CDNSKEY)
• RFC 8624 — Algorithm Implementation Requirements and Usage Guidance for DNSSEC
• RFC 8901 — Modelli DNSSEC multi-firmatario
• Numeri algoritmo DNSSEC IANA
• Ancore di fiducia radice IANA

Letture correlate

• Cos'è DNSSEC? — introduzione top-of-funnel
• 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
• Avvelenamento della cache DNS — l'attacco che DNSSEC sconfigge
• NIS2 e conformità DNS — DNSSEC come controllo normativo