Il rollover della chiave root DNSSEC previsto per l'11 ottobre 2026

DNSSEC è il sistema di firme digitali che consente a un computer di verificare se una risposta ricevuta dal Domain Name System è autentica, e una delle sue chiavi più importanti sta per essere sostituita. Quel cambiamento è stato uno dei quattro argomenti discussi all'APNIC 62, la conferenza dell'Asia Pacific Network Information Centre, tenutasi a Mumbai, in India, dal 4 al 10 settembre 2026, dove operatori di rete, ricercatori ed esperti di infrastrutture internet si sono incontrati per confrontare esperienze operative e sfide in corso. Il resoconto APNIC della Sessione Tecnica 1, Operazioni Internet, è stato pubblicato da George Michaelson il 21 settembre 2026.

Marcin Siodelski, ingegnere software senior presso l'Internet Systems Consortium (ISC), ha presentato Stork, un nuovo strumento di gestione. I software DHCP e BIND di ISC sono stati centrali nell'erogazione dei servizi internet per decenni, e sebbene oggi l'organizzazione sia forse più nota per la gestione del servizio DNS globale F-root, lo sviluppo software rimane una parte fondamentale della sua missione. BIND 9 continua ad alimentare i servizi DNS in tutto il mondo sia come server autoritativo (la macchina che detiene i record ufficiali di un dominio) sia come resolver ricorsivo (la macchina che cerca le risposte per conto dell'utente). Kea DHCP sostituisce il vecchio server ISC DHCP, giunto a fine vita. Poiché gli ambienti DHCP, i sistemi che assegnano automaticamente gli indirizzi di rete, possono essere complessi, Stork viene presentato come un passo avanti significativo: una piattaforma di gestione grafica che si integra con BIND 9 e PowerDNS, e anche con Prometheus e Grafana per monitoraggio, reportistica, dashboard e un'interfaccia di gestione web.

DHCP rimane una parte fondamentale dell'erogazione dei servizi di rete. Gestisce pool di indirizzi IP, alloca sottoreti e mantiene assegnazioni statiche di indirizzi e prefissi per macchine specifiche identificate da indirizzi MAC (l'identificatore hardware integrato in una scheda di rete) o da identificatori client. Tramite Kea, gli operatori possono gestire configurazioni ad alta disponibilità, sistemi di failover, tracciamento dei lease e ispezione dei log, e Marcin ha dimostrato integrazioni Grafana, interfacce di gestione delle sottoreti e strumenti di configurazione. La gestione DNS è un'aggiunta relativamente recente a Stork, e la sua integrazione con BIND 9 consente agli operatori di gestire, monitorare e produrre report su ambienti DNS complessi attraverso un'unica interfaccia, offrendo visibilità su grandi distribuzioni di server e aiutando a collegare i team operativi e l'infrastruttura DNS. Le capacità attuali si concentrano su monitoraggio, viste di configurazione, esplorazione delle zone e monitoraggio dei trasferimenti di zona, inclusa la rilevazione di discrepanze nei numeri di serie tra server, che segnalano che due copie della stessa zona si sono allontanate. L'integrazione con PowerDNS rimane sperimentale e mira a fornire un'esperienza di gestione unificata su distribuzioni miste. Sono previste ulteriori funzionalità, tra cui il rilevamento e la rimozione di record DNS obsoleti in ambienti DNS dinamici, che si allinea strettamente con la gestione dei pool DHCP, oltre a clonazione e validazione delle zone, modifica della configurazione di BIND 9, supporto alle zone catalogo DNS e monitoraggio avanzato dei log di BIND 9. Tali funzionalità dovrebbero essere rilasciate nel corso del 2026 e del 2027.

Champika Wijayatunga, Technical Engagement Director di ICANN per l'Asia Pacifico, ha spiegato il prossimo rollover della Key-Signing Key (KSK) root di DNSSEC, previsto per l'11 ottobre 2026. Ha illustrato la catena di fiducia DNSSEC, che si basa sul Trust Anchor della zona root. Un trust anchor si trova in cima alla gerarchia e non può essere validato rispetto a un'altra chiave: i sistemi devono essere configurati per considerarlo un punto di partenza fidato, un assioma. La chiave oggetto del rollover è la metà pubblica di una coppia di chiavi pubblica e privata; la chiave privata rimane offline all'interno di moduli di sicurezza hardware gestiti da ICANN in strutture sicure sulle coste est e ovest degli Stati Uniti. Le chiavi private producono le firme crittografiche sui dati DNS, mentre le chiavi pubbliche pubblicate consentono ai resolver di verificare l'autenticità, l'integrità e la completezza di quei dati. I rollover periodici sono considerati una buona pratica operativa: riducono i rischi di sicurezza a lungo termine e consentono di introdurre algoritmi e lunghezze di chiave più robusti man mano che la tecnologia evolve, il che è importante per minacce emergenti come il calcolo quantistico che potrebbe accorciare la vita utile effettiva delle coppie di chiavi RSA. ICANN conduce la gestione delle chiavi attraverso cerimonie pubbliche delle chiavi in entrambe le strutture, con la partecipazione di Trusted Community Representatives, e le cerimonie sono trasmesse in diretta streaming. In circostanze normali il materiale chiave verrebbe rinnovato ogni tre o quattro anni, sebbene questo rollover sia stato ritardato. Gli operatori che eseguono la validazione DNSSEC devono assicurarsi che i loro sistemi resolver mantengano aggiornati i trust anchor: molti sistemi si aggiornano automaticamente tramite RFC 5011, ma alcune distribuzioni richiedono un intervento manuale, e Wijayatunga ha sottolineato l'importanza di verificare come si comportano i resolver durante e dopo il rollover. I trust anchor aggiornati sono disponibili presso IANA e possono essere validati indipendentemente dagli aggiornamenti RFC 5011.

