Vai al contenuto principale

Capire la catena di fiducia DNSSEC in 5 minuti

Di CaptainDNS
Pubblicato il 22 febbraio 2026

Catena di fiducia DNSSEC: dalla root DNS al dominio, ogni livello verifica il successivo con chiavi crittografiche
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
  • 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 è la KSK root. È integrata in tutti i resolver validanti (1.1.1.1, 8.8.8.8, 9.9.9.9). È il fondamento dell'intera catena.

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 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 è 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 possiede già la KSK della root DNS (trust anchor). Questa chiave è integrata nella sua configurazione. È l'unico elemento che il resolver accetta senza verifica.

Passaggio 2: validare la root verso il TLD

  1. Il resolver richiede il DS record di .com alla root
  2. La root restituisce il DS record e la sua firma RRSIG
  3. Il resolver verifica la firma con la KSK root
  4. Il DS record di .com è ora validato

Passaggio 3: validare il TLD verso il tuo dominio

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

Passaggio 4: validare la tua zona

  1. Il resolver richiede il DNSKEY di captaindns.com
  2. Confronta l'hash della KSK con il DS record validato al passaggio 3
  3. Se l'hash corrisponde, le DNSKEY sono legittime
  4. 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

Quando si spezza la catena?

Tre scenari provocano la rottura della catena di fiducia.

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.

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

  1. Capire la tua configurazione: identifica chi gestisce la firma di zona (provider DNS) e chi gestisce il DS record (registrar)
  2. Verificare la catena: conferma che il DS record al TLD corrisponde alla tua KSK con dig DS captaindns.com +short
  3. Monitorare le scadenze: sorveglia la validità delle firme RRSIG e pianifica le rotazioni delle chiavi
  4. Documentare la procedura: annota i passaggi di rotazione KSK per il tuo registrar specifico
  5. Testare dopo ogni modifica: verifica la propagazione DNS dopo qualsiasi modifica DNSSEC

Avvia una diagnosi DNSSEC completa del tuo dominio per verificare che ogni anello sia al suo posto.

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 pubblica che il resolver considera affidabile senza verifica aggiuntiva. In DNSSEC, il trust anchor è la KSK della root DNS. È integrata nella configurazione di tutti i resolver validanti.

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 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 pubblica considerata affidabile dal resolver senza verifica. In DNSSEC, la KSK della root DNS.
  • 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.

Fonti

Articoli simili