Dopo l'interruzione di .al in Albania per un rollover DNSSEC fallito, 1.1.1.1 ora rivela i bypass di validazione

A metà luglio 2026, un processo di sicurezza di routine per il dominio di primo livello nazionale dell'Albania, .al, è andato storto e ha mandato offline l'intero dominio. La causa è stato un rollover DNSSEC fallito, la procedura che sostituisce le chiavi crittografiche usate per firmare i record DNS di .al. Il 14 luglio 2026, l'ingegnere di Cloudflare Sebastiaan Neuteboom ha pubblicato un dettagliato rapporto sull'incidente spiegando come il resolver DNS pubblico dell'azienda, 1.1.1.1, ora inizi a comunicare agli utenti quando bypassa deliberatamente la validazione DNSSEC. Il nuovo segnale appare come codice di errore DNS esteso 33, chiamato anche EDE 33, e rende visibili a tutti gli interessati le 'ancore di fiducia negative' precedentemente invisibili.

Prima, un rapido ripasso delle basi. Il Domain Name System, o DNS, è l'elenco telefonico di Internet: converte nomi leggibili come google.al in indirizzi IP numerici che i computer usano per connettersi. DNSSEC, abbreviazione di Domain Name System Security Extensions, aggiunge un livello di firme digitali ai record DNS così che un resolver, il server che esegue questa ricerca, possa verificare che la risposta non sia stata alterata da un attaccante. Quando DNSSEC funziona correttamente, un resolver segue una catena di fiducia dalla radice del DNS fino al dominio specifico. Se un anello di quella catena è rotto, la validazione fallisce e il resolver normalmente restituisce un errore. Tuttavia, un'ancora di fiducia negativa, o NTA, è una configurazione manuale che dice a un resolver di trattare temporaneamente una zona specifica, come .al, come se non fosse affatto firmata con DNSSEC. Gli operatori di resolver usano le NTA quando la configurazione DNSSEC di una zona è errata o rotta, per mantenere i domini della zona raggiungibili per gli utenti mentre il problema di base viene risolto. Fino ad ora, questo bypass avveniva in silenzio, lasciando utenti, proprietari di siti web e strumenti di monitoraggio senza alcuna idea che le loro risposte DNS non fossero state completamente validate.

Il rapporto di Cloudflare mostra come appare questo in pratica usando il dominio di esempio google.al. Quando 1.1.1.1 riceve una query per google.al durante una NTA attiva per la zona .al, restituisce una risposta normale con il codice di stato NOERROR, che significa che la query è riuscita. Ma a questa risposta sono allegati due codici di errore DNS esteso. Il primo, EDE 9, chiamato DNSKEY Missing, rivela il vero fallimento DNSSEC: la catena di fiducia era rotta, quindi la validazione non poteva riuscire. Il secondo è il nuovo EDE 33, che sta per Negative Trust Anchor e dice al client che 1.1.1.1 ha applicato un'ancora di fiducia negativa e ha servito la risposta comunque. Insieme, questi due codici danno piena trasparenza: la risposta è autentica e completa, ma non è stata validata con DNSSEC. Poiché la NTA copre l'intera zona .al, 1.1.1.1 restituisce EDE 33 su qualsiasi risposta generata mentre la NTA è attiva, anche per un dominio sotto .al che non usa affatto DNSSEC. Questo è intenzionale, spiega Cloudflare, perché la NTA si applica all'intera zona e il resolver vuole essere ugualmente trasparente su ogni risposta servita sotto di essa.

Il nuovo codice risolve anche un problema di segnalazione precedente da un incidente simile nel dominio di primo livello tedesco .de. In quel caso precedente, 1.1.1.1 aveva erroneamente restituito EDE 22, che significa No Reachable Authority, invece di far emergere l'errore DNSSEC sottostante. Durante l'incidente .al, il resolver ha correttamente restituito EDE 9 insieme a EDE 33, dando un quadro preciso di cosa sia andato storto. La Internet-Draft che definisce EDE 33 è stata presentata come contributo individuale al gruppo di lavoro DNS Operations (DNSOP) della Internet Engineering Task Force (IETF). La Internet Assigned Numbers Authority (IANA) ha già assegnato il numero di codice 33. Cloudflare ringrazia Babak Farrokhi di Quad9, co-autore della bozza, e nota che lo strumento da riga di comando kdig del progetto Knot ora riconosce EDE 33 per nome. Una richiesta pull per aggiungere lo stesso supporto al resolver DNS Unbound è in revisione. La bozza sarà discussa alla riunione IETF a Vienna dal 18 al 24 luglio 2026.

Questo sviluppo è importante perché i fallimenti DNSSEC dei domini di primo livello, sebbene rari, colpiscono tutti i domini sotto il TLD rotto allo stesso tempo e tutti i resolver validanti allo stesso modo. L'incidente .al, arrivato subito dopo .de, dimostra che le ancore di fiducia negative sono uno strumento operativo necessario. Ma fino a EDE 33, il loro uso era invisibile agli utenti finali. Aggiungendo questo codice, 1.1.1.1 chiude un vuoto lasciato aperto da RFC 7646, lo standard che originariamente definiva come i resolver dovrebbero gestire i fallimenti di validazione DNSSEC. Ora una risposta servita sotto un'ancora di fiducia negativa lo dice direttamente, dando a operatori, strumenti di monitoraggio e utenti comuni le informazioni necessarie per capire esattamente cosa ha fatto il resolver e perché. La Internet-Draft è disponibile sul datatracker IETF, e il feedback può essere inviato alla mailing list DNSOP. Cloudflare indica anche ai lettori la sua pagina 'Come funziona DNSSEC?' per ulteriori informazioni di base e Cloudflare Radar per tendenze DNS in tempo reale e dati sui TLD.

Per i proprietari di siti web e i team IT, la lezione è chiara: le configurazioni errate di DNSSEC possono abbattere un intero dominio di primo livello, quindi il monitoraggio regolare e una pianificazione attenta del rollover delle chiavi sono essenziali. Per gli utenti Internet di tutti i giorni, scegliere un resolver che segnala i codici EDE ti dà un modo per vedere quando le tue risposte DNS non sono state completamente validate. Un servizio DNS crittografato incentrato sulla privacy come AEU DNS aggiunge un altro strato protettivo crittografando le tue ricerche DNS end-to-end, e il suo supporto per DNSSEC e codici di errore estesi significa che ottieni una trasparenza simile quando qualcosa va storto. Prestando attenzione a questi segnali, puoi evitare di essere ingannato da un problema di rete o da un attacco a livello DNS.