DNSSEC Checker

Perché verificare DNSSEC?

DNSSEC (DNS Security Extensions) aggiunge una verifica crittografica alle risposte DNS. Senza questa protezione, un attaccante può falsificare le risposte e dirottare il tuo traffico verso i propri server. È il principio del cache poisoning.

Il pericolo è silenzioso. Un DS orfano o un key rollover incompleto fa scomparire un dominio. Nessun monitor HTTP, nessun ping, nessun uptime check rileverà questo problema. Questi guasti silenziosi persistono per giorni. I resolver validanti (Google, Cloudflare, Quad9) restituiscono SERVFAIL invece della risposta attesa.

Quattro motivi per verificare il tuo DNSSEC:

• Sicurezza: Conferma che la catena sia intatta. I tuoi visitatori raggiungono i tuoi server, non quelli di un attaccante.
• Disponibilità: Un DNSSEC spezzato blocca i resolver validanti, ovvero circa un terzo fino al 40 % delle query mondiali secondo le misurazioni APNIC. Google, Cloudflare e Quad9 rifiutano la risposta.
• Conformità: Banche, pubblica amministrazione, sanità ed e-commerce richiedono DNSSEC sui domini critici.
• Rilevamento proattivo: Individua DS orfani, algoritmi deboli e firme scadute prima dell'interruzione.

Come utilizzare il DNSSEC Checker in 3 passaggi

Passaggio 1: Inserisci il tuo dominio

Inserisci il nome di dominio da verificare, ad esempio cloudflare.com o nic.fr. Lo strumento accetta qualsiasi dominio, firmato DNSSEC o meno. Se DNSSEC non è attivo, lo saprai immediatamente.

Passaggio 2: Scegli la modalità di analisi

• Modalità Semplice (predefinita): Verifica la chain of trust completa interrogando un server autoritativo per zona. Risultato in 1-3 secondi.
• Modalità Completa: Tutto ciò che include la Semplice, più la coerenza DNSKEY multi-server e la validazione RRSIG sui dati (SOA, NS, A, MX). Risultato in 5-10 secondi.

Usa la modalità Completa dopo un key rollover, una migrazione DNS o per un audit di sicurezza. Nel dubbio, inizia con la modalità Semplice.

Passaggio 3: Analizza il report e correggi

Il report classifica ogni risultato per gravità, zona per zona:

• Errori: Catena spezzata, firme non valide, incoerenza tra server. Bloccano la risoluzione.
• Avvertimenti: DS orfani, algoritmi deboli, RRSIG in scadenza. Richiedono attenzione.
• Informazioni: CSK rilevata, NS fuori bailiwick, numero di DS nel parent. Utili a titolo informativo, nessuna azione necessaria.

Cos'è la chain of trust DNSSEC?

La chain of trust DNSSEC funziona come una staffetta di verifiche crittografiche a cascata. Ogni zona garantisce per la successiva. Parte dalla root DNS e arriva fino al tuo dominio:

Root (.)
  |-- DS del TLD --> verifica la DNSKEY del TLD (KSK)
  |-- La ZSK del TLD firma il DS del tuo dominio
        |-- DS del tuo dominio --> verifica la tua DNSKEY (KSK)
        |-- La tua KSK firma il DNSKEY RRSet
        |-- La tua ZSK firma i dati (A, MX, SOA, NS)

I record chiave:

Ogni anello dipende dal precedente. Un solo anello spezzato e l'intera catena crolla. I resolver validanti restituiscono allora SERVFAIL.

NSEC e NSEC3: la prova autenticata di inesistenza

DNSSEC non firma soltanto i record esistenti. Dimostra anche, in modo autenticato, che un nome o un tipo di record non esiste. Senza questa prova, un attaccante potrebbe negare l'esistenza di un record che invece è firmato. Due meccanismi garantiscono questa prova di inesistenza:

• NSEC (Next Secure) concatena i nomi della zona in ordine alfabetico. Ogni record NSEC indica il nome esistente successivo. Lo svantaggio: seguendo questa catena passo dopo passo, chiunque può enumerare tutti i nomi della zona. È lo zone walking.
• NSEC3 (RFC 5155) corregge il problema pubblicando degli hash dei nomi anziché i nomi in chiaro. Lo zone walking diventa molto più costoso, perché bisogna forzare gli hash. NSEC3 aggiunge un sale (salt) e un numero di iterazioni.

L'opt-out NSEC3 è un'opzione pensata per le zone molto grandi (TLD, zone con numerose deleghe non firmate). Evita di generare una prova NSEC3 per le deleghe non sicure, il che riduce la dimensione della zona e il costo della firma. Per contro, l'opt-out non autentica l'assenza di queste deleghe.