Geoff Huston, Chief Scientist di APNIC, ha esaminato le sfide in corso della gestione dei certificati X.509, il sistema che sostiene i meccanismi di autenticazione e privacy utilizzati da HTTPS e TLS. Un certificato è l'attestazione di identità di una terza parte: l'autorità di certificazione emittente è un'organizzazione privata che crea credenziali crittografiche basate su informazioni fornite dai richiedenti, e non è necessariamente l'autorità che ha rilasciato un nome aziendale, un nome di dominio o qualsiasi altra forma di identità. Prendendo come esempio un sito bancario non autorizzato, Huston ha posto una domanda semplice: la revoca dei certificati impedisce davvero alle persone di usare un sito compromesso? Esaminando www.westpac.com.au, ha mostrato che il dominio risolve su infrastrutture ospitate da Amazon anziché su infrastrutture gestite direttamente da Westpac, e che il sito utilizza un certificato rilasciato da DigiCert più di nove mesi prima. In un periodo simile potrebbero verificarsi una serie di fallimenti di sicurezza, tra cui la compromissione dell'autorità di certificazione, il furto di una chiave o un errore operativo, e la parte difficile è come invalidare un certificato quando si verifica uno di questi eventi.

Il meccanismo tradizionale è la Certificate Revocation List (CRL) X.509, che pubblica i numeri di serie dei certificati che non dovrebbero più essere considerati affidabili; in linea di principio un browser scarica la lista, ne valida la firma e controlla se il certificato che ha davanti vi compare. Huston ha mostrato un esempio di lista aggiornata settimanalmente che conteneva 17.527 certificati revocati. In pratica il processo è fin troppo lento per supportare la validazione ordinaria del browser: è tecnicamente valido ma raramente usato come originariamente previsto. L'Online Certificate Status Protocol (OCSP), definito nell'RFC 2560, offriva un'alternativa attraverso query di stato in tempo reale, ma crea problemi di privacy rivelando l'attività di navigazione e introduce potenziali rischi di denial-of-service attraverso ricerche centralizzate, e la sua distribuzione rimane incompleta e incoerente. HTTPS e TLS supportano anche l'OCSP stapling, in cui un server fornisce una risposta OCSP firmata durante l'handshake TLS; ciò migliora la privacy e riduce la latenza, eppure un server compromesso difficilmente fornirà la prova che il proprio certificato è stato revocato, il che limita l'efficacia del meccanismo. Il supporto dei browser varia considerevolmente. Let's Encrypt, ormai la più grande autorità di certificazione al mondo, ha dismesso i suoi servizi OCSP nel 2025 dopo aver gestito più di 140.000 richieste al secondo attraverso Akamai, e il supporto per Must Staple è praticamente scomparso nello stesso periodo. Chrome ha smesso di fare affidamento su OCSP nel 2014 e non ha mai adottato lo stapling come meccanismo di validazione primario, mentre Safari segue un approccio diverso.

Huston ha testato l'emissione e la revoca dei certificati utilizzando Let's Encrypt all'interno di un ciclo di pubblicazione CRL di sette giorni. Il certificato revocato è effettivamente comparso nella lista, ma Chrome e Safari non hanno riconosciuto la revoca. Firefox sì. Data la quota di mercato detenuta da Chrome e Safari, la revoca dei certificati rimane in gran parte inefficace nella pratica. Una risposta è stata quella di accorciare la durata dei certificati: Let's Encrypt ha ridotto la validità dei certificati da 90 giorni a 45 giorni, e alcune autorità di certificazione ora emettono certificati validi per appena sei giorni. Huston ha sostenuto che anche questo è insufficiente, perché gli incidenti di sicurezza si verificano in millisecondi mentre la durata dei certificati è ancora misurata in giorni. Come alternativa ha proposto di utilizzare il DNS e i suoi meccanismi di scadenza della cache integrati. DANE (DNS-based Authentication of Named Entities), combinato con DNSSEC, consente di pubblicare materiale chiave con durate molto più brevi, ed esiste anche un modello DANE con stapling che fornisce funzionalità simili ai certificati X.509 e all'OCSP stapling. Ha concluso che ottenere credenziali web veramente di breve durata potrebbe richiedere un allontanamento dall'ecosistema X.509 verso modelli di fiducia basati su DNSSEC, e che la sfida sta nel passare da un'infrastruttura progettata attorno a durate dei certificati misurate in giorni a una in grado di rispondere alle minacce quasi immediatamente.

