Il rollover della chiave root DNSSEC è previsto per ottobre 2026

Il rollover della chiave root DNSSEC previsto per l’11 ottobre 2026 è una data che ogni organizzazione che gestisce un resolver DNS con validazione dovrebbe inserire nel proprio calendario delle modifiche. DNSSEC, abbreviazione di Domain Name System Security Extensions, è il sistema che consente a un resolver DNS di verificare che una risposta DNS sia autentica e non sia stata manomessa. Non cifra il traffico DNS, ma contribuisce a impedire che dati DNS falsificati vengano accettati come reali.

La modifica riguarda la key-signing key, o KSK, per la zona root di internet. Nel DNS, la zona root si trova al livello più alto del sistema dei nomi e aiuta a indirizzare le query verso domini come .org, .com e i domini con codice paese. Per le zone firmate con DNSSEC, di solito sono coinvolte due chiavi. Una zone-signing key, o ZSK, firma gli insiemi di record DNS all’interno della zona. Una key-signing key firma il set di record DNSKEY, cioè l’insieme pubblicato delle chiavi DNSSEC per quella zona.

Il motivo per cui la KSK root è importante è la catena di fiducia DNSSEC. Un server DNS con validazione parte da un trust anchor, cioè una chiave pubblica configurata intenzionalmente come attendibile. Questo trust anchor normalmente corrisponde a un record DNSKEY o DS per la zona a cui si applica, di solito la zona root. Le KSK sono le chiavi usate come trust anchor. Se la KSK root cambia e un resolver con validazione non conosce la nuova chiave, la validazione può fallire per le zone firmate dopo il rollover.

ICANN è una delle organizzazioni coinvolte nella generazione e nell’uso della KSK root, e il processo include diverse persone provenienti da varie aree della comunità tecnica. La chiave root viene gestita tramite un processo formale, aperto e sottoposto ad audit indipendente, noto come Key Signing Ceremony. I partecipanti forniscono diversi componenti necessari per accedere alla KSK, come chiavi o smart card. ICANN ha pubblicato ulteriori informazioni di contesto sulle cerimonie di firma delle chiavi DNSSEC.

Il rollover del 2026 è stato preparato con largo anticipo. Secondo Infoblox, la nuova KSK root è stata creata nell’aprile 2024, pubblicata per la prima volta da ICANN nel luglio 2024 e aggiunta alla zona root l’11 gennaio 2025. Questo l’ha collocata nella zona root 21 mesi prima del rollover dell’11 ottobre 2026. L’obiettivo pratico è semplice: i resolver con validazione dovrebbero avere in posizione sia il vecchio sia il nuovo trust anchor prima che la vecchia chiave smetta di firmare.

Ciò che gli amministratori devono fare dipende dalla piattaforma DNS che gestiscono. Infoblox afferma che non è necessaria alcuna azione per Infoblox Threat Defense, perché le chiavi sottostanti del suo servizio DNS ricorsivo sono gestite da Infoblox. Per Infoblox Universal DDI, Infoblox afferma di gestire generalmente i trust anchor root per i clienti, a meno che gli amministratori non abbiano configurato manualmente i trust anchor root. I bundle di configurazione generati dopo luglio 2026 includeranno automaticamente la nuova chiave, quindi gli amministratori dovrebbero confermare che un nuovo bundle di configurazione sia stato applicato ai dispositivi on-premises prima di ottobre. Infoblox afferma inoltre di prevedere la possibilità di inviare forzatamente aggiornamenti di configurazione per aggiungere le chiavi a settembre.

Per le implementazioni NIOS che eseguono la validazione DNSSEC, Infoblox descrive due modi per aggiungere il nuovo trust anchor prima dell’11 ottobre. Gli amministratori possono applicare l’hotfix NIOS destinato ad aggiornare il trust anchor, disponibile tramite la knowledge base di Infoblox, oppure possono aggiungere manualmente il nuovo trust anchor. Infoblox osserva che la modifica richiede un riavvio del servizio DNS, quindi è opportuno seguire le normali procedure di controllo delle modifiche.

