Implementare DNSSEC: firma, gestione delle chiavi e casi d'errore comuni

Implementare DNSSEC è per molti team IT un passo necessario per garantire l’integrità della risoluzione dei nomi. DNSSEC (Domain Name System Security Extensions) assicura che le risposte dal DNS non siano state manomesse, firmando crittograficamente le zone. Questo contributo spiega in modo pratico quali prerequisiti verificare, come generare e gestire KSK e ZSK, come funziona la pubblicazione dei record DS presso il registrar e quali errori tipici si presentano — con strategie di verifica e di fallback per l’esercizio in produzione.

Perché DNSSEC e a chi è rilevante

DNSSEC protegge da manipolazioni come cache poisoning e attacchi man-in-the-middle sulle risposte DNS. Per i gestori di zone interne ed esterne, in particolare per soluzioni software sensibili ai processi, DNSSEC è rilevante perché risposte DNS errate impattano direttamente autenticazione, consegna delle e-mail, endpoint API e raggiungibilità dei servizi. È importante: DNSSEC protegge l’integrità e l’autenticità delle risposte DNS, non la riservatezza (quindi non i contenuti).

Nozioni di base: termini, architettura e catena di fiducia

Termini importanti spiegati brevemente: KSK (Key Signing Key) è una coppia di chiavi che firma solo le chiavi di firma della zona (ZSK); la KSK funge da trust anchor (ancora di fiducia). ZSK (Zone Signing Key) firma i dati effettivi della zona (Resource Records). DS (Delegation Signer) è il record nella zona sovraordinata (parent) che riassume la chiave pubblica della KSK e crea così la catena di fiducia verso la root. I validator (resolver con supporto DNSSEC) verificano questa catena per classificare una risposta come „secure“.

Cruciale è l’interazione: si firma la propria zona con una ZSK; la ZSK è assicurata dalla KSK; la KSK è verificata tramite un record DS nella zona parent. Se la catena è interrotta in un qualsiasi punto (DS mancante, chiave obsoleta, firme scadute), i validator possono restituire SERVFAIL e i client non raggiungono più i servizi.

Requisiti e considerazioni di pianificazione prima dell’implementazione

Prima di iniziare la firma, verifichi:

• Il suo Registrar/Provider dispone di accesso API o UI per le voci DS? Molti registrar offrono l’upload automatico soltanto tramite interfacce specifiche.
• Il server DNS autorevole supporta DNSSEC (BIND, Knot, PowerDNS, NSD)? Quali strumenti per la firma sono disponibili?
• Le chiavi devono essere memorizzate su un HSM (Hardware Security Module)? L’HSM aumenta la sicurezza, ma comporta oneri operativi e costi.
• Esiste un dominio di test o un ambiente di staging in cui possa provare il rollout?

Guida passo-passo: firmare la zona (procedura pratica)

L’esempio seguente descrive il flusso di lavoro di base con gli strumenti BIND (dnssec-keygen, dnssec-signzone). Viene spiegato non solo il „come“, ma anche il „perché“.

1) Generare le chiavi (KSK e ZSK)

La ZSK è normalmente più piccola (e ruota più frequentemente) della KSK. Le KSK dovrebbero essere cambiate meno frequentemente e protette meglio (eventualmente offline o su HSM). Esempio con dnssec-keygen:

# ZSK (RFC-conforme: es. RSASHA256, 2048 bit)
dnssec-keygen -a RSASHA256 -b 2048 -n ZONE example.com

# KSK (più lunga, es. 4096 bit, pensata come trust anchor)
dnssec-keygen -a RSASHA256 -b 4096 -n ZONE -f KSK example.com

Perché così? Chiavi di firma più piccole (ZSK) riducono il carico CPU durante la firma; KSK più grandi aumentano la sicurezza per il trust anchor. L’opzione -f KSK contrassegna la chiave come Key Signing Key (KSK).

2) Firmare la zona

La firma genera RRSIG (firme) e record DNSKEY che vengono integrati nel file di zona. Esempio:

# Assunzione: file di zona example.com.zone
# dnssec-signzone genera un file di zona firmato
dnssec-signzone -A -3 randomsalt -N increment -o example.com -t example.com.zone

