La rotazione della chiave radice DNS richiede che KSK-2024 sia considerata attendibile
Il DNS, il Domain Name System che traduce i nomi dei siti web in indirizzi di rete, si prepara a un importante aggiornamento delle relazioni di fiducia l'11 ottobre 2026: la radice passerà a una nuova chiave di firma. Nel loro rapporto del 6 ottobre, Sebastiaan Neuteboom e James Godlewski di Cloudflare esortano gli operatori a confermare che i loro sistemi di verifica DNS considerino attendibile KSK-2024, con key tag 38696. Il cambiamento mantiene l'algoritmo crittografico esistente, ma l'accettazione della nuova chiave è essenziale affinché la risoluzione dei nomi continui a funzionare correttamente.
I sistemi interessati sono i resolver che eseguono la validazione DNSSEC. Un resolver risolve i nomi per conto di utenti e applicazioni; le DNS Security Extensions (DNSSEC) gli consentono di verificare le firme digitali per stabilire l'autenticità delle informazioni DNS. Questa verifica dipende da una catena di fiducia che arriva fino alla radice, il vertice della gerarchia DNS. Una key-signing key (KSK) della radice firma il set DNSKEY della radice, ossia la raccolta pubblicata delle sue chiavi di verifica DNS. Un'ancora di fiducia è l'insieme delle informazioni sulla chiave che un resolver accetta come punto di partenza per queste verifiche. Senza la chiave attendibile appropriata, la verifica può fallire anche quando il servizio richiesto funziona correttamente.
Il passaggio dell'11 ottobre cambia la KSK che firma tale raccolta di chiavi della radice. Non completa il ritiro della chiave precedente. Secondo il rapporto, l'Internet Corporation for Assigned Names and Numbers (ICANN) prevede di revocare KSK-2017 nel 2027, rimuoverla dalla zona radice, cioè dai record DNS al vertice della gerarchia, ed eliminarne la chiave privata. Una chiave privata è il materiale segreto utilizzato per creare le firme. Porre fine al ruolo di firma di una chiave e revocare la fiducia in essa sono operazioni distinte, ed è per questo che la transizione si estende oltre ottobre.
Per gli utenti, il rapporto indica il test di preparazione del resolver. Il test utilizza un trust anchor sentinel, una query DNS speciale che può rivelare se un resolver ha accettato una determinata chiave della radice. Verifica inoltre che un nome firmato normalmente venga risolto correttamente, che un nome con informazioni DNSSEC volutamente non valide venga rifiutato e che il resolver risponda a una query sentinel relativa alla chiave attuale della radice. Questi controlli aiutano a distinguere un risultato significativo sulla preparazione da un errore di risoluzione o da un resolver che non supporta il meccanismo di test.
Un limite importante è che un test dall'esito non conclusivo non dimostra che la nuova chiave sia assente. Se non è possibile confermare il supporto ai sentinel, il test non può rispondere a questa domanda. Inoltre, il test controlla il resolver utilizzato dal browser, la cui scelta può essere influenzata da Secure DNS, un'opzione del browser per la risoluzione DNS cifrata, o da una rete privata virtuale (VPN), che instrada il traffico attraverso un'altra connessione di rete. Cloudflare mette a confronto questo approccio con i propri esempi da riga di comando che utilizzano dig, uno strumento di risoluzione DNS, e interrogano esplicitamente il suo resolver 1.1.1.1. Entrambi i metodi rilevano soltanto il percorso di risoluzione che risponde a quelle specifiche richieste, non tutti i sistemi DNS che un'organizzazione potrebbe utilizzare.
KSK-2017 e KSK-2024 utilizzano entrambe RSA/SHA-256, la stessa combinazione di metodi crittografici per creare e verificare le firme. Si tratta della sostituzione della coppia di chiavi, non di un cambio di algoritmo. Cloudflare ricorda di aver scritto nel 2018 che una rotazione riuscita avrebbe potuto aprire il dibattito su un cambio di algoritmo; otto anni dopo, la radice utilizza ancora RSA. La rotazione della chiave limita comunque il tempo durante il quale una singola chiave privata rimane in uso e permette di collaudare la distribuzione di nuove ancore di fiducia, gli aggiornamenti dei resolver e il ritiro delle vecchie chiavi. Il rapporto osserva che la prima rotazione ha dimostrato come queste fasi operative possano fallire anche quando la crittografia funziona correttamente.
L'Internet Assigned Numbers Authority (IANA) prevede idealmente un intervallo di tre anni tra le rotazioni, bilanciando la regolare pratica operativa con l'impegno e i rischi dei cambiamenti frequenti. Il periodo trascorso dal 2018 è stato più lungo. ICANN attribuisce questo ritardo alle interruzioni causate dalla pandemia e agli aggiornamenti dell'hardware che protegge le chiavi private di firma. Mantenere invariato l'algoritmo consente agli operatori di testare separatamente gli aggiornamenti delle ancore di fiducia. Una transizione a un altro algoritmo aggiunge un ulteriore requisito: anche il software del resolver deve essere in grado di verificare il nuovo tipo di firma.
Separatamente, ICANN ha proposto una futura transizione dell'algoritmo della radice a ECDSA P-256, un metodo di firma digitale a curva ellittica che produce chiavi e firme più piccole rispetto a RSA. Non fa parte della sostituzione della chiave di ottobre e non è crittografia post-quantistica, cioè crittografia progettata per resistere agli attacchi condotti con computer quantistici. Cloudflare afferma che 1.1.1.1 ora convalida le firme ML-DSA-44, progettate per offrire tale resistenza. Il solo supporto in un resolver, tuttavia, non può rendere l'intera catena DNSSEC sicura contro gli attacchi quantistici: i domini firmati, le rispettive zone superiori e la radice dovrebbero tutti adottare una crittografia adeguata.
A livello della radice, quella futura transizione richiederebbe una KSK post-quantistica e un'altra distribuzione per far sì che i resolver la considerino attendibile. La sostituzione attuale mette quindi alla prova un processo operativo pertinente, senza offrire di per sé resistenza agli attacchi quantistici. Cloudflare incoraggia i fornitori DNS e gli sviluppatori di resolver a implementare RFC 8509, la specifica per i trust anchor sentinel, affinché gli utenti possano verificare la preparazione prima di una rotazione anziché dipendere da un presupposto non verificabile.
Per i lettori che stanno valutando chi gestisce la risoluzione dei loro nomi, AEU DNS offre un DNS privato e sicuro, sebbene questa sola descrizione del servizio non ne dimostri la preparazione per questa specifica rotazione. Il compito immediato per chiunque gestisca un resolver con validazione DNSSEC è più preciso: verificare che consideri attendibile KSK-2024 con key tag 38696 e, in caso contrario, seguire le indicazioni di ICANN e le istruzioni del fornitore del software del resolver. Gli utenti il cui test dà un esito non conclusivo dovrebbero chiedere al proprio fornitore DNS informazioni sul supporto ai sentinel e sulla preparazione, anziché interpretare l'incertezza come un malfunzionamento confermato o come una garanzia che tutto sia a posto.