Si avvicina il cambio della chiave radice DNS, con lacune nella preparazione rilevata

Il cambio della chiave radice DNS previsto per l'11 ottobre 2026 si avvicina, con livelli di preparazione disomogenei nelle misurazioni riportate da Geoff Huston di APNIC. Il DNS, Domain Name System, traduce i nomi dei siti web in indirizzi di rete. La sua chiave radice aiuta i sistemi a verificare che le informazioni DNS siano autentiche: si tratta quindi di un intervento di manutenzione della sicurezza che, se la transizione non va a buon fine, può avere conseguenze sulla navigazione quotidiana.

Nel suo articolo per APNIC, pubblicato il 9 ottobre e scritto l'8 ottobre, Huston riferisce che circa il 70% dei test che sembravano supportare uno specifico meccanismo di verifica della preparazione indicava che la nuova chiave era considerata attendibile. Una misurazione separata condotta da Verisign, operatore di server radice, mostrava che circa il 90% dei resolver che inviavano segnalazioni l'aveva aggiunta. Nessuna delle due percentuali è una stima di quanti utenti internet perderanno il servizio. I metodi osservano popolazioni diverse e presentano limiti importanti.

Perché la chiave radice richiede una gestione particolare

Le DNS Security Extensions (DNSSEC) utilizzano firme digitali, prove matematiche di autenticità, per verificare le risposte DNS. Un resolver ricorsivo è il servizio che cerca queste risposte per conto dell'utente. Quando un resolver che esegue la validazione non riesce a stabilire l'attendibilità richiesta, una ricerca può fallire anziché restituire una risposta di cui non è possibile verificare l'autenticità.

Normalmente, le chiavi DNS sono organizzate in una gerarchia. Una Zone-Signing Key (ZSK), che firma i record all'interno di una sezione gestita del DNS chiamata zona, viene autenticata tramite la Key-Signing Key (KSK) di quella zona. La KSK di una zona subordinata è collegata alla zona superiore tramite un record Delegation Signer (DS) firmato, contenente un hash, ossia un'impronta matematica della chiave pubblica. Questo permette di estendere la fiducia da un livello a quello sottostante.

La KSK della radice non ha una zona superiore. La chiave attendibile esistente firma invece un insieme di record di chiavi contenente quella che la sostituirà. I resolver devono quindi avere tempo sufficiente per rilevare e accettare la nuova chiave come ancora di fiducia, un punto di partenza memorizzato localmente per l'autenticazione.

La procedura di aggiornamento automatico è specificata in RFC 5011. Il periodo di attesa è di almeno 30 giorni, o più lungo se richiesto dal time to live (TTL) originale, l'intervallo di validità associato al primo insieme pertinente di record di chiavi. Prima di accettare la nuova chiave, un resolver deve rilevare almeno due insiemi autenticati di record di risorsa DNSKEY, le raccolte delle chiavi DNS pubblicate, che la contengano. Rispettando i periodi di attesa richiesti, la transizione dovrebbe avvenire automaticamente.

Questa rotazione cambia la coppia di chiavi, non l'algoritmo crittografico. La nuova KSK-2024 è stata pubblicata sul sito dell'Internet Assigned Numbers Authority (IANA) nel luglio 2024 e aggiunta ai record DNSKEY della radice nel gennaio 2025. IANA prevede di iniziare a utilizzarla per firmare l'insieme di record DNSKEY della radice l'11 ottobre 2026.

Due modi per esaminare la preparazione

RFC 8145 descrive come i resolver possono segnalare ai server radice le chiavi che considerano attendibili. Un key tag è un breve identificatore numerico di una chiave. I resolver possono inserire questi identificatori nel nome di una query: `_ta-4f66-9728` indica fiducia nelle chiavi contrassegnate dai tag 20326 e 38696. In alternativa, possono includere i valori in un'opzione edns-key-tag, un campo aggiuntivo trasmesso insieme a una query DNS.

Gli operatori dei server radice possono esaminare questi segnali nei registri delle query. Il campione di Verisign del luglio 2026 mostrava che circa il 90% dei resolver che inviavano segnalazioni aveva aggiunto KSK-2024. Ma un resolver può servire milioni di persone oppure una sola, come quello sul portatile di Huston. Contare i resolver, quindi, non rivela il numero di utenti che dipendono da sistemi non ancora pronti.

