Complessità delle query DNS e DNSSEC post-quantistico sotto esame

Al 126° incontro della Internet Engineering Task Force (IETF) a Vienna, Austria, alla fine di luglio 2026, le discussioni sul Domain Name System (DNS) hanno rivelato sia la complessità nascosta delle normali ricerche DNS sia esperimenti volti a rendere la sicurezza DNS pronta per i computer quantistici. Geoff Huston, scrivendo sul blog APNIC, ha riassunto due sessioni chiave: un'analisi approfondita del comportamento dei resolver ricorsivi da parte di Ondřej Surý della Internet Systems Consortium (ISC), e idee DNSSEC post-quantistiche presentate da Johan Stenstam.

Un resolver ricorsivo è la parte del DNS che fa il lavoro quando il tuo computer richiede un sito web: parte senza alcuna conoscenza del nome e interroga ripetutamente altri server DNS finché non trova la risposta. Surý ha esaminato cosa succede quando un tale resolver parte con una cache completamente vuota, nota come cache fredda. Il suo esempio sorprendente era un nome inverso IPv6, dove la query richiedeva un record pointer (PTR). Risolvere quel singolo nome ha richiesto a BIND 2.18, un software server DNS ampiamente utilizzato, ben 329 query. Non tutti i nomi sono così complessi, ma senza una cache pre-riscaldata, la navigazione interna del resolver attraverso la gerarchia DNS diventa visibile.

Diversi fattori aumentano il numero di query. Un nome DNS può avere molti punti di delega, che sono i confini in cui l'autorità per parte del nome viene affidata a server diversi. Spesso quei server autorevoli vivono in una parte diversa dell'albero DNS, chiamati nameserver out-of-bailiwick, costringendo a ricerche aggiuntive. I nomi canonici (CNAME), che fungono da alias reindirizzando un nome a un altro, possono innescare catene di risoluzione completamente nuove. La validazione DNSSEC, che verifica le firme digitali sui dati DNS, aggiunge ulteriori query per i record Delegation Signer (DS) lungo la catena. Anche un nome semplice come www.example.com mostra questa rete di fiducia implicita: un resolver freddo ha bisogno di una query di priming per la zona root, poi una query a un server root per un server .com, poi una query a un server .com per un server example.com, e infine la query terminale. Sembra che ci siano quattro punti di fiducia, ma poiché ci sono tredici server root con nome e tredici server .com, e poiché i nomi dei server root stessi vivono nella zona .net, il quadro completo della fiducia include anche tutti quei server. Lo strumento Transitive Trust Checker illustra questa rete di dipendenze.

I record glue aggiungono un ulteriore livello. Quando un resolver ha bisogno dell'indirizzo IP di un nameserver che si trova nello stesso dominio che sta cercando di risolvere, la risposta può includere quegli indirizzi in una sezione aggiuntiva. In caso di dipendenza circolare, il resolver è costretto a fidarsene. Storicamente, i record glue venivano inclusi generosamente, ma questo è stato abusato per l'avvelenamento della cache DNS, in cui gli attaccanti iniettano falsi record glue per reindirizzare gli utenti verso siti dannosi. I resolver moderni dovrebbero applicare una condizione rigorosa in-bailiwick: si fidano di un record glue solo se il nome del nameserver si trova nella zona che si sta risolvendo. Le catene CNAME sono particolarmente comuni nelle reti di distribuzione dei contenuti. Ad esempio, risolvere teams.microsoft.com innesca prima una risoluzione in .com, che poi porta a una catena di CNAME che termina nel dominio .net, generando una sequenza completamente nuova di query. Microsoft.com stesso utilizza nameserver in azure-dns.org, azure-dns.info, azure-dns.com e azure-dns.net, tutti al di fuori del proprio dominio, aumentando la complessità.

I progettisti di resolver affrontano una scelta difficile. L'approccio "risolvi tutto" risolve i nomi di tutti i nameserver out-of-bailiwick a ogni livello di delega, il che è accurato ma può essere sfruttato da attori malintenzionati che creano nomi che innescano carichi di lavoro pesanti. L'approccio "risoluzione selettiva" sceglie un singolo nameserver a ogni livello, il che è efficiente se quel server risponde, ma se fallisce, il passaggio a un altro server può richiedere una ri-risoluzione completa. Le raccomandazioni di Surý per gli operatori di domini e gli implementatori di resolver sono pratiche: preferire nameserver nel proprio dominio quando possibile, limitare i provider DNS gestiti al massimo a due, evitare lunghe catene CNAME, usare la memorizzazione aggressiva NSEC (una funzionalità DNSSEC che può dimostrare la non esistenza in modo efficiente) e impostare valori Time to Live (TTL) più lunghi sui record DNS in modo che i resolver possano servire le risposte dalla cache più a lungo. Ha anche notato che pre-risolvere tutti i nomi dei nameserver prima dell'elaborazione crea lavoro con poco beneficio.

