Il dominio .de va offline: problemi DNSSEC fanno discutere

Per alcune ore, buona parte dei domini tedeschi con estensione .de ha smesso di rispondere correttamente su resolver DNS moderni come Google Public DNS(.8.8.8.8), Cloudflare 1.1.1.1 e Quad9 9.9.9.9. Il problema non è dipeso da un attacco DDoS, un guasto di rete o una compromissione dei server autoritativi di DENIC, il registro che gestisce il ccTLD tedesco. A causare il blackout è bastata una firma DNSSEC malformata pubblicata durante una rotazione delle chiavi crittografiche della zona .de. Un singolo errore crittografico ha reso irraggiungibili milioni di siti per tutti i resolver che applicano correttamente la validazione DNSSEC.

La “perfezione tedesca” è, insomma, andata in fumo riportando al centro della discussione una questione basilare che accompagna DNSSEC da oltre 20 anni. Da una parte c’è la necessità di autenticare le risposte DNS per bloccare attacchi come cache poisoning, spoofing e hijacking; dall’altra esiste un problema operativo molto concreto: quando la validazione fallisce, il protocollo interrompe completamente la risoluzione del dominio. Nessun degrado graduale, nessun fallback automatico: se la firma non è valida il dominio che la utilizza semplicemente “sparisce” e diventa irraggiungibile. Ma andiamo con ordine, e spieghiamo come funziona DNSSEC.

Cos’è DNSSEC e come funziona

DNSSEC, acronimo di Domain Name System Security Extensions, nasce per risolvere uno dei problemi storici del DNS tradizionale: l’assenza di autenticazione crittografica nelle risposte.

Il meccanismo di risoluzione dei nomi di dominio, progettato negli anni ’80, si limita infatti a rispondere alle query senza dimostrare che i dati arrivino realmente dal server autoritativo corretto (ovvero il server che ha “voce in capitolo” su un indirizzo mnemonico come google.com o ilsoftware.it).

Un resolver DNS che non usa DNSSEC riceve un indirizzo IP e lo considera valido associandolo all’indirizzo mnemonico. Il protocollo originale non prevede firme digitali né verifiche di integrità.

DNSSEC introduce una catena di fiducia crittografica basata su firme digitali RRSIG, chiavi DNSKEY e record DS pubblicati nella zona DNS superiore. Quando un resolver compatibile, cioè un server DNS in grado di verificare la sicurezza delle risposte, interroga un dominio firmato, controlla che i dati ricevuti non siano stati modificati o falsificati durante il trasferimento. Se la verifica fallisce o i dati risultano incoerenti, la richiesta viene bloccata.

Una soluzione efficace per contrastare gli attacchi ai resolver DNS

Il motivo principale che ha portato alla nascita di DNSSEC riguarda l’escalation di attacchi come i già citati cache poisoning, DNS spoofing e DNS hijacking.

Nel caso del cache poisoning un attaccante tenta di inserire record DNS falsi nella cache di un resolver ricorsivo, inducendo gli utenti a raggiungere server malevoli pur digitando indirizzi corretti. Uno degli episodi più famosi risale al 2008, quando il ricercatore Dan Kaminsky dimostrò una tecnica capace di avvelenare massivamente le cache DNS.

La tecnica del DNS spoofing segue una logica simile: l’attaccante intercetta o falsifica le risposte DNS prima che arrivino al client.

Nel DNS hijacking, invece, il traffico è reindirizzato alterando resolver, router, record autoritativi o configurazioni di rete, spesso tramite compromissioni dei provider Internet o malware installati sui dispositivi (anche quelli degli utenti).

DNSSEC: autenticità e integrità delle risposte

DNSSEC non cifra il traffico DNS e non protegge la privacy delle query: il suo compito è garantire autenticità e integrità delle risposte. In pratica impedisce che un resolver accetti dati manipolati da qualsiasi soggetto terzo. Se un attaccante tenta di modificare un record DNS di tipo A, MX o CNAME senza avere la chiave privata associata alla zona DNS, il controllo crittografico non va a buon fine.

Diversi TLD nazionali come .de e .it (e molti altri) supportano DNSSEC da anni; lo stesso vale per operatori governativi, registri bancari, provider cloud e piattaforme enterprise. Anche servizi come Cloudflare DNS, Quad9 e Google Public DNS effettuano validazione DNSSEC lato resolver.

Va detto però che numerosi grandi servizi consumer continuano a non firmare direttamente i propri domini principali, spesso per evitare complessità operative durante rotazioni chiavi, migrazioni CDN o modifiche DNS.

La firma RRSIG che ha bloccato la zona .de

