Catena di fiducia DNSSEC: capire in 5 minuti (2026)

Q: Come verificare che DNSSEC funzioni sul mio dominio?

Esegui dig captaindns.com +dnssec | grep flags . Se il flag ad (Authenticated Data) è presente, la catena di fiducia è validata. Puoi anche usare uno strumento online che verifica il DS record, le DNSKEY e le firme RRSIG.

TL;DR

La catena di fiducia DNSSEC collega la root DNS al tuo dominio tramite firme crittografiche concatenate
Tre tipi di record assicurano la validazione: DNSKEY (chiavi pubbliche), RRSIG (firme) e DS (collegamento alla zona padre)
Ogni anello verifica il successivo: la root firma il TLD, il TLD firma il tuo dominio
Dall'11 ottobre 2026 la KSK 38696 firma la root DNS: un resolver autogestito che non l'ha tra le sue àncore può restituire SERVFAIL
Verifica che la tua catena sia intatta con il nostro DNSSEC Checker (vedi piano d'azione in fondo)

DNSSEC non funziona come un certificato TLS che installi su un server. È un sistema distribuito. La fiducia si propaga dalla root DNS fino al tuo dominio, anello dopo anello. Se un singolo anello si spezza, l'intera catena crolla e i tuoi visitatori ricevono un errore SERVFAIL.

Capire questa catena è essenziale per attivare DNSSEC correttamente, diagnosticare gli errori ed evitare interruzioni di servizio. Questa guida ti spiega ogni componente in 5 minuti, con schemi ed esempi concreti.

Perché il DNS ha bisogno di una catena di fiducia?

Il DNS è stato progettato nel 1983 (RFC 1034) come un elenco distribuito. Nessun meccanismo permetteva di verificare che una risposta provenisse dal server legittimo. Un attaccante poteva iniettare una risposta falsa (DNS spoofing) e reindirizzare il traffico verso un server malevolo.

DNSSEC (RFC 4033) risolve questo problema aggiungendo firme crittografiche. Ma una firma da sola non basta: serve un modo per verificare che la chiave di firma sia legittima. Questo è il ruolo della catena di fiducia.

Il principio è semplice: ogni livello della gerarchia DNS garantisce l'autenticità del livello successivo.

I tre livelli della gerarchia DNS

La risoluzione DNS segue una struttura ad albero su tre livelli. DNSSEC sfrutta questa gerarchia per costruire la catena di fiducia.

Livello 1: la root DNS

La root DNS è il punto di partenza di ogni risoluzione. È gestita dall'IANA (Internet Assigned Numbers Authority) e distribuita su 13 cluster di server root. La root firma i record DS di ogni TLD.

L'àncora di fiducia (trust anchor) della root si basa sulla sua KSK. Il resolver validante la conserva nella propria configurazione e deve mantenerla aggiornata quando cambiano le chiavi. È il punto di partenza della catena, non una chiave integrata una volta per tutte.

Livello 2: il TLD (.com, .fr, .org)

Il TLD riceve la sua legittimità dalla root tramite un DS record. Il registro del TLD (Verisign per .com, AFNIC per .fr) gestisce la firma della sua zona. Il TLD firma a sua volta i DS record di ogni dominio registrato.

Livello 3: il tuo dominio (captaindns.com)

Il tuo dominio è l'ultimo anello. Il tuo provider DNS firma i record della tua zona (A, MX, TXT, ecc.) e pubblica le chiavi pubbliche. Il DS record pubblicato al TLD collega la tua zona alla zona padre.

Catena di fiducia DNSSEC: dalla root DNS al dominio, ogni livello firma il successivo

Le chiavi crittografiche: ZSK e KSK

Ogni zona DNSSEC utilizza due coppie di chiavi. La loro separazione permette una rotazione indipendente e limita l'impatto di una compromissione.

ZSK (Zone Signing Key)

La ZSK firma i record DNS della tua zona. Ogni tipo di record (A, MX, TXT, AAAA) riceve la propria firma RRSIG.

Dimensione tipica: 1024-2048 bit (RSA) o 256 bit (ECDSA P-256)
Rotazione: ogni 1-3 mesi
Pubblicata in: il record DNSKEY della tua zona (flag 256)

La rotazione frequente della ZSK limita i rischi. Se la chiave viene compromessa, l'esposizione è limitata nel tempo. La rotazione della ZSK non richiede un aggiornamento del DS record al TLD.

KSK (Key Signing Key)

La KSK del tuo dominio firma unicamente il set di DNSKEY (inclusa la ZSK). Il suo hash è pubblicato nel DS record a livello del TLD. È il ponte tra la tua zona e la zona padre.

Dimensione tipica: 2048-4096 bit (RSA) o 384 bit (ECDSA P-384)
Rotazione: ogni 1-2 anni
Pubblicata in: il record DNSKEY della tua zona (flag 257)

La rotazione della KSK del tuo dominio è più delicata: richiede l'aggiornamento del DS record al registrar. Un coordinamento sbagliato spezza la catena di fiducia.

I record DNSSEC spiegati

Quattro tipi di record DNS assicurano il funzionamento della catena.

DNSKEY: le chiavi pubbliche

Il record DNSKEY contiene la chiave pubblica utilizzata per verificare le firme. La tua zona pubblica almeno due DNSKEY: una per la ZSK (flag 256) e una per la KSK (flag 257).

dig DNSKEY captaindns.com +short

Il resolver usa queste chiavi per verificare le firme RRSIG dei record della tua zona.

RRSIG: le firme

Ogni record DNS firmato possiede un RRSIG corrispondente. L'RRSIG contiene la firma crittografica, l'algoritmo utilizzato, il periodo di validità e il Key Tag della chiave che ha firmato.

dig A captaindns.com +dnssec

Il resolver verifica che la firma RRSIG corrisponda al record restituito e che la chiave (DNSKEY) sia valida.

DS: il collegamento con la zona padre

Il DS record (Delegation Signer) è pubblicato nella zona padre (il TLD). Contiene un hash della KSK della tua zona. Il resolver confronta questo hash con la KSK pubblicata nel tuo DNSKEY per confermare la legittimità delle tue chiavi.

dig DS captaindns.com +short

Il DS record è l'anello critico tra due livelli della gerarchia. Senza DS record, la catena è interrotta e DNSSEC appare come INSECURE.

NSEC/NSEC3: la prova di inesistenza

NSEC e NSEC3 dimostrano che un record richiesto non esiste, in modo autenticato. Senza questi record, un attaccante potrebbe forgiare risposte "dominio inesistente" (NXDOMAIN) per deviare il traffico.

NSEC3 (RFC 5155) aggiunge un hashing dei nomi per evitare l'enumerazione di zona (zone walking).

Come fa il resolver a validare una risposta?

Ecco il processo completo di validazione quando un resolver riceve una query per captaindns.com.

Passaggio 1: recuperare l'àncora di fiducia

Il resolver parte da un'àncora di fiducia della root configurata localmente. Questa fiducia iniziale non proviene da una zona padre; l'àncora deve poi essere mantenuta aggiornata, in particolare tramite RFC 5011 quando questo meccanismo è supportato e funziona.

Aggiornamento del 12 ottobre 2026: il rollover della KSK root è avvenuto l'11 ottobre. La sezione sul rollover della root, più in basso, spiega cosa cambia per un resolver autogestito.

Passaggio 2: validare la root verso il TLD

Il resolver richiede il DS record di .com alla root
La root restituisce il DS record e la sua firma RRSIG
Il resolver valida il set DNSKEY della root con la KSK root, poi la firma del DS con la ZSK così autenticata
Il DS record di .com è ora validato

Passaggio 3: validare il TLD verso il tuo dominio

Il resolver richiede il DS record di captaindns.com al TLD .com
Il TLD restituisce il DS record e la sua firma RRSIG
Il resolver verifica la firma con la DNSKEY del TLD (validata al passaggio 2)
Il DS record di captaindns.com è ora validato

Passaggio 4: validare la tua zona

Il resolver richiede il DNSKEY di captaindns.com
Confronta l'hash della KSK con il DS record validato al passaggio 3
Se l'hash corrisponde, le DNSKEY sono legittime
Il resolver richiede il record A e verifica il suo RRSIG con la ZSK

Se tutti i passaggi hanno successo, la risposta è contrassegnata come SECURE (flag ad nella risposta DNS). Se un passaggio fallisce, la risposta è BOGUS e il resolver restituisce SERVFAIL.

Processo di validazione DNSSEC passo dopo passo: dalla root al record finale

Rollover della KSK root: situazione al 12 ottobre 2026

Dall'11 ottobre 2026, KSK-2024 (key tag 38696) firma il set DNSKEY della zona root al posto di KSK-2017 (20326): è l'unica KSK a firmarlo. Al controllo del 12 ottobre 2026, su k.root-servers.net e a.root-servers.net il set DNSKEY root risulta firmato da 38696, e l'IANA classifica KSK-2024 con stato Active, «Signing since 2026-10-11». Questo rollover non cambia l'algoritmo. I DS dei TLD restano firmati dalla ZSK.

Pubblicata l'11 gennaio 2025, la nuova chiave avrebbe dovuto essere riconosciuta come àncora tramite RFC 5011 già dal 10 febbraio 2025. Questo calendario non dimostra che l'aggiornamento sia riuscito sul tuo resolver.

La vecchia chiave 20326 resta pubblicata nella zona root. Al 12 ottobre 2026, l'IANA la classifica con stato Post-Publication e indica che resta un'àncora di fiducia valida: non rimuoverla tu stesso dal tuo resolver. Per la sua rimozione, consulta il calendario IANA aggiornato.

La raccomandazione di ICANN è di verificare, senza darlo per scontato, che 38696 sia un'àncora di fiducia utilizzabile localmente. Vedere questa chiave in una risposta DNS non basta.

Un resolver autogestito che non ha 38696 tra le sue àncore non riesce più a validare il set DNSKEY root. I SERVFAIL compaiono su domini correttamente configurati man mano che il set DNSKEY root in cache scade (TTL di 2 giorni). Se una query restituisce SERVFAIL su questo resolver ma ottiene una risposta normale con dig +cd (validazione disattivata solo per questo test), a fallire è la validazione: verifica l'àncora 38696 prima di intervenire sulla zona o sul registrar. Con 1.1.1.1, 8.8.8.8 o 9.9.9.9, non devi fare nulla sulle loro àncore.

Quando si spezza la catena?

Una rottura può dipendere dalla zona o dal resolver che la valida. Ecco quattro scenari.

DS record mancante o errato

Il DS record al TLD non corrisponde alla KSK pubblicata nella tua zona. Cause:

Il DS record non è mai stato aggiunto al registrar (la zona è firmata ma la catena non è stabilita)
La KSK è stata rinnovata senza aggiornare il DS record
Un errore nei valori del DS record (Key Tag, Algorithm, Digest)

Risultato: INSECURE se nessun DS record. BOGUS se il DS record esiste ma non corrisponde.

Firme RRSIG scadute

Ogni firma RRSIG ha una durata di validità. Se le firme non vengono rinnovate prima della scadenza, il resolver le rifiuta.

Risultato: BOGUS su tutti i record la cui firma è scaduta.

Prevenzione: i provider DNS gestiti (Cloudflare, Route 53, OVHcloud) rinnovano automaticamente le firme. Il rischio esiste soprattutto con BIND o PowerDNS autogestiti.

Algoritmi incompatibili

Se il DS record specifica un algoritmo diverso da quello usato dalla DNSKEY, la validazione fallisce.

Risultato: BOGUS.

Àncora root non aggiornata nel resolver

Dal rollover dell'11 ottobre 2026, un resolver autogestito che non considera affidabile 38696 può restituire SERVFAIL per numerosi domini altrimenti correttamente configurati. Il problema è nell'àncora root di quel resolver, non nel DS del tuo dominio. Verifica questa àncora prima di modificare la zona o la configurazione al registrar.

Verificare la tua catena di fiducia

Per confermare che la tua catena è intatta, usa il seguente comando:

dig captaindns.com +dnssec +short

Il flag ad (Authenticated Data) nella risposta conferma che la catena completa è validata:

dig captaindns.com +dnssec | grep flags
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2

Per un'analisi completa di ogni anello, usa il nostro strumento DNS Lookup che dettaglia i record DNSKEY, DS e RRSIG.

Piano d'azione consigliato

Capire la tua configurazione: identifica chi gestisce la firma di zona (provider DNS) e chi gestisce il DS record (registrar)
Verificare la catena: conferma che il DS record al TLD corrisponde alla tua KSK con dig DS captaindns.com +short
Monitorare le scadenze: sorveglia la validità delle firme RRSIG e pianifica le rotazioni delle chiavi
Documentare la procedura: annota i passaggi di rotazione KSK per il tuo registrar specifico
Testare dopo ogni modifica: verifica la propagazione DNS dopo qualsiasi modifica DNSSEC
Resolver autogestito: verifica che 38696 sia effettivamente un'àncora di fiducia del tuo resolver; se una query restituisce SERVFAIL su questo resolver ma una risposta normale con dig +cd, a fallire è la validazione; se usi solo 1.1.1.1, 8.8.8.8 o 9.9.9.9, non devi intervenire sulle loro àncore

Avvia una diagnosi DNSSEC completa del tuo dominio per verificare i suoi DS, DNSKEY e RRSIG. Il DNSSEC Checker non verifica l'àncora locale del tuo resolver.

Guide DNSSEC correlate

FAQ

Cos'è la catena di fiducia DNSSEC?

La catena di fiducia DNSSEC è il meccanismo con cui ogni livello della gerarchia DNS (root, TLD, dominio) garantisce l'autenticità del livello successivo tramite firme crittografiche. Il resolver risale questa catena dall'àncora di fiducia (KSK root) fino al tuo dominio.

Cos'è un trust anchor?

Un trust anchor (àncora di fiducia) è una chiave o un riferimento a una chiave che il resolver considera affidabile per avviare la validazione. Per la root DNS, si basa sulla KSK root e deve essere mantenuta aggiornata, in particolare durante un rollover. RFC 5011 prevede questo aggiornamento automatico, di cui occorre verificare il corretto funzionamento.

Il mio resolver autogestito è interessato dal rollover della KSK root?

Sì, se valida DNSSEC. Dall'11 ottobre 2026 la KSK 38696 firma il set DNSKEY root: un resolver autogestito che non l'ha tra le sue àncore può restituire SERVFAIL su domini correttamente configurati. Verifica che 38696 sia riconosciuta come àncora di fiducia, senza dare per scontato che RFC 5011 abbia funzionato. Con 1.1.1.1, 8.8.8.8 o 9.9.9.9, non devi intervenire sulle loro àncore.

Qual è la differenza tra ZSK e KSK?

La ZSK (Zone Signing Key) firma i record DNS della tua zona (A, MX, TXT). La KSK (Key Signing Key) firma unicamente le DNSKEY. La loro separazione permette di rinnovare la ZSK frequentemente senza toccare il DS record del registrar.

Cosa succede se la catena di fiducia si spezza?

Se un anello della catena è invalido (DS errato, firma scaduta, chiave incompatibile), il resolver contrassegna la risposta come BOGUS e restituisce SERVFAIL al client. I tuoi visitatori non possono più accedere al tuo sito finché il problema non viene corretto.

Come funziona DNSSEC?

DNSSEC aggiunge firme crittografiche a ogni record DNS. Il tuo provider DNS firma i record con una chiave privata (ZSK). Il resolver verifica le firme con la chiave pubblica (DNSKEY). La legittimità delle chiavi è garantita da un DS record pubblicato al TLD, formando una catena di fiducia fino alla root.

Come verificare che DNSSEC funzioni sul mio dominio?

Esegui dig captaindns.com +dnssec | grep flags. Se il flag ad (Authenticated Data) è presente, la catena di fiducia è validata. Puoi anche usare uno strumento online che verifica il DS record, le DNSKEY e le firme RRSIG.

Perché la rotazione della KSK è rischiosa?

La rotazione della KSK del tuo dominio richiede l'aggiornamento del DS record al registrar. Durante la transizione, i due DS record (vecchio e nuovo) devono coesistere. Un coordinamento sbagliato (vecchio DS rimosso prima della propagazione del nuovo) spezza la catena e provoca SERVFAIL.

DNSSEC funziona con tutti i resolver?

No. Solo i resolver validanti verificano le firme DNSSEC. I principali resolver pubblici (Cloudflare 1.1.1.1, Google 8.8.8.8, Quad9 9.9.9.9) validano DNSSEC. Alcuni resolver degli operatori non lo fanno. Secondo l'APNIC, circa il 38% delle query DNS mondiali sono validate DNSSEC nel 2026.

Glossario

Trust anchor (àncora di fiducia): chiave o riferimento a una chiave riconosciuta come affidabile per avviare la validazione DNSSEC; l'àncora root deve essere mantenuta aggiornata quando cambia la KSK.
DS record (Delegation Signer): record pubblicato nella zona padre contenente un hash della KSK. Collegamento tra due livelli della gerarchia.
DNSKEY: record contenente la chiave pubblica di firma. Flag 256 per la ZSK, flag 257 per la KSK.
RRSIG: firma crittografica di un record DNS. Contiene l'algoritmo, il periodo di validità e il Key Tag.
NSEC/NSEC3: record di prova di inesistenza autenticata. NSEC3 aggiunge un hashing per evitare l'enumerazione di zona.
BOGUS: stato di una risposta DNS la cui validazione DNSSEC è fallita. Il resolver restituisce SERVFAIL.