Le opzioni: -A abilita la gestione automatica delle chiavi, -3 genera il salt per NSEC3, -N incrementa la seriale in modo pulito. Dopo l’esecuzione si ottiene un file come example.com.zone.signed, che il server autoritativo deve servire.

3) Convertire il DNSKEY in DS e pubblicarlo nella zona parent

Solo la voce DS nella zona parent collega la sua zona alla catena di trust sovraordinata. Viene creata a partire dalla KSK:

# Creare il DS dalla KSK (sha256 è comune)
dnssec-dsfromkey Kexample.com.+008+12345.key

# Output: example.com. IN DS 12345 8 2 
# Inserire questo valore DS presso il Registrar/zona parent

Perché funziona: il DS è un hash del record DNSKEY (KSK pubblico). Il parent conserva questo hash; i resolver, durante la validazione, confrontano l’hash con il DNSKEY presente nella sua zona.

Gestione delle chiavi: conservazione, backup e HSM

Il key management comprende protezione, rotazione e ripristino. Regole e opzioni:

• HSM: Se utilizza un HSM (interfaccia PKCS#11), le chiavi private rimangono protette fisicamente. Questo ha senso per le KSK, meno obbligatorio per le ZSK, a seconda del profilo di rischio.
• Offline-KSK: Conservi le chiavi private KSK offline (p. es. su un host spento o su un HSM), per prevenire il furto.
• Backup & Recovery: Crei backup sicuri e cifrati delle chiavi, inclusi export PKCS#12 protetti da password o archivi cifrati. Testi regolarmente il ripristino.
• Logging & Audit: Ogni operazione sulla chiave (generazione, rollout, cancellazione) dovrebbe essere registrata, idealmente in un sistema a prova di revisione.

Integrazione con KMS e automazione

Molti team integrano sistemi di gestione chiavi (Cloud-KMS o HashiCorp Vault) tramite PKCS#11 o API. Vantaggi: audit centralizzato, rotazione automatizzata; svantaggi: nuova superficie d’attacco, dipendenza dalla disponibilità. Cruciale è un piano di ripristino testato nel caso in cui il KMS non sia raggiungibile.

Key Rollover: strategie per ZSK e KSK

Rollover significa la sostituzione di una chiave con una nuova. Esistono due tipi: ZSK-Rollover e KSK-Rollover. Ognuno ha una sequenza tipica e rischi.

ZSK-Rollover (frequente, automatizzabile)

I ZSK vengono spesso rinnovati automaticamente e a intervalli brevi (p. es. 1–3 mesi), poiché sono usati più frequentemente per la firma. Procedura:

1. Generazione di nuovi ZSK.
2. Pubblicazione: nuovi DNSKEY nella zona senza rimuovere subito i vecchi ZSK.
3. Lasciare proseguire la firma finché le vecchie firme non scadono.
4. Rimuovere i vecchi ZSK.

Rischio: dimenticare di mantenere le vecchie firme per un periodo sufficiente porta a firme non valide. L’automazione tramite dnssec-signzone o la rotazione chiavi integrata del server riduce gli errori.

KSK-Rollover (pianificato con cura)

Il KSK-Rollover è più complesso perché l’entry DS presso il parent deve essere aggiornato. Procedura (flusso sicuro in due fasi):

1. Pre-Publish: Generi il nuovo KSK e pubblichi il nuovo DNSKEY pubblico nella sua zona, in parallelo al KSK precedente.
2. Fase di discrepanza: attenda affinché i resolver apprendano la nuova chiave come „known“; firmi con la ZSK come di consueto.
3. Update Parent: Generi il valore DS dal nuovo KSK e lo registri presso il registrar/parent (o utilizzi l’automatismo CDS/CDNSKEY, se supportato).
4. Roll: Rimuova successivamente il vecchio KSK dalla sua zona, quando il parent ha accettato il nuovo DS e non si verificano errori dei validator.

Perché tanto lavoro? Un cambio KSK errato o prematuro senza il DS corretto interrompe l’albero di trust e provoca interruzioni per i validator.

Opzioni di automazione: CDS/CDNSKEY, API e CI/CD

CDS e CDNSKEY sono RFC per la pubblicazione automatica del DS presso il registrar: la sua zona pubblica record CDS/DNSKEY e un registrar compatibile può trasferirli automaticamente nella zona parent. Vantaggio: possibile KSK-rollover automatico. Svantaggio: molti registrar non lo supportano ancora o solo tramite workflow specifici; pertanto testare in anticipo.

Alternativa: integrare le API del registrar con pipeline CI/CD. Esempio: il job di firma genera il DS, la pipeline chiama l’API del registrar per l’immissione, verifica il successo e notifica il team. Prevedere sempre misure di sicurezza e l’approvazione umana per le modifiche al KSK.

Verifica e validazione: strumenti e sequenze di controllo tipiche

Controlli essenziali da eseguire sempre:

• Verifica locale delle firme: assicuri che siano presenti record RRSIG.
• Validazione DNS da un resolver pubblico: controlli la chain-of-trust fino al parent/root.
• Monitori le date di scadenza delle firme (RRSIG Expiration) e la scadenza delle chiavi (Key-Expiry).

Comandi pratici di verifica

# Verificare se la zona ha RRSIG
dig +dnssec example.com SOA

# Verificare la catena: mostra se la risposta è contrassegnata come 'ad' (authentic data)
dig +dnssec @8.8.8.8 example.com A

# Verificare il DS pubblicato presso il parent (es. nameserver della TLD)
dig +short DS example.com @a.gtld-servers.net

# Strumento per una validazione più approfondita: delv (o drill)
delv example.com @8.8.8.8

Importante: Verifichi da più resolver pubblici e dalla sua rete; effetti di cache possono portare a risultati diversi.

Errori frequenti e come risolverli

Nell’operatività quotidiana si presentano ricorrenti alcuni errori. Qui i più rilevanti con cause e rimedi.

1) SERVFAIL per parti della zona dopo l’attivazione

