Il DNSSEC root key rollover riesce nonostante le difficoltà locali
Le misurazioni del DNSSEC root key rollover non hanno rilevato gravi interruzioni globali, sebbene la validazione sia diminuita nettamente in alcune reti ed economie.
Il DNSSEC root key rollover si è concluso senza una grave interruzione globale, secondo le misurazioni comunicate da APNIC dopo il cambiamento dell'11 ottobre 2026. Le DNS Security Extensions (DNSSEC) consentono a un resolver di verificare che le risposte DNS siano autentiche e non siano state alterate. La rete di misurazione di APNIC basata su annunci pubblicitari ha rilevato che la quota mondiale degli utenti misurati che si affidavano esclusivamente a resolver con validazione DNSSEC è aumentata dal 39,7% prima del rollover al 40,6% dopo il rollover.
Il cambiamento è iniziato alle 14:00 UTC dell'11 ottobre. Ha sostituito la root Key Signing Key (KSK), una credenziale crittografica utilizzata per verificare i record firmati della DNS root. La root zone si trova al livello più alto del Domain Name System e indirizza i resolver verso i server responsabili dei domini sottostanti. Un resolver è il servizio che cerca l'indirizzo internet associato a un nome di dominio.
Prima del cambiamento, i resolver che eseguivano la validazione dovevano considerare attendibile la KSK in uscita. Dopo aver aggiornato il DNSKEY resource record memorizzato localmente nella cache, che contiene le informazioni pubbliche utilizzate per la verifica DNSSEC, dovevano considerare attendibile la key in entrata. I record memorizzati nella cache potevano rimanere validi per due giorni, quindi il periodo di transizione è proseguito fino alle 14:00 UTC del 13 ottobre. Un resolver che non avesse accettato la nuova key poteva non superare i controlli DNSSEC, facendo potenzialmente apparire indisponibili ai propri utenti domini correttamente firmati.
APNIC ha esaminato i dati dei primi 16 giorni di ottobre. Durante il rollover, il numero giornaliero di misurazioni è rimasto entro il normale intervallo di variazione. Sebbene il risultato globale sia stato positivo, le medie nazionali hanno evidenziato esiti contrastanti in Brasile e India, dove molti utenti si affidano a recursive resolver con validazione DNSSEC forniti dagli internet service provider. Un recursive resolver esegue la sequenza di ricerche DNS necessaria per ottenere una risposta per un utente.
APNIC ha contattato un importante ISP indiano il 9 ottobre, dopo che il segnale KSK Sentinel aveva indicato che i suoi resolver non avevano stabilito localmente la fiducia nella key in entrata e che probabilmente avrebbero smesso di funzionare dopo il rollover. KSK Sentinel è un meccanismo di misurazione utilizzato per determinare se un resolver considera attendibile una determinata root key. L'ISP è intervenuto prima del cambiamento e il tasso misurato di validazione DNSSEC tra gli utenti indiani è salito dal 55% al 59%. APNIC non è riuscita a contattare gli ISP brasiliani che mostravano lo stesso avviso in quel periodo e il tasso misurato del Brasile è sceso dal 54% al 50%.
Misurazioni precedenti avevano individuato le 50 reti con i tassi di accettazione più bassi per KSK-2024. Ciascuna aveva prodotto almeno 1.000 test che indicavano il supporto per KSK Sentinel, mentre meno della metà delle sue misurazioni accettava la key in entrata. I dati di verifica raccolti fino al 18 ottobre hanno prodotto un risultato inaspettato: nessuna di quelle reti è rimasta indietro. Tutte e 50 hanno aggiunto KSK-2024 ai propri set di key attendibili tra il 7 e il 13 ottobre e ciascuna ha successivamente registrato un tasso di accettazione superiore al 50%.
APNIC ha inoltre confrontato il tasso di validazione di ogni rete dopo il rollover con la sua media nei primi 10 giorni di ottobre. Il dataset comprendeva 13.538 reti con una media di almeno 20 campioni giornalieri sia nel periodo precedente sia in quello successivo. La validazione è aumentata di oltre il 50% in 35 reti. APNIC ha dichiarato che una spiegazione probabile era che i loro resolver considerassero attendibile la key in entrata, ma non la key allora in uso. In totale, 594 reti hanno registrato un aumento di almeno il 10%. Nella direzione opposta, 58 reti hanno perso almeno il 50% del proprio tasso di validazione, mentre 660 hanno registrato un calo di almeno il 10%.
Il numero stimato di utenti dietro resolver con validazione DNSSEC è aumentato da 1.654.477.399 prima del rollover a 1.700.275.794 dopo il rollover, su una popolazione totale stimata di 4.308.517.174 utenti. APNIC ha descritto questo dato come un aumento netto di 45,8 milioni di utenti con validazione.
L'India ha registrato il maggiore aumento stimato, passando da 321.679.249 a 367.102.609 utenti con validazione DNSSEC, con un incremento di 45.423.360 su una popolazione totale di 655.274.727 utenti. Gli altri aumenti stimati sono stati: Vietnam, 9.157.450; Algeria, 3.266.261; Marocco, 2.360.854; Kazakistan, 950.982; Slovacchia, 664.669; Iran, 558.706; Thailandia, 282.420; Sri Lanka, 263.373; e Lituania, 208.987. Le rispettive popolazioni con validazione dopo il rollover erano pari a 32.490.227, 10.692.147, 26.111.432, 7.417.541, 1.767.006, 16.548.704, 29.149.702, 1.870.630 e 838.531 utenti.
Il Brasile ha registrato il maggiore calo stimato, passando da 80.503.978 a 72.723.712 utenti con validazione, con una perdita di 7.780.266 su una popolazione totale di 162.001.400 utenti. Gli altri maggiori cali stimati sono stati: Federazione Russa, 3.078.946; Cina, 1.756.584; Stati Uniti, 906.565; Bulgaria, 760.869; Bangladesh, 610.974; Giappone, 609.093; Uganda, 329.937; Pakistan, 312.472; ed Egitto, 300.999. Le rispettive popolazioni con validazione dopo il rollover erano pari a 17.668.816, 4.955.581, 98.812.775, 1.002.739, 30.315.215, 15.785.216, 8.834.481, 37.347.439 e 47.290.182 utenti.
Questi dati non significano che ogni transizione locale sia avvenuta senza problemi. Il DNS è altamente distribuito e coordinato solo in modo limitato, quindi il comportamento dei resolver varia naturalmente tra le diverse reti. APNIC ha comunque concluso che il rollover di ottobre 2026 ha avuto successo se valutato su scala internet. Le sue misurazioni mostrano entrambi gli aspetti del risultato: nessuna grave interruzione mondiale, ma perdite significative in alcune reti ed economie che non sono riuscite a mantenere la validazione ai livelli precedenti.
Per i lettori che scelgono un'alternativa al resolver predefinito del proprio ISP, AEU DNS offre un DNS privato e sicuro per tutti. L'autenticità DNSSEC e la privacy DNS sono aspetti correlati ma distinti, quindi gli utenti e i team IT dovrebbero verificare che cosa supporta il resolver scelto e come mantiene le proprie informazioni di fiducia relative alla root.
Termini spiegati
- DNSSEC
- Le DNS Security Extensions consentono a un servizio DNS di verificare che una risposta sia autentica e non sia stata modificata.
- Key Signing Key
- Una Key Signing Key è un'informazione crittografica utilizzata per verificare i record DNS firmati a uno specifico livello del DNS.
- root zone
- La root zone è il livello più alto del DNS e indirizza le ricerche verso i sistemi responsabili delle singole estensioni di dominio.
- resolver
- Un resolver è il servizio che trova l'indirizzo internet collegato a un nome di dominio.
- DNSKEY resource record
- Un DNSKEY resource record pubblica le informazioni pubbliche utilizzate da un resolver per controllare una firma DNSSEC.
- KSK Sentinel
- KSK Sentinel è un metodo di misurazione usato per controllare se un DNS resolver considera attendibile una determinata root key.
- recursive resolver
- Un recursive resolver segue la catena necessaria di ricerche DNS e restituisce all'utente la risposta finale.
Come proteggerti
- Esegui un test DNSSEC online affidabile e controlla che segnali una validazione riuscita per la tua attuale connessione internet.
- Mantieni abilitati gli aggiornamenti automatici del router, in modo che il suo software relativo al DNS non rimanga inutilmente obsoleto.
- Se molti siti web digitati correttamente smettono improvvisamente di caricarsi, prova un'altra rete affidabile e segnala la differenza al tuo provider internet.
- Se la tua organizzazione gestisce un proprio servizio DNS, chiedi all'amministratore di confermare che il record attendibile per la verifica della root si aggiorni automaticamente.
- Prima di un'interruzione, documenta un provider DNS di riserva approvato, così da non dover scegliere un servizio sconosciuto sotto pressione.