RFC 8509 adotta un approccio diverso. Il suo meccanismo Root Key Trust Anchor Sentinel invia un segnale di ritorno alla persona che esegue la query. Un resolver che lo supporta riconosce un prefisso speciale nel nome richiesto e modifica la risposta in base alle chiavi che considera attendibili.

Per `root-key-sentinel-is-ta-`, una chiave attendibile produce la risposta originale; una chiave non attendibile produce SERVFAIL, una risposta di errore DNS. Per `root-key-sentinel-not-ta-`, questi esiti sono invertiti. Il team DNS di Cloudflare gestisce una pagina web attraverso cui gli utenti possono eseguire questi test sulla propria configurazione DNS.

APNIC utilizza misurazioni basate su annunci pubblicitari per sottoporre agli utenti internet tre query di prova. Le prime due verificano il supporto del meccanismo usando KSK-2017, contrassegnata dal tag 20326. Un resolver che supporta il meccanismo e considera attendibile quella chiave dovrebbe restituire NOERROR, una risposta DNS che indica il successo dell'operazione, per il test is-ta e SERVFAIL per il test not-ta. Un resolver privo di supporto restituisce invece una risposta autenticata per entrambi. La terza query verifica se KSK-2024, contrassegnata dal tag 38696, è considerata attendibile.

Anziché identificare i singoli resolver, APNIC cerca di misurare gli utenti le cui richieste DNS passano esclusivamente attraverso resolver che eseguono la validazione e non considerano ancora attendibile la chiave sostitutiva. Solo i campioni con le risposte attese ai test iniziali vengono conteggiati come utenti che forniscono una segnalazione.

Che cosa hanno rilevato i test di APNIC

Huston riferisce che un piccolo test del 5 ottobre, condotto usando sonde RIPE Atlas, dispositivi utilizzati per misurare la connettività internet, ha coperto 2.900 sistemi autonomi distinti, ossia reti amministrate separatamente. Ha rilevato 1.230 sonde con un comportamento coerente con il supporto del meccanismo sentinel e l'accettazione della nuova chiave. Altre 47 si comportavano in modo coerente con il mancato caricamento della chiave.

I test su più vasta scala di APNIC, basati su annunci pubblicitari, si sono svolti tra maggio e luglio 2026 e sono ripresi all'inizio di ottobre, con una media di circa 16 milioni di test al giorno. Circa 6 milioni di test giornalieri sembravano utilizzare resolver che eseguono la validazione DNSSEC, e circa 1,8 milioni fornivano un segnale chiaro di supporto del meccanismo sentinel. Tra i campioni che sembravano supportare quel meccanismo, circa il 70% segnalava di considerare attendibile KSK-2024. Questi filtri sono importanti: il risultato non può essere semplicemente esteso a tutti i resolver o a tutti gli utenti internet.

Le medie nascondono inoltre differenze sostanziali tra le reti. Huston descrive una tabella delle 50 reti con i tassi di accettazione più bassi, limitata alle reti con almeno 1.000 test che mostravano il supporto del meccanismo sentinel. L'estratto fornito termina prima che la tabella completa sia visibile. I tassi di accettazione elencati includono il 16,40% per Allo Comms negli Stati Uniti, il 12,70% per Vodafone Libertel nei Paesi Bassi, l'8,20% per Vodafone-CZ in Cechia, il 6,20% per Superloop in Australia e il 2,50% per Reliance Jio in India. Si tratta di segnali misurati di preparazione, non di tassi confermati di interruzione del servizio né della prova che ogni cliente di quelle reti sia interessato.

Per le aziende e i proprietari di siti web, la questione pratica è se il servizio DNS da cui dipendono abbia accettato l'ancora di fiducia sostitutiva. Chiedere al fornitore o al team IT di verificare la preparazione è più utile che interpretare una percentuale aggregata come una previsione per una specifica connessione.

AEU DNS offre un servizio DNS privato e crittografato ai lettori che desiderano proteggere le proprie richieste durante il transito, ma la crittografia è distinta dalla preparazione dell'ancora di fiducia DNSSEC e non garantisce di per sé che il sistema sia pronto per questa rotazione. I dati riportati qui riguardano la preparazione prima del cambio programmato, non un'interruzione osservata dopo di esso.