Causa: Catena interrotta (DS mancante o errato presso il parent), firme scadute o il server autorevole fornisce dati DNSKEY/DNSSEC incoerenti.

Sequenza di controllo:

1. dig +dnssec example.com SOA e controllare se sono presenti RRSIG.
2. dig +short DS example.com @parent-server verificare se il DS è presente e corretto.
3. Usare delv per visualizzare l’errore di validazione.

Risoluzione: Assicurarsi che il DS corrisponda all’hash KSK-DNSKEY; rinnovare le firme localmente e, se necessario, aggiornare il DS corretto presso il registrar.

2) Risposte inconsistenti tra server autorevoli

Causa: File di zona differenti (non sincronizzati), stati delle chiavi diversi; ad esempio un server restituisce la nuova versione DNSKEY, un altro ancora la vecchia.

Risoluzione: Controllare i log dei trasferimenti di zona (AXFR/IXFR), sincronizzare i file di zona, validare i numeri di serial e invocare rndc reload o un riavvio in modo coordinato. Nei cluster DNS verificare i meccanismi di replica.

3) Problemi di caching e TTL dopo un rollover

Causa: Vecchi valori DNSKEY/digest nella cache impediscono la validazione immediata dopo il cambio. I TTL e il negative-caching degli errori di validazione (NSEC/NSEC3) possono influire sui tempi.

Risoluzione: Considerare i TTL prima e dopo i rollout; pianificare il rollover con tempi di sovrapposizione sufficienti. In emergenza si possono ridurre i TTL in anticipo, ma ciò è praticabile solo a breve termine.

4) Il registrar non supporta l’aggiornamento automatico del DS

Causa: Molti registrar non implementano l’adozione di CDS/CDNSKEY.

Risoluzione: Automatizzare l’upload del DS tramite l’API del registrar o l’inserimento manuale con passaggi di approvazione documentati. Testare questo workflow in un dominio di prova prima di passare alla produzione.

Checklist operativa prima del rollout in produzione

