La zona radice del DNS ha iniziato a usare la nuova chiave di firma KSK l’11 ottobre. Tre giorni dopo, il 15 ottobre, ICANN ha confermato che il rollover è stato completato secondo il piano, aggiungendo però un elemento da seguire: sono arrivate segnalazioni di problemi su un numero limitato di sistemi e l’organizzazione sta ancora valutando se siano collegati alla transizione. La nota non indica quali operatori siano coinvolti né descrive un’interruzione generalizzata.
Il passaggio chiude la fase operativa più visibile, ma non il monitoraggio. Per chi gestisce resolver DNSSEC, registrar e servizi online che dipendono dalla risoluzione dei nomi, la notizia è un promemoria pratico: l’esito regolare della modifica alla radice non dimostra da solo che ogni resolver, configurazione manuale o infrastruttura meno aggiornata abbia già recepito correttamente la nuova ancora di fiducia.
Leggi anche: DNSSEC e rollover KSK: il test di preparazione per registry e resolver
Che cosa è cambiato l’11 ottobre
La KSK (Key Signing Key) della zona radice è il riferimento crittografico di fiducia da cui parte la validazione DNSSEC. I resolver che convalidano le risposte DNS usano questa catena per verificare che i dati ricevuti siano autentici e non siano stati alterati. In questa rotazione, la nuova chiave è identificata dal key tag 38696 e ha sostituito la precedente nell’uso per la zona radice.
La modifica non cambia i nomi di dominio registrati, le deleghe dei TLD o il funzionamento ordinario di un registrar. Agisce su un livello più basso: se un resolver validante non riconosce l’ancora corretta, può rifiutare come non valide risposte DNS che altrimenti sarebbero raggiungibili. Per utenti e aziende l’effetto potenziale non è quindi una perdita del dominio, ma un problema di risoluzione osservabile come sito o servizio non raggiungibile da alcune reti.
Le segnalazioni restano da chiarire
ICANN riferisce di essere a conoscenza di problemi che interessano un numero limitato di sistemi e di stare verificando il loro possibile rapporto con il rollover. Questa formulazione è cauta e va letta per quello che dice: la coincidenza temporale è oggetto di analisi, non una causa dimostrata. Non sono stati pubblicati conteggi, nomi di operatori, geografie o dettagli tecnici dei casi.
Perciò non c’è base, al momento, per concludere che la rotazione abbia provocato un incidente diffuso o che la chiave nuova sia difettosa. Le verifiche dovranno distinguere un’eventuale configurazione locale non aggiornata, software con procedure di aggiornamento dell’ancora non funzionanti e cause indipendenti dal rollover. Fino a quando non saranno disponibili elementi più precisi, la priorità per gli operatori è raccogliere log e misure del resolver interessato e confrontare il comportamento tra reti, senza disabilitare la validazione come correzione generalizzata.
La parte conclusiva del calendario è ancora davanti
Il cambio di chiave non coincide con la fine dell’intero processo. ICANN indica tra i prossimi passaggi operativi la revoca programmata della KSK precedente a gennaio 2027. La finestra di coesistenza e la preparazione anticipata sono state pensate proprio per consentire agli operatori di aggiornare le proprie implementazioni prima che la vecchia chiave venga ritirata.
Per provider di accesso, gestori di resolver aziendali, vendor di apparati e sviluppatori di software DNSSEC, questo significa verificare che gli aggiornamenti automatici dell’ancora siano abilitati e funzionanti, e controllare separatamente le installazioni in cui la configurazione è stata impostata manualmente. Per registrar e registry l’impatto diretto è più limitato, ma la resilienza della risoluzione è parte dell’affidabilità complessiva della catena dei nomi: vale la pena includere la verifica DNSSEC nei canali di assistenza e nei controlli sui servizi delegati.
Leggi anche: DNSSEC e automazione: perché la gestione ordinaria riduce il rischio operativo
La lettura Webinvest
Il rollover è una manutenzione programmata dell’infrastruttura globale, non un evento di mercato che modifica il valore o la titolarità dei domini. La notizia utile per chi opera nel settore è il passaggio dalla preparazione alla verifica sul campo: il nuovo key tag è in uso, ICANN monitora segnalazioni circoscritte e il ritiro della chiave precedente è ancora previsto per gennaio. La causa dei problemi segnalati resta aperta.
Chi valuta registrar, hosting o servizi DNS dovrebbe quindi concentrarsi su evidenze verificabili: uso di resolver aggiornati, validazione DNSSEC coerente, procedure di aggiornamento dell’ancora testate e capacità di isolare errori limitati a una rete o a una configurazione. Una segnalazione non confermata non equivale a un guasto sistemico; allo stesso tempo, il completamento del cambio non sostituisce i controlli locali. Il prossimo dato decisivo sarà l’eventuale chiarimento tecnico di ICANN o dei gestori coinvolti, seguito dalla revoca della vecchia chiave a inizio 2027.
Fonti: ICANN – Root Zone KSK Rollover Completed as Planned; IANA – DNS Root Zone Begins Using New Key Signing Key.
← Tutte le news