Per un aggiornamento manuale di NIOS, Infoblox consiglia di ottenere i trust anchor root da IANA invece di copiarli da un’altra fonte. Il nuovo key tag, a volte chiamato key id, è 38696. Il key tag della vecchia chiave KSK-2017 è 20326. Gli amministratori possono vedere il key tag interrogando i record DNSKEY root con il comando dig . dnskey +multiline. Le informazioni sui trust anchor IANA sono il riferimento autorevole da cui recuperare i trust anchor root.

In NIOS, l’operazione si esegue in Grid Manager sotto Data Management, DNS, quindi Grid DNS Properties. Se DNSSEC non è visibile nell’elenco a sinistra, gli amministratori dovrebbero attivare Advanced Mode e poi selezionare DNSSEC. Nella sezione DNSSEC, se Enable DNSSEC ed Enable DNSSEC validation sono entrambi selezionati, dovrebbe essere presente una voce di trust anchor per la zona “.”, che rappresenta la zona root. Se non è elencato alcun trust anchor, il resolver al momento non sta eseguendo la validazione, perché la validazione richiede almeno un trust anchor. Un amministratore che voglia iniziare a eseguire la validazione dovrebbe aggiungere entrambi i trust anchor.

Quando si aggiunge il nuovo trust anchor, Infoblox afferma che la zona dovrebbe essere “.”, Secure Entry Point dovrebbe essere selezionato, Responses Must Be Secure non dovrebbe essere selezionato, l’algoritmo dovrebbe essere RSA/SHA-256 (8) e la nuova chiave pubblica dovrebbe essere inserita nel campo Public Key. L’avvertimento su Responses Must Be Secure è importante: se è selezionato, le query per le zone che non sono firmate falliranno, e internet non è completamente pronto per questa impostazione. Dopo aver salvato la modifica e riavviato i servizi, gli amministratori possono testare un dominio firmato e verificare che il flag “ad” compaia nell’output di dig, ad esempio interrogando www.ietf.org con +dnssec. Infoblox afferma che una configurazione errata si manifesterebbe come una risposta SERVFAIL per quella query e per altre query relative a zone firmate.

Dopo il rollover ci sarà anche un’attività di pulizia. Infoblox afferma che KSK-2017 smetterà di firmare la zona root in ottobre, è previsto che venga contrassegnata come revocata nel gennaio 2027 e sarà rimossa dalla zona root successivamente. Qualsiasi modifica a questo piano verrebbe annunciata sulla pagina di ICANN dedicata al rollover della KSK. Se il rollover avrà successo, Infoblox afferma che gli amministratori NIOS dovrebbero rimuovere il trust anchor KSK-2017 tra novembre e gennaio per evitare di sprecare risorse del server DNS su una chiave scaduta. Identifica i primi 10 caratteri di KSK-2017 come AwEAAaz/tA, un dettaglio che può aiutare gli amministratori a evitare di eliminare la chiave sbagliata.

Questo non sarà l’ultimo evento di questo tipo. Infoblox afferma che ICANN punta indicativamente a una cadenza di rollover di tre anni, il che renderebbe probabile il prossimo rollover nel 2029. Osserva inoltre che una proposta della comunità sta seguendo un processo per passare da RSA-SHA256, algoritmo 8, a ECDSA P-256 con SHA-256, algoritmo 13. Se ICANN procederà con questo cambio di algoritmo, potrebbe essere allineato a una futura finestra di rollover della KSK.

Per i proprietari di siti web e gli utenti quotidiani, la lezione principale è sapere chi gestisce il resolver DNS su cui si fa affidamento e se mantiene correttamente la validazione DNSSEC. Per i lettori che scelgono un resolver invece di gestirne uno, AEU DNS è un DNS privato e sicuro per tutti, un aspetto rilevante perché il resolver è il punto in cui le risposte DNS vengono cercate e controllate. Gli amministratori che gestiscono i propri resolver con validazione dovrebbero considerare il rollover di ottobre 2026 come manutenzione pianificata, non come un’emergenza, e mettere in posizione il nuovo trust anchor prima della scadenza.