• Firmare una zona di test con la stessa configurazione e validarla in staging.
• Backup di tutte le chiavi private, copia offline sicura della KSK.
• Verificare se il registrar consente aggiornamenti DS e se sono disponibili API.
• Impostare il monitoraggio: avvisi di scadenza RRSIG, validazioni fallite e discrepanze tra NS.
• Piano di rollback documentato: passaggi per rimuovere il DS presso il parent e disattivare la firma, nel caso in cui i validatori dovessero fallire in massa.

Strategia di rollback e misure di emergenza

Se la messa in produzione causa problemi, esiste una strategia di ritorno pragmatica:

1. Rollback 1: Rimuovere la voce DS presso il parent (se è necessario consentire temporaneamente il funzionamento senza validazione). Nota: questo permette nuovamente risposte DNS non sicure, ma funzionanti.
2. Rollback 2: Se ciò non è possibile, ripristinate il precedente file di zona firmato e la configurazione DNSKEY e pubblicateli; non aumentate eventualmente i TTL, ma lasciate scadere le cache.
3. Comunicazione: Informate immediatamente i team interessati, le pipeline CI/CD e il supporto del registrar esterno.

Monitoraggio e manutenzione in esercizio

Attività ricorrenti:

• Monitorare le date di scadenza delle RRSIG; inviare avvisi quando le firme scadono entro una finestra predefinita (es. 7 giorni).
• Rispettare e documentare regolarmente la pianificazione del key rollover.
• Eseguire automaticamente firme di test e controlli di validazione da più reti (es. tramite job CI o controlli di monitoraggio).

Conclusione: implementare DNSSEC come iniziativa operativa, non come attività una tantum

DNSSEC aumenta la sicurezza della risoluzione dei nomi, ma introduce complessità operative: gestione delle chiavi, pubblicazione del DS presso il parent, processi di rollover e monitoraggio sono attività operative centrali. Implementazioni riuscite seguono processi chiari, controlli automatizzati e percorsi di rollback testati. Pianificate risorse per il key management (HSM o KMS), testate i workflow del registrar e automatizzate il monitoraggio delle firme. Se tenete conto di questi punti, ridurrete il rischio di interruzioni e farete di DNSSEC una componente stabile del rafforzamento della vostra infrastruttura.

Comandi di verifica avanzati ed esempi

Selezione di comandi utili per un controllo rapido:

# Anzeigen aller DNSKEYs der Zone
dig +dnssec example.com DNSKEY

# RRSIG-Details anzeigen
dig +dnssec example.com RRSIG

# Prüfen ob Resolver die Antwort validiert (ad flag)
dig +short +dnssec @8.8.8.8 example.com A | grep -i ad || echo "Not validated"

# Exportieren des DS-Werts aus einer KSK-Datei
dnssec-dsfromkey Kexample.com.+008+12345.key

Lista di controllo per la prima implementazione (versione breve)

• Staging: firmare e validare nell’ambiente di test.
• Key-Policy: KSK offline/HSM, ZSK con rotazione automatizzata.
• Registrar: verificare API o supporto, testare il workflow DS.
• Monitoring: impostare RRSIG-Expiry, DS-Drift, errori di validazione.
• Piano di rollback: rimuovere il DS, ripristinare la vecchia zona, playbook di comunicazione.

Fonti e strumenti (raccomandazioni)

Strumenti comuni: BIND (dnssec-keygen, dnssec-signzone), Knot, PowerDNS, delv/drill per la validazione, OpenDNSSEC per integrazione HSM e automazione delle chiavi. Scegliete lo strumento che si adatta alla vostra struttura operativa e testate approfonditamente i punti di integrazione (Registrar-API, replicazione delle zone).

Riepilogo: Implementare DNSSEC è gestibile se definite in anticipo la gestione delle chiavi, i test, i workflow del registrar e il monitoraggio in modo chiaro. Stabilite processi chiari per KSK/ZSK, rollover e recovery e automatizzate le verifiche ricorrenti. In questo modo ridurrete i rischi operativi e garantirete una catena di fiducia robusta per le vostre zone DNS.

Per questo argomento sono importanti anche la firma DNS e KSK e ZSK. L’articolo contestualizza questi aspetti in modo comprensibile e mostra su cosa è importante concentrarsi nella pratica quotidiana.