Per la maggior parte dei domini, NSEC o NSEC3 vanno bene. NSEC3 è preferibile se l'enumerazione della tua zona è una preoccupazione.

Cosa verifica esattamente lo strumento?

Modalità Semplice

Modalità Completa (in aggiunta)

Diagnosi comuni e soluzioni

DS orfano (DNSSEC_DS_ORPHAN)

Sintomo: Un record DS nel parent non ha nessuna DNSKEY corrispondente nella tua zona.

Causa probabile: Key rollover incompleto. La vecchia chiave è stata eliminata dalla zona prima dell'aggiornamento del DS presso il registrar.

Azione: Elimina il DS orfano tramite il registrar. Oppure riaggiungi la DNSKEY corrispondente. Rilancia il checker per confermare.

Algoritmo debole (DNSSEC_WEAK_ALGO)

Sintomo: La tua zona utilizza un algoritmo di firma considerato non sicuro dalla RFC 8624.

Algoritmi interessati: RSAMD5 (1), DSA (3) e DSA-NSEC3-SHA1 (6) sono vietati per la firma. RSASHA1 (5) e RSASHA1-NSEC3-SHA1 (7) sono sconsigliati.

Azione: Migra verso un algoritmo raccomandato: RSASHA256 (8), ECDSAP256SHA256 (13), ECDSAP384SHA384 (14) o Ed25519 (15). Rilancia il test per confermare.

Digest SHA-1 (DNSSEC_WEAK_DIGEST)

Sintomo: Il tuo DS utilizza SHA-1 (tipo 1) come tipo di digest.

Azione: Aggiungi un DS SHA-256 (tipo 2), oppure SHA-384 (tipo 4) se il tuo registrar lo supporta, in parallelo. Attendi 48 ore di propagazione, poi elimina il DS SHA-1. Rilancia il test per confermare.

SERVFAIL dopo l'attivazione di DNSSEC

Sintomo: Il tuo dominio restituisce SERVFAIL per i resolver validanti dopo l'attivazione di DNSSEC.

Cause frequenti:

• DS nel registrar non corrisponde alla DNSKEY della tua zona
• Firme RRSIG non generate o scadute
• Server autoritativi che non servono i record DNSKEY

Azione: Avvia il test in modalità Completa per individuare l'anello spezzato. Verifica prima che il DS corrisponda alla KSK: stesso key tag, stesso algoritmo.

Incoerenza DNSKEY tra server (DNSSEC_SERVER_INCONSISTENT)

Sintomo: I server autoritativi della tua zona non servono le stesse chiavi DNSKEY. Rilevato solo in modalità Completa.

Causa probabile: Propagazione incompleta tra server primario e secondari, oppure configurazione diversa su un server.

Azione: Verifica la replica tra i tuoi server DNS. Forza un trasferimento di zona (AXFR/IXFR) se necessario. Rilancia il test dopo qualche minuto per confermare.

Verificare DNSSEC da riga di comando (delv e dig)

Per gli amministratori di sistema, due strumenti permettono di verificare DNSSEC manualmente. delv (incluso con BIND 9.10 e versioni più recenti) effettua una validazione completa della chain of trust e mostra un verdetto finale. dig interroga i record grezzi (DS, DNSKEY, RRSIG) ma non valida la catena da solo.

Nota: le vecchie opzioni dig +sigchase e +trusted-key sono state rimosse dalle versioni moderne di BIND. Usa delv al loro posto per la validazione.

# Validare la chain of trust completa (verdetto finale)
delv captaindns.com A

# Tracciare ogni passaggio della validazione
delv @1.1.1.1 captaindns.com A +rtrace

# Validare e mostrare le DNSKEY della zona
delv captaindns.com DNSKEY

# Vedere i record DS pubblicati presso il parent
dig DS captaindns.com +short

# Vedere le DNSKEY e le loro firme RRSIG (senza validazione)
dig DNSKEY captaindns.com +dnssec

# Vedere le RRSIG su un record A
dig A captaindns.com +dnssec

Una risposta delv validata mostra ; fully validated; un fallimento della validazione mostra ; resolution failed. Questi comandi richiedono accesso al terminale e competenze DNS. Il DNSSEC Checker qui sopra automatizza l'intero processo e presenta i risultati visivamente, senza riga di comando.

DNSSEC per provider DNS

L'attivazione di DNSSEC richiede la collaborazione tra provider DNS e registrar. Ecco come si posizionano i principali provider:

Dopo l'attivazione, verifica sempre la chain of trust con lo strumento qui sopra. L'errore n. 1: un DS nel registrar che non corrisponde alla DNSKEY generata dal provider.

Best practice DNSSEC