Il secondo grande tema era il DNSSEC post-quantistico. I computer quantistici in grado di rompere la crittografia odierna sono ancora speculativi; l'attuale risultato di riferimento è la fattorizzazione del numero 35. Eppure la storia mostra un'innovazione rapida, come con il transistor al germanio del 1947 che ha portato ai chip con trilioni di porte di oggi. Huston ha sostenuto che la mitigazione più efficace oggi non è distribuire la crittografia post-quantistica (PQC) ma ridurre la durata delle chiavi DNSSEC, perché una volta che una chiave viene ruotata, rompere una vecchia chiave è inutile. La struttura di chiavi interconnesse di DNSSEC significa che una chiave è utile solo finché non viene sostituita. La vera preoccupazione è se un futuro computer quantistico possa rompere una chiave entro la sua durata utile.

Se alla fine saranno necessari algoritmi post-quantistici, porteranno sfide pratiche. Le firme PQC sono molto più grandi, potenzialmente costringendo il DNS a passare dal leggero User Datagram Protocol (UDP) al più pesante Transport Control Protocol (TCP), o richiedendo frammentazione a livello applicativo. Huston ha sottolineato che, sebbene tecnicamente fattibile, far trasportare a tutto il traffico DNS carichi enormi sarebbe economicamente insostenibile perché il DNS è attualmente incredibilmente economico grazie alle dimensioni ridotte dei messaggi.

Johan Stenstam ha presentato tre esperimenti per esplorare il DNSSEC post-quantistico senza rompere il sistema. Il suo primo esperimento ha sfruttato il fatto che l'algoritmo di Shor, che romperebbe la crittografia RSA su un computer quantistico, impiega ore o giorni per una chiave a 2.048 bit. Ha usato DSYNC per ruotare una Key-Signing Key (KSK) DNSSEC ogni dieci minuti per tre mesi, pre-pubblicando solo l'hash DS quantisticamente opaco della chiave. Nel momento in cui un attaccante potesse rompere la KSK, questa era già stata ruotata ed era inutile. Il secondo esperimento ha usato un profilo diviso: una grande KSK post-quantistica per firmare il record DNSKEY all'apice della zona, mentre una Zone-Signing Key (ZSK) più piccola firmava le risposte effettive. Le query ordinarie userebbero le firme ZSK piccole e resterebbero entro i limiti UDP, mentre solo il record DNSKEY sarebbe grande. Il terzo esperimento, chiamato Combined Signing Key (CSK) "Gargantuan", ha prodotto una risposta DNSKEY di 23.843 byte. Due di queste chiavi entrano ancora in una risposta DNS TCP perché è sotto il limite di 64K, ma l'implementazione DNS necessita di una patch per usare buffer grandi. Stenstam ha notato che poi "funziona a meraviglia".

Questi esperimenti suggeriscono che l'approccio mono-algoritmo usato finora in DNSSEC potrebbe essere inappropriato per l'implementazione post-quantistica. La KSK, che viene usata raramente ma deve rimanere stabile a lungo, ha requisiti diversi dalla ZSK, che firma ogni risposta e deve essere piccola. Innovazioni come profili divisi o rotazione rapida delle chiavi potrebbero permettere a DNSSEC di sopravvivere all'era quantistica senza rendere il traffico DNS troppo pesante per l'economia di internet.

Per gli utenti internet di tutti i giorni e le aziende, scegliere un servizio DNS crittografato che mette al primo posto la privacy come AEU DNS (https://aeu-dns.com) può aiutare a ridurre l'esposizione a questi rischi. Il DNS crittografato impedisce la manomissione in transito delle risposte DNS, che è alla base degli attacchi di avvelenamento della cache, e un resolver ben gestito che valida DNSSEC aggiunge un ulteriore livello di garanzia che le risposte siano autentiche.