L'11 ottobre 2026 avverrà il secondo rollover della chiave KSK del DNS root. L'operazione sostituirà KSK-2017 con KSK-2024 per mantenere l'integrità della catena di fiducia DNSSEC globale.
L'11 ottobre 2026 il DNS root eseguirà il rollover della sua Key Signing Key (KSK), un'operazione critica che avviene solo per la seconda volta nella storia di Internet. Nello specifico, la chiave KSK-2017, identificata dal tag 20326, verrà sostituita dalla nuova chiave KSK-2024, contrassegnata dal tag 38696. Questo cambiamento non riguarda i singoli siti web, ma l'ancora di fiducia che permette ai resolver DNS di autenticare le risposte tramite firme crittografiche, un processo noto come DNSSEC (Domain Name System Security Extensions). [1]
L'impatto principale di questa operazione ricade sui gestori di resolver DNS che effettuano la validazione DNSSEC. Se un resolver non riconosce e non si fida della nuova chiave KSK-2024 prima della data dello switch, potrebbe considerare invalidi i record DNS di interi domini di primo livello (TLD), rendendo i siti web irraggiungibili nonostante siano perfettamente funzionanti. Questo accade perché l'ancora di fiducia, ovvero il punto di partenza della verifica crittografica, risulterebbe errata, interrompendo l'intera catena di convalida che parte dal root e arriva al dominio finale. [1]
Per comprendere l'importanza del KSK, occorre analizzare come DNSSEC verifichi l'autenticità di un record. Un resolver non si fida ciecamente di una risposta, ma segue una catena di fiducia: per verificare un dominio come cloudflare.com, controlla il record Delegation Signer (DS) pubblicato dal dominio genitore .com, il quale a sua volta è verificato dal root DNS. Il root, non avendo un genitore superiore, utilizza una chiave pubblica preconfigurata nel resolver, chiamata trust anchor. Questa ancora è l'unico punto di partenza certo per l'intera infrastruttura di sicurezza del DNS globale. [1][2]
All'interno del root, esistono due tipi di chiavi con ruoli distinti. La Zone Signing Key (ZSK) si occupa di firmare i record DNS del root, inclusi i record DS per i TLD. La Key Signing Key (KSK), invece, firma l'elenco delle chiavi pubbliche del root stesso (il set DNSKEY). Il resolver utilizza l'ancora di fiducia KSK per verificare che l'elenco delle chiavi sia autentico e, solo a quel punto, utilizza la ZSK contenuta in quell'elenco per validare gli altri record. Il rollover di ottobre sostituisce proprio questa chiave di livello superiore, che garantisce l'integrità di tutto ciò che sta sotto. [1]
Sequenza di transizione per mantenere la catena di fiducia DNSSEC
L'aggiornamento della chiave non avviene istantaneamente per evitare blackout globali, ma segue il protocollo RFC 5011. Questo meccanismo permette ai resolver di apprendere automaticamente la nuova chiave: il root pubblica KSK-2024 insieme alla vecchia KSK-2017. Poiché la vecchia chiave continua a firmare il set, il resolver può verificare l'autenticità della nuova. Tuttavia, per prevenire attacchi, il resolver non accetta immediatamente la nuova chiave come ancora di fiducia, ma attende un periodo di osservazione di almeno 30 giorni, verificando che la chiave rimanga costante nei record pubblicati. [1][2]
Nonostante l'automazione, l'esperienza del primo rollover del 2018 ha mostrato che aggiornamenti software o migrazioni tra macchine possono causare la perdita dello stato di fiducia appreso. Per mitigare questo rischio, alcuni provider come Cloudflare hanno scelto di inserire KSK-2024 direttamente nel codice del software (built-in trust anchors) a partire da luglio 2024. Questo approccio elimina la dipendenza dal processo di apprendimento automatico di RFC 5011, garantendo che ogni istanza del resolver sia pronta fin dal primo avvio senza dover attendere i 30 giorni di validazione. [1]
Per risolvere l'impossibilità di verificare se un resolver remoto si fidi della nuova chiave, è stato introdotto lo standard RFC 8509, che definisce i 'sentinel' (sentinelle) dell'ancora di fiducia. Questo sistema utilizza query DNS speciali verso domini specifici per interrogare il resolver. Ad esempio, una query a un dominio che contiene 'is-ta-38696' chiede se la chiave KSK-2024 è trusted. Se il resolver supporta il sentinel e si fida della chiave, restituirà una risposta valida; se non si fida, restituirà un errore SERVFAIL. Al contrario, una query a 'not-ta-38696' dovrebbe restituire SERVFAIL se la chiave è correttamente trusted. [1]
Un esempio operativo di verifica consiste nell'utilizzare lo strumento dig per interrogare un resolver specifico, come 1.1.1.1, verso il dominio di test dnstest.dev. Eseguendo il comando 'dig @1.1.1.1 root-key-sentinel-is-ta-38696.dnstest.dev', l'utente può osservare se riceve un codice NOERROR con un indirizzo IP valido. Se invece l'interrogazione a 'root-key-sentinel-not-ta-38696.dnstest.dev' restituisce SERVFAIL, il test conferma che il resolver non solo supporta il protocollo sentinel, ma ha correttamente integrato KSK-2024 come ancora di fiducia, superando i criteri di validazione richiesti. [1]
È fondamentale distinguere tra un risultato negativo e un risultato inconcludente durante i test di prontezza. Se un resolver non supporta lo standard RFC 8509, il test non sarà in grado di determinare se la chiave KSK-2024 sia presente o meno. In questo caso, l'assenza di una risposta specifica non indica necessariamente che la chiave manchi, ma solo che il protocollo di interrogazione non è implementato. Inoltre, i test effettuati tramite browser possono essere influenzati da configurazioni di Secure DNS (DoH) o dall'uso di VPN, che spostano l'interrogazione su resolver diversi da quelli configurati localmente sul sistema operativo. [1]
L'interpretazione corretta richiede una verifica a più livelli: prima accertarsi che il resolver risponda correttamente a una query DNSSEC standard e a una query sentinel per la chiave root attuale. Solo dopo aver stabilito che il supporto al sentinel è attivo, il risultato della query per KSK-2024 diventa significativo. Se il test restituisce un errore di lookup generico invece di un SERVFAIL specifico per il sentinel 'not-trusted', l'operatore deve considerare il risultato come non determinativo e procedere con il controllo manuale dei file di configurazione del software. [1]
Il rollover di ottobre 2026 mantiene l'algoritmo RSA/SHA-256, sostituendo solo la coppia di chiavi. Questo approccio è stato scelto per ridurre i rischi, separando il cambio di chiave dal cambio di algoritmo. Una volta completata la transizione, ICANN prevede di revocare e rimuovere definitivamente KSK-2017 nel corso del 2027. L'obiettivo a lungo termine è l'adozione di algoritmi più efficienti come ECDSA P-256, che produce chiavi e firme più piccole rispetto a RSA, sebbene questa transizione richieda un ulteriore rollover completo e l'aggiornamento del software dei resolver. [1]
La sfida futura riguarda la sicurezza post-quantum. Sebbene 1.1.1.1 validi già firme ML-DSA-44, progettate per resistere agli attacchi dei computer quantistici, l'intera catena di fiducia DNSSEC deve migrare a standard post-quantum per essere effettivamente sicura. Ciò richiederà che non solo il root, ma anche i domini firmati e le loro zone genitrici adottino nuove chiavi. Il rollover di ottobre 2026 funge quindi da esercitazione tecnica essenziale per testare la distribuzione delle ancore di fiducia, preparando l'infrastruttura globale a migrazioni crittografiche molto più complesse in futuro. [1]
NVIDIA e Microsoft lanciano RTX Spark, un superchip che integra GPU Blackwell e CPU Grace per permettere l'esecuzione locale di agenti AI complessi su laptop e desktop Windows, riducendo la dipendenza dal cloud.
Il 5 ottobre 2026, Amazon Bedrock ha reso disponibile GLM 5.3 di Z.ai, un modello open-weight basato su architettura Mixture-of-Experts ottimizzato per l'ingegneria del software e il coding autonomo.
Dal 5 ottobre 2026, le istanze Amazon EC2 Hpc8a, basate su processori AMD EPYC di 5ª generazione, sono disponibili nella regione Asia Pacific (Singapore) per carichi HPC intensivi e a bassa latenza.
Parliamone
Hai un’esperienza da condividere o una domanda? Scrivi un commento pertinente, senza pubblicità o link.