Algoritmo di firma: Preferisci un algoritmo a curva ellittica, ECDSAP256SHA256 (13) o Ed25519 (15). RSASHA256 (8) ed ECDSAP384SHA384 (14) restano ampiamente diffusi e accettati. ECDSA produce firme circa 3,5-4 volte più compatte di RSA-2048, il che riduce la dimensione delle risposte.

Digest DS: Pubblica un DS con SHA-256 (tipo 2); SHA-384 (tipo 4) è anch'esso accettato. SHA-1 (tipo 1) è deprecato: non pubblicare più un DS SHA-1 da solo.

Key rollover: Segui le pratiche delle RFC 6781 e 7583 (vedi la sezione dedicata più sotto). Non eliminare mai il vecchio DS prima della propagazione di quello nuovo.

Monitoring: Verifica la catena dopo ogni modifica DNS. Una zona non rifirmata in tempo provoca dei SERVFAIL.

Migrazione di provider: Conferma che il nuovo provider supporti lo stesso algoritmo. I due set di chiavi devono coesistere durante la propagazione.

Rotazione delle chiavi di firma (rollover)

Una chiave DNSSEC non è eterna. Va sostituita periodicamente (rollover) senza spezzare la chain of trust. Le RFC 6781 (pratiche operative) e 7583 (tempistiche) descrivono queste procedure. La modalità operativa varia secondo il tipo di chiave.

Rollover della KSK (Key Signing Key). La KSK è referenziata dal DS presso il parent. Il metodo comune è il double-DS: pubblica il DS della nuova KSK presso il parent, attendi che tutte le cache abbiano recepito entrambi i DS, sposta la firma del DNSKEY RRSet sulla nuova KSK, poi rimuovi il vecchio DS. Il tempo dipende dal TTL del DS presso il parent.

Rollover della ZSK (Zone Signing Key). La ZSK firma i dati e non è legata al parent. Due metodi:

• Pre-publish: pubblica la nuova ZSK nel DNSKEY RRSet prima di usarla, attendi la propagazione, firma i dati con la nuova chiave, poi rimuovi la vecchia. È il metodo raccomandato per la ZSK.
• Doppia firma: firma i dati con la vecchia e la nuova ZSK contemporaneamente. Più facile da comprendere, ma raddoppia il numero di firme e appesantisce le risposte.

Rischi di un rollover fallito. Rimuovere una chiave o un DS prima della scadenza delle cache che vi fanno riferimento spezza la catena: i resolver validanti restituiscono SERVFAIL. Non eliminare mai la vecchia chiave o il vecchio DS prima che tutti i TTL interessati siano scaduti. Verifica l'assenza di DS orfani dopo ogni rollover della KSK.

CDS e CDNSKEY: automatizzare il DS presso il parent

Il punto debole di un rollover della KSK è l'aggiornamento manuale del DS presso il registrar. Un copia-incolla errato spezza la catena. I record CDS e CDNSKEY (RFC 7344 e 8078) automatizzano questo passaggio.

La zona figlia pubblica un CDS (Child DS) o un CDNSKEY (Child DNSKEY) che indica al parent il DS da pubblicare. Il registrar o il registry analizza periodicamente questi record e aggiorna il DS automaticamente, senza intervento manuale. Due usi:

• Bootstrapping (RFC 8078): la prima attivazione di DNSSEC, quando nessun DS esiste ancora presso il parent.
• Manutenzione: l'aggiornamento del DS durante i rollover della KSK successivi.

Non tutti i registry supportano ancora CDS/CDNSKEY, ma l'adozione progredisce. Quando sono supportati, eliminano la principale fonte di errore dei rollover della KSK. Verifica poi la catena con il DNSSEC Checker per confermare che il DS pubblicato corrisponda effettivamente alla tua KSK.

Casi d'uso concreti

Attivazione DNSSEC presso un nuovo registrar

Hai appena attivato DNSSEC? Avvia subito una verifica in modalità Semplice. Conferma che il DS nel parent corrisponda alla DNSKEY della tua zona. Una sola discrepanza significa SERVFAIL per ogni resolver validante.

Key rollover

Dopo un key rollover, cerca DS orfani con la modalità Semplice. Un vecchio DS non eliminato non blocca la risoluzione oggi. Ma segnala manutenzione incompleta e complicherà il prossimo rollover.

Migrazione di provider DNS

Stai migrando a Cloudflare, Route 53 o un altro provider? Avvia il test in modalità Completa. Verifica tre cose: i DS puntano alle nuove DNSKEY, le firme sono valide su tutti i server autoritativi, le chiavi sono coerenti su ogni server.

Audit di sicurezza

La modalità Completa è il tuo report di conformità DNSSEC. Copre la coerenza DNSKEY tra tutti i server autoritativi, la validità delle firme sui dati (SOA, NS, A, MX) e i giorni residui prima della scadenza di ogni RRSIG.

