La prossima rotazione della chiave root DNS è in corso e l'adozione della nuova chiave è pericolosamente bassa

Le chiavi crittografiche non sono mai destinate a durare per sempre. Rompere una chiave privata non è matematicamente impossibile; è computazionalmente irrealizzabile, il che significa che un attaccante avrebbe bisogno di un'enorme quantità di potenza di calcolo e tempo. Se una chiave viene usata per molti anni, un attaccante ha quegli stessi anni per continuare a provare. Ecco perché la durata delle chiavi, le scelte degli algoritmi e le dimensioni delle chiavi devono essere regolarmente rivalutate rispetto alla crescita della potenza di calcolo, inclusa la possibile comparsa di computer quantistici crittograficamente rilevanti. Per i segreti che devono rimanere protetti per 20 anni, potrebbero essere necessari algoritmi post-quantistici; per i segreti con una durata di cinque anni, i computer quantistici di produzione sono meno preoccupanti a breve termine. Nel Domain Name System Security Extensions (DNSSEC), che aggiunge firme digitali alle query DNS così gli utenti possono fidarsi delle risposte, la maggior parte delle chiavi ha una durata breve, da pochi mesi a un anno o due, quindi non necessitano ancora di protezione post-quantistica.

Ma la rotazione regolare delle chiavi è comunque essenziale. Tutte le chiavi crittografiche usate in DNSSEC dovrebbero essere sostituite periodicamente, sia per limitare l'esposizione sia per dare agli operatori pratica con il processo di rotazione. Non esiste un intervallo corretto unico: ruotare ogni settimana è troppo breve, mentre lasciare una chiave in posizione per venticinque anni è poco saggio. Una buona pratica operativa è introdurre una nuova chiave nel record DNSKEY della zona, che contiene le chiavi pubbliche per quella zona DNS, e lasciarla lì per almeno una durata di cache DNS prima di passare alla nuova. In alternativa, una zona può usare una nuova chiave immediatamente pubblicando più record RRSIG (firme digitali) così che ogni record DNS sia firmato sia dalla vecchia che dalla nuova chiave; tuttavia, bisogna fare attenzione che le risposte DNS non crescano oltre la soglia di frammentazione dei pacchetti UDP di 1.210 byte, perché risposte più grandi possono essere scartate da alcune reti. I resolver ricorsivi a volte applicano le proprie durate di cache piuttosto che le indicazioni della zona, quindi un periodo di introduzione conservativo prima di eliminare la vecchia chiave è saggio. Le pratiche operative dettagliate sono descritte in RFC 6781 e RFC 7583.

L'unica eccezione importante è la chiave root del DNS, chiamata Root Key Signing Key (KSK). Questa chiave firma la zona root del sistema di denominazione di Internet, e ogni resolver con validazione DNSSEC deve avere una copia della sua chiave pubblica come trust anchor. La prima KSK root è servita per otto anni; il suo successore, KSK-2017, è ora in servizio da poco meno di otto anni a maggio 2026. La lunga durata non è una scelta ma una necessità: non c'è un modo conveniente per introdurre un nuovo valore KSK e farlo incorporare rapidamente nei set di trust anchor di tutti i resolver validanti. Invece, IANA, che amministra la zona root, pubblica una chiave in arrivo molto prima che venga usata, la firma con la chiave corrente (un processo noto come 'vecchio firma nuovo'), e attende un periodo prolungato affinché i resolver la adottino. L'obiettivo dichiarato per la durata della KSK root è nominalmente di cinque anni, ma l'esperienza pratica l'ha esteso; la prima rotazione è stata eseguita l'11 ottobre 2018. Se tali durate estese rimangono pratica comune per IANA, la necessità di passare a algoritmi e chiavi post-quantistici significativamente più grandi arriverà prima. La prossima rotazione è in corso: la chiave in arrivo, KSK-2024, è stata pubblicata sul sito IANA a luglio 2024 e aggiunta al record DNSKEY della zona root a gennaio 2025. IANA prevede di usare KSK-2024 per generare la firma digitale della zona root a ottobre 2026, sostituendo KSK-2017.

