--- id: "dnssec" kind: "glossary-term" title: "DNSSEC" language: "it" category: "DNS e basi tecniche" updated: "2026-10-10T23:12:43Z" canonical: "https://tldlog.com/it/glossario/dnssec/" translations: en: "https://tldlog.com/glossary/dnssec/" es: "https://tldlog.com/es/glosario/dnssec/" de: "https://tldlog.com/de/glossar/dnssec/" fr: "https://tldlog.com/fr/glossaire/dnssec/" pt-BR: "https://tldlog.com/pt/glossario/dnssec/" ru: "https://tldlog.com/ru/glossariy/dnssec/" zh-Hans: "https://tldlog.com/zh/cihui/dnssec/" --- # DNSSEC estensioni di sicurezza del DNS Estensioni del DNS che aggiungono firme digitali alle risposte DNS. Le firme permettono a un resolver (il server che cerca i nomi per conto degli utenti) di verificare che una risposta sia autentica e non sia stata modificata lungo il percorso. I titolari lo attivano tramite il loro provider DNS e il registrar. Il DNSSEC aggiunge firme digitali alle risposte del Domain Name System, così un computer può verificare che una risposta provenga dal titolare di un dominio e non sia stata modificata lungo il percorso. Non nasconde nulla e non ferma ogni attacco. Per attivarlo devono collaborare il provider DNS, il registrar e il registro. ## Da che cosa protegge il DNSSEC, in parole semplici Quando qualcuno visita example.com, un resolver ne cerca l'indirizzo. Senza DNSSEC, un attaccante che fornisce al resolver una risposta falsificata può mandare i visitatori sul server sbagliato. Con il DNSSEC, un resolver che esegue la convalida controlla la firma e respinge il falso. La RFC 4033 (marzo 2005) definisce ciò che il DNSSEC offre: prova dell'origine e dell'integrità dei dati DNS. Non offre riservatezza, quindi le risposte restano leggibili, né protezione dagli attacchi denial of service. Copre solo le risposte DNS, non il phishing né la presa di controllo di un account presso il registrar. La RFC 9364 (febbraio 2023) definisce il DNSSEC la migliore pratica attuale per autenticare i dati DNS; se usarlo per un dominio è una decisione del titolare. ## Come funziona la catena di fiducia dalla radice al dominio Un resolver che esegue la convalida parte da una chiave di cui si fida già: il trust anchor, cioè la Key Signing Key della zona radice, pubblicata dall'IANA. Da lì segue una catena: 1. La zona radice contiene un record DS firmato per .com. 2. Quel record DS corrisponde a una chiave della zona .com, che permette al resolver di verificare i record di .com, compreso il record DS di example.com. 3. Quel record DS corrisponde alla chiave di example.com, che verifica i record del dominio stesso. Una zona firmata la cui zona madre non contiene alcun record DS è un'«isola di sicurezza»: non può essere convalidata a partire dalla radice. Una risposta è sicura quando ogni firma è valida, non sicura quando una prova firmata mostra che la zona madre non ha record DS per la zona, e bogus quando le firme attese mancano, sono scadute o non sono utilizzabili (RFC 4033). Per una risposta bogus il resolver di norma restituisce un errore, SERVFAIL (RFC 4035). ## Chiavi e record: KSK, ZSK, DNSKEY, DS e RRSIG - I record **DNSKEY** pubblicano le chiavi pubbliche di una zona. - I record **RRSIG** contengono le firme, ciascuna valida solo tra una data di inizio e una data di scadenza. - I record **DS** si trovano nella zona madre e contengono un key tag, un numero di algoritmo e un'impronta (digest) della chiave della zona figlia. - La **KSK** firma solo l'insieme delle chiavi della zona, e il record DS della zona madre punta a essa. La **ZSK** firma tutto il resto. La RFC 6781 (dicembre 2012) osserva che i validatori trattano allo stesso modo i due tipi di chiave: la distinzione è operativa, e alcune zone usano una sola chiave per entrambi i ruoli. Dimostrare che un nome non esiste richiede record appositi. NSEC indica il nome esistente successivo, il che permette a chiunque di elencare l'intera zona («zone walking»). NSEC3 (RFC 5155) applica prima un hash ai nomi, anche se rivela ancora dettagli come le dimensioni della zona. ## Attivare il DNSSEC: che cosa fanno il registrar, il registro e il provider DNS 1. Il provider DNS firma la zona e pubblica i record DNSKEY e RRSIG. 2. I dati DS, oppure i dati della chiave, vengono passati al registrar. 3. Il registrar li invia al registro tramite EPP con l'estensione secDNS (RFC 5910, maggio 2010), come dati DS oppure come dati della chiave da cui il registro ricava il record DS. 4. Il registro pubblica il record DS nella zona del TLD. Quando il registrar è anche il provider DNS, i passaggi da 1 a 3 sono spesso un'unica impostazione. Per i gTLD, il RAA (accordo di accreditamento dei registrar) del 2013 impone ai registrar di trasmettere ai registri che supportano il DNSSEC, tramite la RFC 5910, le richieste di aggiungere, rimuovere o modificare il materiale delle chiavi. Il Registry Agreement base (approvato il 21 gennaio 2024, in vigore a ottobre 2026) impone ai registri gTLD di firmare le proprie zone e di accettare il materiale delle chiavi dei domini figli. Le regole dei ccTLD sono diverse: conviene informarsi presso il registrar o il registro. Esiste anche una via automatica: il provider DNS pubblica record CDS e CDNSKEY che indicano quale deve essere il record DS, e alcuni registri e registrar li rilevano. La RFC 8078 (marzo 2017) ha aggiunto un segnale per disattivare il DNSSEC; la RFC 9615 (luglio 2024) permette alla zona madre di verificare questi record con metodi crittografici prima di attivare il DNSSEC. ## Che cosa può andare storto: firme scadute, sostituzione delle chiavi e cambio di provider DNS - **Firme scadute.** Record RRSIG non rinnovati in tempo rendono bogus le risposte. - **Un record DS senza chiave corrispondente.** La RFC 6781 lo chiama «security lameness»: il dominio smette di funzionare per tutti i resolver che eseguono la convalida, e la correzione impiega tempo a diffondersi. Per questo il cambio di una KSK richiede che il nuovo record DS sia presente nella zona madre prima che la vecchia chiave venga rimossa. - **Cambio di provider DNS.** Il vecchio operatore controlla le chiavi. Il metodo migliore è una sostituzione delle chiavi coordinata. Se il vecchio operatore non collabora, si rimuove il record DS, si cambiano i name server e, una volta diffusa la modifica, si aggiunge il nuovo record DS. Nel frattempo il dominio non è firmato, situazione che la RFC 8078 preferisce agli errori di convalida. TTL brevi aiutano. Gli errori si manifestano come SERVFAIL per chi usa resolver che eseguono la convalida, mentre il dominio può continuare a funzionare per tutti gli altri. Alla radice, al 9 ottobre 2026, l'ICANN prevede di sostituire la KSK della radice l'11 ottobre 2026: la KSK-2024 (key tag 38696) subentra alla KSK-2017 (key tag 20326), che sarà revocata l'11 gennaio 2027 e rimossa il 22 marzo 2027. La cosa riguarda gli operatori dei resolver che eseguono la convalida, che devono adottare il nuovo trust anchor, non gli assegnatari. ## DNSSEC e DNS cifrato: le differenze Il DNSSEC firma i dati perché qualsiasi resolver possa verificarli, ma tutto resta leggibile. DNS over TLS (DoT) e DNS over HTTPS (DoH) cifrano il collegamento tra il dispositivo dell'utente e il resolver, il che protegge la riservatezza, ma non dimostrano che i dati provengano dal titolare della zona. Le due tecnologie si completano a vicenda. ## Fonti - [RFC 4033: DNS Security Introduction and Requirements](https://www.rfc-editor.org/rfc/rfc4033.txt) - [RFC 6781: DNSSEC Operational Practices, Version 2](https://www.rfc-editor.org/rfc/rfc6781.txt) - [RFC 5910: Domain Name System (DNS) Security Extensions Mapping for the Extensible Provisioning Protocol (EPP)](https://www.rfc-editor.org/rfc/rfc5910.txt) - [DNSSEC Trust Anchors and Rollovers](https://www.iana.org/dnssec/files) - [ICANN Announces Next Major Internet Security Update](https://www.icann.org/resources/press-material/release-2026-05-20-en) ## termini correlati - [record DS](https://tldlog.com/it/glossario/record-ds/) - [record DNSKEY](https://tldlog.com/it/glossario/record-dnskey/) - [resolver](https://tldlog.com/it/glossario/resolver/) - [DNS](https://tldlog.com/it/glossario/dns/)