Dominio che restituisce SERVFAIL

Utenti segnalano che il tuo sito è irraggiungibile da alcune reti? Probabilmente reti con resolver validanti. Avvia il test immediatamente. Se la catena è spezzata, lo strumento mostra esattamente dove.

FAQ - Domande frequenti

D: Cos'è DNSSEC e perché attivarlo?

R: DNSSEC (DNS Security Extensions) aggiunge firme crittografiche alle risposte DNS. Senza DNSSEC, un attaccante può falsificare le risposte DNS per reindirizzare il traffico (cache poisoning). Attivare DNSSEC garantisce che i visitatori raggiungano effettivamente i tuoi server e non un intermediario malevolo.

D: Come verificare se DNSSEC è attivo sul mio dominio?

R: Inserisci il tuo dominio nello strumento qui sopra. Se il risultato mostra "DNSSEC non è attivo", significa che nessun record DS è pubblicato presso il registry parent. Contatta il tuo registrar o provider DNS per attivare DNSSEC.

D: Cos'è un DS orfano?

R: Un DS orfano è un record DS pubblicato nella zona parent che non corrisponde a nessuna DNSKEY nella zona figlia. Succede spesso durante un key rollover non completato correttamente. Non è bloccante finché esiste un altro DS valido, ma indica una configurazione incompleta.

D: Perché il mio dominio restituisce SERVFAIL dopo l'attivazione di DNSSEC?

R: SERVFAIL dopo l'attivazione di DNSSEC significa che la chain of trust è spezzata. Cause frequenti: DS pubblicato nel parent non corrispondente alla DNSKEY della tua zona, firme RRSIG scadute o non generate, oppure server autoritativi che non servono i record DNSKEY. Avvia il test in modalità Completa per identificare esattamente l'anello difettoso.

D: Qual è la differenza tra la modalità Semplice e Completa?

R: La modalità Semplice verifica la chain of trust (DS, DNSKEY, RRSIG) interrogando un solo server per zona. La modalità Completa aggiunge la verifica di coerenza DNSKEY tra tutti i server autoritativi e valida le firme RRSIG sui record di dati (SOA, NS, A, MX).

D: Quali algoritmi DNSSEC sono raccomandati?

R: Gli algoritmi comuni e raccomandati sono RSASHA256 (8), ECDSAP256SHA256 (13), ECDSAP384SHA384 (14) ed Ed25519 (15). Secondo la RFC 8624, RSAMD5 (1), DSA (3) e DSA-NSEC3-SHA1 (6) sono vietati; RSASHA1 (5) e RSASHA1-NSEC3-SHA1 (7) sono sconsigliati.

D: NSEC o NSEC3: cos'è lo zone walking?

R: NSEC e NSEC3 dimostrano in modo autenticato che un nome non esiste. NSEC elenca i nomi in chiaro, il che permette di enumerare l'intera zona (zone walking). NSEC3 (RFC 5155) pubblica degli hash al posto dei nomi per impedire questa enumerazione.

D: A cosa servono i record CDS e CDNSKEY?

R: CDS e CDNSKEY (RFC 7344 e 8078) permettono alla zona figlia di segnalare al parent il DS da pubblicare. Il registrar o il registry analizza questi record per creare e poi mantenere automaticamente il DS, senza copia-incolla manuale a ogni rotazione di KSK.

D: DNSSEC rallenta la risoluzione DNS?

R: L'impatto resta limitato, ma le risposte firmate sono più voluminose. Possono superare la dimensione di un pacchetto UDP e provocare una frammentazione o un ripiego su TCP. I resolver mettono in cache i risultati validati, il che ammortizza il costo dopo la prima query.

Strumenti complementari

Risorse utili

• RFC 4033 - DNS Security Introduction: Introduzione e requisiti delle estensioni DNSSEC
• RFC 4034 - Resource Records for DNSSEC: Specifica dei record DS, DNSKEY, RRSIG, NSEC
• RFC 4035 - Protocol Modifications for DNSSEC: Comportamento dei resolver e dei server validanti
• RFC 5155 - DNSSEC Hashed Authenticated Denial of Existence: Specifica di NSEC3
• RFC 6781 - DNSSEC Operational Practices: Best practice operative e rollover
• RFC 7583 - DNSSEC Key Rollover Timing: Calendario di rotazione delle chiavi
• RFC 8624 - Algorithm Implementation Requirements: Requisiti sugli algoritmi DNSSEC
• Verisign DNSSEC Debugger: Strumento di riferimento per il debug DNSSEC
• DNSViz: Visualizzazione avanzata della catena DNSSEC