La questione assume un peso particolare se si considera la dimensione della zona .de. DENIC gestisce circa 18 milioni di domini registrati e rappresenta una delle infrastrutture DNS nazionali più grandi al mondo.

Un errore in un TLD di queste dimensioni non resta confinato a pochi operatori: impatta servizi bancari, portali pubblici, media, e-commerce e infrastrutture aziendali distribuite su scala globale.

Le prime analisi tecniche hanno individuato un problema in una firma digitale RRSIG, il record utilizzato da DNSSEC per verificare l’autenticità dei dati DNS, associata a un record NSEC3 della zona .de, cioè l’insieme dei record DNS che gestiscono il dominio nazionale tedesco.

L’errore sarebbe stato introdotto durante una procedura di rotazione della zone-signing key, la chiave crittografica usata per firmare i record DNS della zona, probabilmente a causa della generazione o pubblicazione di una firma digitale non valida. Il record NSEC3, utilizzato da DNSSEC per confermare in modo sicuro che un dominio o un record DNS non esiste, conteneva infatti una firma malformata o corrotta.

Di conseguenza, i resolver compatibili con DNSSEC hanno iniziato a restituire errori SERVFAIL accompagnati da messaggi Extended DNS Errors come “RRSIG with malformed signature found“, segnalando l’impossibilità di verificare correttamente la firma digitale.

I resolver DNS senza validazione DNSSEC continuavano a risolvere correttamente i domini .de: chi invece utilizzava resolver moderni e configurati secondo le direttive fissate da IETF riceveva solo errori SERVFAIL.

Perché DNSSEC fallisce in modalità “fail-closed“

La filosofia di DNSSEC si basa su un approccio fail-closed: se il resolver non riesce a verificare l’autenticità dei dati DNS, blocca tutto. Non esiste una modalità permissiva standardizzata. Dal punto di vista della sicurezza la scelta è sensata: un attaccante non può bypassare la protezione in modo semplice.

Il rovescio della medaglia emerge proprio durante incidenti come quello tedesco: un errore operativo interno può produrre gli stessi effetti di un attacco sofisticato. Per il resolver non cambia nulla: la firma non è valida, quindi la risposta non è affidabile.

Il DNS tradizionale funziona invece in modalità “fail-open“: anche con dati inconsistenti o parzialmente corrotti, il sistema continua a rispondere.

DENIC utilizza una procedura di rotazione periodica delle chiavi, generalmente ogni 5 settimane. Si tratta di una tecnica standard: la nuova chiave è pubblicata prima dell’attivazione effettiva per permettere ai resolver di aggiornarsi in tempo. In teoria è un approccio che riduce i rischi; in pratica introduce una complessità notevole nelle procedure operative.

Negative Trust Anchor: la contromisura adottata da Cloudflare

Cloudflare ha reagito all’incidente tedesco introducendo un Negative Trust Anchor (NTA), come previsto dalla RFC 7646. Un NTA permette al resolver DNS di ignorare temporaneamente la validazione DNSSEC per una zona specifica. In sostanza il resolver continua a validare normalmente il resto dei nomi di dominio su scala globale, ma smette di verificare la firma problematica del TLD interessato.

La misura ha ripristinato rapidamente la raggiungibilità dei domini .de per gli utenti che utilizzavano il server DNS pubblico Cloudflare 1.1.1.1. Altri operatori hanno implementato workaround simili, ma non tutti con la stessa velocità. Chi dipendeva da resolver più lenti nell’applicazione delle mitigazioni ha continuato a subire problemi per diverse ore.

Va detto però che l’adozione di NTA non è una soluzione elegante: IETF raccomanda infatti che un NTA abbia una durata inferiore a una settimana e che il resolver verifichi periodicamente se la zona DNSSEC sia tornata valida.

Perché DNSSEC continua ad avere un’adozione limitata

Nonostante oltre 20 anni di standardizzazione, DNSSEC resta poco diffuso. Diverse analisi pubblicate nel 2026 indicano che solo una minima parte delle query DNS mondiali beneficia realmente di validazione end-to-end: alcuni report parlano di circa lo 0,47% delle richieste globali effettivamente validate.

Il dato è interessante perché spesso si confonde la presenza di firme DNSSEC su un dominio con la protezione reale degli utenti: un dominio firmato non garantisce nulla se il resolver del provider Internet usato dall’utente finale non effettua la validazione.

L’incidente tedesco probabilmente rafforzerà la prudenza. Per molte aziende il rapporto costi-benefici resta difficile da giustificare: DNSSEC protegge contro minacce reali, ma introduce modalità di funzionamento estremamente severe e soprattutto gli errori umani diventano devastanti quanto gli attacchi.