Il cambio della chiave radice DNSSEC è avvenuto: cosa devono verificare gli operatori

La tappa dell’ottobre 2026 non è stata un passaggio di consegne nella gestione della zona radice DNS. È stato un rollover della Key Signing Key (KSK) che supporta DNSSEC: dall’11 ottobre, la nuova KSK-2024, identificata dal key tag 38696, firma il DNSKEY set della radice. ICANN e IANA avevano pianificato la sostituzione nell’ambito di una transizione graduale avviata nel 2024. È cambiata una chiave crittografica, non la responsabilità operativa.

La distinzione è importante. La zona radice resta il punto di riferimento più alto della gerarchia DNS e questo cambiamento non ne ha trasferito la gestione a una nuova organizzazione. È cambiata la chiave crittografica che i resolver validanti usano come trust anchor per verificare la zona radice e, attraverso di essa, la catena DNSSEC. Definire l’evento un cambio di operatore confonde governance e infrastruttura con il normale rinnovo delle chiavi.

Il calendario di ICANN fissava all’11 ottobre 2026 l’inizio della firma con la nuova chiave; il ritiro della chiave precedente era invece previsto in una fase successiva, attesa per gennaio 2027. Al 9 novembre 2026, quindi, l’evento principale è già avvenuto, ma il ciclo di manutenzione della chiave non è concluso. Le conseguenze pratiche riguardano soprattutto i sistemi che effettuano la validazione DNSSEC con configurazioni obsolete o gestite manualmente.

Il DNS organizza i nomi di dominio in una gerarchia. Al vertice si trova la zona radice, che pubblica i riferimenti ai domini di primo livello — per esempio .com, .org e le estensioni nazionali — e ai server che ne sono responsabili. Un root server non conserva l’indirizzo IP di ogni sito web: indirizza il resolver al livello successivo della ricerca.

Quando un resolver ricorsivo non trova una risposta nella propria cache, può interrogare una delle identità radice. La risposta lo indirizza al server del TLD pertinente; il resolver prosegue quindi verso i server autoritativi del dominio. Se l’informazione è già nella cache, la richiesta può essere risolta senza raggiungere la radice: quest’ultima, perciò, non interviene a ogni visita a una pagina web.

È inoltre importante distinguere le 13 identità radice denominate, dalla A alla M, dalle macchine fisiche che le servono. Il sistema è distribuito tra numerose istanze e operatori indipendenti; ICANN descrive 13 identità gestite da 12 operatori e oltre 1.500 singoli server. La ridondanza e l’instradamento anycast consentono di gestire le richieste da più località, ma non trasformano ogni istanza in un operatore distinto né eliminano il coordinamento della zona radice.

DNSSEC aggiunge firme crittografiche affinché un resolver validante possa controllare l’autenticità e l’integrità dei dati DNS. La KSK radice convalida il DNSKEY set della zona radice; nella catena che verifica i riferimenti ai domini di primo livello vengono utilizzate anche altre chiavi della zona. La nuova chiave non modifica la struttura dei domini né i record dei siti: rinnova il punto di partenza crittografico della verifica.

KSK-2024 è stata pubblicata nella zona radice l’11 gennaio 2025, con un anticipo sufficiente perché i resolver compatibili con l’aggiornamento automatico delle trust anchor potessero apprenderla. L’11 ottobre 2026 ha iniziato a firmare la zona radice. La precedente KSK-2017 non va confusa con la nuova: l’avvio della firma e la rimozione definitiva di una chiave sono fasi distinte.

Questa sostituzione non è una migrazione a un algoritmo crittografico diverso. ICANN e Cloudflare descrivono KSK-2017 e KSK-2024 come chiavi che utilizzano RSA/SHA-256. Il rollover attuale verifica e rinnova quindi la distribuzione della fiducia, ma non significa che la radice sia passata alla crittografia post-quantistica. Un cambiamento di algoritmo richiederebbe ulteriore compatibilità nei resolver e sarebbe un processo separato.

La maggior parte delle persone non deve intervenire sul telefono, sul computer o sul router. Chi utilizza resolver gestiti dal proprio provider Internet o da un servizio DNS pubblico dipende da quegli operatori per mantenere aggiornati software e trust anchor. Non è necessario cambiare server DNS solo perché è stata rinnovata la KSK.

Il lavoro ricade soprattutto sugli amministratori di resolver ricorsivi che convalidano DNSSEC, in particolare quando mantengono trust anchor manuali, eseguono software datato o gestiscono apparecchiature rimaste offline a lungo. Se il resolver non si fida di KSK-2024, può rifiutare la validazione di risposte firmate correttamente. Per chi dipende da quel resolver, un possibile sintomo è che alcuni nomi non vengano risolti anche se i siti e i loro server funzionano.

Una risposta SERVFAIL, da sola, non dimostra che manchi la nuova chiave: lo stesso risultato può dipendere da altri problemi di configurazione o validazione. La verifica pertinente riguarda lo stato di fiducia effettivamente usato dal resolver, non soltanto la presenza della chiave in una risposta DNS. ICANN identifica KSK-2024 con il key tag 38696. Gli amministratori devono confrontarlo con le procedure e i file delle trust anchor del proprio software e non rimuovere manualmente la vecchia chiave al di fuori del calendario ufficiale.

Il rinnovo della KSK riguarda la validazione crittografica di DNSSEC. La latenza di una richiesta dipende, tra gli altri fattori, dalla posizione del resolver, dai percorsi Internet e dalla presenza della risposta nella cache; il rollover, da solo, non consente di concludere che la latenza migliorerà in generale.

La funzione di sicurezza di DNSSEC è aiutare a rilevare risposte DNS non autentiche o alterate, non cifrare da solo le richieste né nascondere il nome cercato. Cambiare la chiave mantiene la possibilità di convalidare la zona radice con una chiave rinnovata, ma non sostituisce altre misure di sicurezza, come la manutenzione del resolver, la protezione dei suoi sistemi o la cifratura del trasporto DNS quando opportuno.

Il processo mette anche alla prova il coordinamento tra la pubblicazione di una nuova chiave, la sua adozione da parte dei resolver e il ritiro di quella precedente. Il primo rollover della KSK radice è avvenuto nel 2018; la transizione attuale è la seconda. La continuità dipende dalla presenza di una trust anchor valida nei sistemi validanti, mentre l’architettura distribuita e le cache rafforzano altri passaggi della risoluzione. Sono meccanismi complementari, non intercambiabili.

Se amministri un resolver con validazione DNSSEC, è utile verificare che la configurazione si fidi di KSK-2024 (key tag 38696) e che il meccanismo di aggiornamento delle trust anchor funzioni. Consulta la documentazione della versione software installata e lo stato persistente del servizio: la presenza della chiave nella zona pubblica non garantisce che il software l’abbia integrata come trust anchor.

Per i dispositivi che usano resolver di terze parti, in caso di errori di risoluzione persistenti è ragionevole controllare lo stato del servizio o gli avvisi del provider. Non modificare i record di un dominio né disattivare DNSSEC come prima risposta a SERVFAIL senza aver individuato il punto in cui fallisce la validazione. Il problema può riguardare il resolver, una zona specifica o un’altra parte della catena.

La prossima tappa del calendario di ICANN è il ritiro di KSK-2017, previsto per gennaio 2027. Fino ad allora, amministratori e provider dovrebbero seguire le istruzioni ufficiali e mantenere i consueti aggiornamenti di sicurezza. Per gli utenti finali il messaggio è più semplice: non occorre riconfigurare la connessione per questo rollover; il cambiamento va gestito nell’infrastruttura che convalida le richieste.