DNSSEC: come funziona e perché serve davvero

Il DNS è nato nel 1983 senza alcun meccanismo di autenticazione: quando il tuo resolver chiede l'indirizzo IP di un dominio, accetta la prima risposta che arriva con il transaction ID corretto. Chi riesce a indovinare o intercettare quel pacchetto può dirottare il traffico verso un server che controlla. DNSSEC (DNS Security Extensions) risolve esattamente questo problema aggiungendo firme crittografiche alle risposte.

Cosa protegge DNSSEC (e cosa no)

DNSSEC garantisce autenticità e integrità: la risposta arriva davvero dalla zona autoritativa dichiarata e non è stata modificata in transito. Non garantisce invece riservatezza: le query e le risposte restano in chiaro, chiunque sul percorso può leggerle.

Questa è la distinzione più fraintesa. DNSSEC e DNS over HTTPS non sono alternative, sono complementari:

• DNSSEC → firma i dati, li valida ovunque siano transitati
• DoH/DoT → cifra il canale tra client e resolver, ma non dice nulla sulla veridicità del dato

Un resolver che parla DoH ma non valida DNSSEC può restituirti tranquillamente un record falsificato a monte.

La catena di fiducia

DNSSEC introduce nuovi record type che affiancano quelli classici:

• DNSKEY — la chiave pubblica della zona
• RRSIG — la firma di un record set (A, MX, TXT, ecc.)
• DS (Delegation Signer) — l'hash della DNSKEY del figlio, pubblicato nella zona padre
• NSEC / NSEC3 — prova firmata della non esistenza di un nome

Il meccanismo è una catena che parte dalla root:

1. Il resolver conosce a priori la chiave della root (trust anchor), distribuita con il software e aggiornata secondo RFC 5011
2. La root firma il record DS di .it
3. .it firma il record DS di velixconnect.it
4. La zona velixconnect.it firma i propri record con la sua chiave

Se anche un solo anello salta — DS mancante, firma scaduta, algoritmo non supportato — la validazione fallisce e il resolver restituisce SERVFAIL. Non restituisce il dato non firmato: preferisce non rispondere piuttosto che rispondere in modo non verificabile.

In pratica si usano due chiavi per zona: una KSK (Key Signing Key), a rotazione lenta, che firma solo il DNSKEY set ed è quella referenziata dal DS nel padre; e una ZSK (Zone Signing Key), più corta e a rotazione frequente, che firma tutti gli altri record. Questa separazione permette di ruotare la ZSK senza toccare il registrar.

Il problema delle firme scadute

A differenza di un certificato TLS, le RRSIG hanno una finestra di validità stretta — tipicamente da pochi giorni a un mese. Se il processo di ri-firma automatica si inceppa, il dominio smette di risolvere per tutti i resolver validanti nel giro di ore, senza preavviso e senza che nulla appaia rotto lato server.

È la causa numero uno degli outage DNSSEC. Le contromisure:

• Firma automatica delegata al provider DNS (inline signing su BIND, automatico su Cloudflare, Route53, deSEC)
• Monitoraggio della scadenza delle RRSIG con alert almeno a metà finestra
• Verifica del DS dopo ogni rollover della KSK: se cambi chiave senza aggiornare il DS presso il registrar, il dominio muore

Attivarlo sul proprio dominio

Il percorso standard oggi è quasi interamente gestito:

1. Abilita DNSSEC nel pannello del provider DNS autoritativo — genera le chiavi e attiva la firma automatica
2. Copia il record DS (o la DNSKEY, a seconda di cosa richiede il registrar) generato dal provider
3. Inseriscilo presso il registrar del dominio, che lo propaga al registry del TLD
4. Attendi la propagazione, tipicamente qualche ora

Se DNS autoritativo e registrar coincidono, spesso basta un interruttore.

Per la verifica esistono strumenti pubblici come DNSViz e Verisign DNSSEC Debugger, che disegnano l'intera catena e mostrano dove si rompe. Da riga di comando:

• dig +dnssec dominio.it — mostra le RRSIG e il flag AD (Authenticated Data) se il resolver ha validato
• delv dominio.it — esegue la validazione lato client e riporta fully validated

Attenzione: il flag AD dipende dal resolver che stai interrogando. Se usi un resolver che non valida, non vedrai AD anche su un dominio perfettamente firmato.

Lato ISP: validare o no

Un ISP che abilita la validazione sui propri resolver ricorsivi protegge tutti i clienti che usano i DNS di default, senza che debbano configurare nulla. Il costo è un aumento del carico CPU sui resolver e, soprattutto, il rischio di segnalazioni per domini di terzi mal configurati: se un e-commerce noto sbaglia il rollover, i tuoi utenti vedranno il sito irraggiungibile mentre chi usa un resolver non validante continua a navigare.

È un trade-off che quasi tutti gli operatori hanno ormai risolto a favore della validazione, adottando però monitoraggio attivo per distinguere rapidamente un guasto interno da una zona esterna rotta. La combinazione oggi consigliata per un'infrastruttura moderna è resolver validanti DNSSEC, esposti anche via DoH/DoT, con RPKI attiva sul lato routing: tre livelli che coprono rispettivamente l'integrità dei dati, la riservatezza del canale e l'autenticità degli annunci BGP.