Per monitorare se i resolver hanno adottato la nuova chiave, i ricercatori usano due diverse tecniche di misurazione. La prima, descritta in RFC 8145, chiede ai resolver di segnalare quali chiavi fidano quando inviano query ai root server. Un resolver può incorporare i tag delle chiavi in un nome di query speciale, come _ta-4f66-9728, il che significa che si fida delle chiavi con tag 20326 e 38696, oppure può includere i tag in un'opzione EDNS. RFC 5011 specifica un tempo di attesa aggiuntivo di 30 giorni o il TTL originale del primo RRSet DNSKEY del trust point, a seconda di quale sia maggiore, così che un resolver deve vedere almeno due record validati contenenti la nuova chiave prima di accettarla. Verisign ha analizzato questi segnali e ha riportato a marzo 2025 che tutti i resolver che segnalavano si fidavano ancora di KSK-2017, il che era previsto fino a quando quella chiave non verrà revocata all'inizio del 2027. Circa lo 0,5% dei resolver si fidava ancora di KSK-2010, anche se era stata revocata nel 2019, probabilmente a causa di aggiornamenti del sistema operativo obsoleti. Una piccola popolazione ha iniziato a fidarsi di KSK-2024 a luglio 2024, subito dopo la pubblicazione della chiave nel file trust anchor IANA. Il salto più grande è avvenuto 30 giorni dopo l'aggiunta della chiave al record DNSKEY della zona root, che corrisponde ai tempi di aggiornamento automatico definiti in RFC 5011. Un piccolo aumento durante quel primo mese probabilmente proveniva da resolver configurati manualmente. Tuttavia, questi dati contano solo i resolver che segnalano, non il numero di utenti dietro ogni resolver, e mancano i resolver che non supportano affatto il meccanismo di segnalazione.

Per ottenere una visione incentrata sull'utente, APNIC usa un metodo diverso descritto in RFC 8509, il Root Key Trust Anchor Sentinel. Invece di chiedere ai resolver di segnalare ai root server, questo approccio inserisce un'etichetta speciale all'estrema sinistra nel nome della query DNS. Il resolver riconosce l'etichetta e restituisce una risposta in base al fatto che si fidi di una particolare chiave. Ad esempio, una query a root-key-sentinel-is-ta-20326 restituisce la risposta normale se il resolver si fida di quella chiave, e SERVFAIL (un errore DNS) se non si fida. L'etichetta inversa root-key-sentinel-not-ta-20326 restituisce SERVFAIL se la chiave è considerata affidabile, e la risposta normale se non lo è. Il sistema di misurazione basato su annunci di APNIC invia queste query a una raccolta di utenti finali ogni giorno. Il test usa tre etichette: not-ta-20326 e is-ta-20326 verificano prima che il resolver esegua la validazione DNSSEC e supporti il meccanismo sentinel; la terza, is-ta-38696, controlla se il resolver ha caricato KSK-2024 nel suo set di trust anchor. Solo i campioni in cui i primi due test restituiscono le risposte attese vengono contati come 'utenti che segnalano'.

I risultati sono sorprendenti. Sebbene i dati a livello di resolver RFC 8145 suggerissero che i resolver che segnalavano avevano adottato KSK-2024 a marzo 2025, la misurazione a livello utente RFC 8509 racconta una storia diversa. Ad aprile 2026, 13 mesi dopo la fine del timer di introduzione di 30 giorni per KSK-2024, meno del 20% degli utenti dietro resolver con validazione DNSSEC aveva aggiunto KSK-2024 al proprio set di trust anchor locale. Ciò significa che se la rotazione della KSK root avvenisse immediatamente, la stragrande maggioranza degli utenti su resolver validanti vedrebbe improvvisamente fallimenti di validazione DNSSEC e non riuscirebbe a raggiungere molti siti web. La discrepanza potrebbe derivare dal fatto che molti resolver che validano DNSSEC non supportano il meccanismo sentinel, o perché la popolazione dei resolver è diversa dalla popolazione degli utenti. La misurazione ha limitazioni: il test basato su annunci usa due URL, e un resolver validante che supporta il sentinel restituisce una risposta firmata DNSSEC per l'etichetta is-ta, ma non tutti i resolver lo fanno. I conteggi giornalieri dei segnali di validazione DNSSEC e sentinel mostrano anche che solo un sottoinsieme degli utenti testati è dietro resolver validanti.

La lenta adozione di KSK-2024 evidenzia un divario operativo persistente: gli operatori di resolver devono assicurarsi che il loro software sia aggiornato e che i loro file trust anchor includano la nuova chiave, ma molti non lo hanno fatto. Gli utenti finali e i proprietari di siti web possono adottare misure per proteggersi. Per gli utenti Internet di tutti i giorni, scegliere un resolver DNS crittografato che rispetti la privacy come AEU DNS, che valida le firme DNSSEC e non registra le query, può aiutare a garantire che le proprie query rimangano autenticate e private anche mentre la transizione globale della chiave root è incompleta. Per gli operatori di resolver, seguire RFC 5011 e mantenere il software aggiornato è fondamentale ben prima di ottobre 2026.