Il report finale pubblicato da DENIC sul blackout DNS del 5 maggio 2026 conferma un punto spesso sottovalutato: la sicurezza del DNS non e' solo una questione di attivare DNSSEC, ma di gestire con estrema disciplina i processi che mantengono valida la catena di fiducia. Nel caso del ccTLD tedesco .de, un rollover ordinario delle chiavi ha generato firme non validabili e ha limitato per circa tre ore l'accesso a una parte dei domini sotto l'estensione nazionale.
Per chi investe, sviluppa o gestisce domini, il caso e' interessante perche non riguarda un singolo registrar, un provider hosting o una configurazione errata del singolo dominio. Il problema si e' manifestato al livello della registry, quindi nella parte alta della gerarchia DNS. Quando un TLD grande come .de incontra un errore di firma, l'impatto puo propagarsi rapidamente verso resolver, servizi, email e applicazioni che dipendono da nomi apparentemente non correlati.
Leggi anche: DNS-PERSIST-01: la validazione dei certificati diventa piu stabile per chi gestisce domini
Cosa e' successo durante il rollover DNSSEC
Secondo DENIC, il 5 maggio 2026 un normale rollover DNSSEC ha prodotto una situazione anomala nel sistema di firma della zona .de. Il processo avrebbe dovuto generare una sola coppia di chiavi e caricarla in piu Hardware Security Module distribuiti tra data center separati. A causa di un errore nel codice di un componente interno, invece, sono state generate tre coppie di chiavi diverse, con gli stessi identificativi e lo stesso key tag.
Il risultato operativo e' stato insidioso: una parte delle firme pubblicate risultava valida, mentre un'altra parte non poteva essere verificata dai resolver che applicano DNSSEC. DENIC segnala che non si e' trattato di un attacco, di una compromissione dell'infrastruttura, di un guasto dei server Knot o degli HSM, ne' di una classica collisione del key tag. Il problema era nel comportamento del codice che orchestrava il caricamento del materiale crittografico.
La conseguenza piu rilevante e' che anche domini di secondo livello non firmati con DNSSEC potevano risultare irraggiungibili. In una zona TLD, infatti, la validazione coinvolge anche record firmati usati per provare l'assenza di determinati dati di delega. Se quei record risultano sospetti, un resolver validante puo classificare la risposta come bogus e restituire errore invece di completare la risoluzione.
Perche l'incidente conta oltre il mercato tedesco
.de e' uno dei ccTLD piu importanti al mondo per volume, uso reale e centralita economica. Un'interruzione di tre ore a quel livello non e' solo un problema nazionale: coinvolge utenti internazionali, CDN, resolver pubblici, aziende con fornitori tedeschi, applicazioni SaaS, caselle email e servizi che usano nomi .de come endpoint tecnici.
Il caso mostra anche una tensione operativa: DNSSEC fa correttamente il proprio lavoro quando rifiuta firme non validabili, ma quella stessa rigidita puo trasformare un errore di firma centrale in un blocco percepito come indisponibilita totale. Alcuni grandi resolver hanno mitigato l'impatto sospendendo temporaneamente la validazione per .de, una scelta che riduce il disservizio ma introduce un compromesso di sicurezza da valutare solo in condizioni eccezionali e pubblicamente confermate.
Leggi anche: Domain security e continuità operativa: il DNS entra nei piani di resilienza
Le misure annunciate da DENIC
Nel report finale, DENIC indica diverse azioni correttive: miglioramento degli alert, maggiore visibilita sugli errori intercettati dagli strumenti di validazione, procedura accelerata per ripristinare una zona valida in emergenza, validazione parziale prima della pubblicazione e sospensione di ulteriori rollover ZSK finche non saranno completati altri interventi sul processo di sviluppo e sull'ambiente di test.
Un passaggio importante riguarda proprio i test. Il difetto non era emerso perche l'ambiente di prova non riproduceva pienamente lo scenario con piu HSM collegati. Per un'infrastruttura registry, questa e' una lezione forte: non basta testare la logica in condizioni semplificate, perche gli errori piu costosi spesso emergono solo quando il sistema reale distribuito viene attraversato da procedure rare ma critiche.
Leggi anche: .pk sotto osservazione: governance, DNSSEC e sovranita digitale dei ccTLD
Cosa controllare nei propri domini
Per i titolari di portafogli e per le aziende, la lezione pratica non e' disattivare DNSSEC per paura degli incidenti. La lezione e' sapere chi controlla ogni punto della catena: registry, registrar, DNS provider autoritativo, resolver usati dagli utenti, monitoraggio esterno e procedure di escalation. Un dominio strategico dovrebbe essere monitorato non solo via HTTP, ma anche attraverso query DNS da resolver diversi, con attenzione a errori SERVFAIL, risposte DNSSEC bogus e divergenze tra reti.
Chi gestisce nomi critici dovrebbe inoltre tenere aggiornata la documentazione operativa: dove sono le zone, chi puo modificare DS record e DNSKEY, quali contatti usare in emergenza, quali servizi dipendono da sottodomini o deleghe specifiche. Nei mercati dei domini si parla spesso di prezzo, liquidita e brandability; episodi come quello di .de ricordano che il valore di un nome dipende anche dalla continuita della risoluzione.
Leggi anche: ccNSO e DASC preparano il terzo sondaggio sul DNS abuse nei ccTLD
La lettura Webinvest
Il blackout DNSSEC di .de non ridimensiona l'importanza di DNSSEC, ma chiarisce che la sicurezza dei domini e' un processo industriale, non una casella tecnica da spuntare. Per registry e registrar, la fiducia si gioca sulla capacita di testare scenari rari, reagire in modo coordinato e comunicare rapidamente. Per gli investitori e le aziende, invece, il messaggio e' piu concreto: un dominio premium o operativo vale davvero solo se la sua infrastruttura di risoluzione e' osservabile, documentata e governata.
Fonte: DENIC, Final Report: DNS Outage of 5 May 2026. Approfondimento tecnico correlato: Cloudflare Blog.
← Tutte le news