Ritesh Mukherjee, leader di product management per NOS e AI presso Nokia, ha discusso la fase successiva della sicurezza per BGP, il protocollo con cui le reti si comunicano reciprocamente quali indirizzi possono raggiungere. Route Origin Validation (ROV) verifica se una rete è autorizzata a originare una rotta, mentre Autonomous System Provider Authorization (ASPA) aiuta a validare l'integrità del percorso AS, l'elenco delle reti attraversate da una rotta. Ha presentato diversi esempi di incidenti di routing.

Uno riguardava Reliance (AS18101) che blackholava i prefissi di Telegram. Il sistema RIPE RIS ha rapidamente rilevato l'evento come falsa originazione di rotta, e Telegram ha risposto annunciando prefissi più specifici, che AS18101 ha anche propagato; poiché quegli annunci si estendevano oltre l'India, le reti estere hanno selezionato quelli che sembravano percorsi più brevi. L'incidente è diventato un BGP hijack perché i dati dell'Internet Routing Registry mostravano che AS18101 non era autorizzato a originare le rotte interessate, e ROV avrebbe rilevato il problema e impedito una propagazione più ampia. Eppure solo il 27% dei sistemi autonomi attualmente applica ROV, e l'adozione in India rimane particolarmente bassa. Un secondo esempio riguardava SingNet (AS3758): un annuncio di rotta da AS17894 è stato filtrato da AS37100, ma il traffico è stato comunque deviato attraverso Sparkle (AS6762), che ha propagato una rotta più specifica. Seacom aveva abilitato ROV, ma la sua dipendenza da Sparkle ha ridotto il beneficio, mostrando come una distribuzione parziale crei punti ciechi che consentono agli hijack di persistere in sezioni della default-free zone, il nucleo di internet che inoltra il traffico senza un percorso di riserva. Un terzo caso è stato una route leak da Vodafone Idea (AS55410), che ha annunciato migliaia di prefissi successivamente propagati da Bharti Airtel (AS9498), causando un'ampia deviazione del traffico verso AS55410. La bassa adozione di ROV, il filtraggio limitato dei percorsi e l'assenza di controlli sul numero massimo di prefissi hanno tutti contribuito alla portata di quell'incidente.

Questi esempi illustrano sfide di sicurezza del routing che hanno interessato le reti in tutta la regione Asia Pacifico per quasi due decenni. La diffusione di ROV nella regione rimane indietro rispetto ad altre regioni dei Regional Internet Registry, sebbene alcune economie, tra cui Vietnam, Indonesia e Filippine, abbiano raggiunto livelli di adozione più elevati; l'India ha raggiunto l'88% di copertura Route Origin Authorization, ma l'applicazione rimane limitata. Mukherjee ha proposto un modello di protezione in tre parti: BMP per il rilevamento delle anomalie, ASPA per la validazione dei percorsi e ROV con applicazione. Ha inoltre evidenziato RAVEN, il BGP Routing Security Monitor di Nokia, disponibile attraverso il repository GitHub di Nokia, che aiuta gli operatori a valutare la propria esposizione alla sicurezza del routing prima di applicare politiche di blocco. RAVEN funziona come singolo binario, riceve dati di routing via BMP e può integrarsi con validatori RPKI come Routinator; supporta anche dashboard Grafana, webhook, integrazione FlowSpec e audit da riga di comando. Distribuire BMP sull'Adj-RIB-In, la tabella delle rotte che un router ha ricevuto da un vicino prima che venga applicata la politica, fornisce visibilità sul comportamento del routing e può aiutare gli operatori a diventare vicini migliori. Ha fortemente sostenuto limiti massimi di prefissi sulle sessioni eBGP per evitare che le route leak sovraccarichino l'infrastruttura di routing, e ha incoraggiato la distribuzione a lungo termine di ASPA, di ROV con politiche di scarto e la partecipazione attiva a MANRS.

Per gli utenti quotidiani, i fili conduttori che attraversano la sessione tornano tutti alla fiducia: le chiavi che firmano le risposte DNS, i certificati che dovrebbero provare che un sito web è quello che dichiara di essere, e le informazioni di routing che decidono se il traffico raggiunge il posto giusto. La maggior parte dei router domestici e dei resolver dei provider gestirà automaticamente il cambio di chiave DNSSEC, ma chiunque gestisca un proprio resolver, o dipenda da qualcuno che lo fa, dovrebbe verificare dopo l'11 ottobre 2026 che la validazione funzioni ancora, perché un resolver che smette silenziosamente di validare ha perso una protezione che aveva prima. Per i lettori che preferiscono non dipendere affatto da un resolver del provider, AEU DNS è un servizio DNS privato e cifrato, e la sua documentazione pubblica descrive la validazione DNSSEC e l'approccio no-logs che offre, così chiunque può controllare i dettagli e decidere se fa al caso proprio.