DNSSEC affronta un problema di traffico post-quantum

DNSSEC, il sistema che usa firme digitali per verificare che le risposte DNS siano autentiche, affronta un problema di trasporto se adotta la post-quantum cryptography. Le firme più grandi potrebbero rendere molte risposte troppo grandi per la normale trasmissione UDP, costringendo i recursive resolver a riprovare le query tramite TCP.

La preoccupazione deriva dal possibile arrivo di un cryptographically relevant quantum computer, o CRQC, abbastanza potente da ricavare le chiavi private dalle informazioni pubbliche esposte entro un periodo utile. I computer quantistici sono ancora a uno stadio molto iniziale e la loro costruzione è stata lenta e costosa. Tuttavia, l'algoritmo del 1994 di Peter Shor ha dimostrato che computer quantistici sufficientemente potenti potrebbero minacciare RSA e la crittografia a curve ellittiche, nota come ECC.

Non si sa quando esisterà un CRQC. È stato preso in considerazione l'anno 2030, anche se APNIC lo descrive come una possibilità ottimistica e non come una previsione consolidata. Il problema è già rilevante per le informazioni che devono rimanere segrete per due decenni. Un aggressore potrebbe catturare oggi dati cifrati e decifrarli in seguito, una pratica nota come Harvest Now, Decrypt Later, o HNDL.

Le firme digitali presentano una debolezza correlata. Se un aggressore calcola la chiave privata appartenente a una coppia di chiavi di firma, potrebbe impersonarne il proprietario. Il rischio dipende in parte da quanto a lungo quella chiave rimane in uso. Una pubblicazione ICANN del 2022, “Observing DNSSEC Key Lifecycles” (OCTO-035), ha rilevato che le Key-Signing Keys dei domini di primo livello, o KSK, rimanevano generalmente in uso per uno o più anni, mentre le Zone Signing Keys, o ZSK, venivano generalmente utilizzate per uno o più mesi.

Ruotare le chiavi più frequentemente potrebbe offrire una prima risposta, per esempio sostituendo una ZSK ogni mese e una KSK ogni anno o ogni sei mesi. Tuttavia, una rotazione più rapida non sarebbe sufficiente se il quantum computing progredisse velocemente. Gli operatori DNS dovrebbero infine utilizzare algoritmi crittografici post-quantum, noti come PQC, nella loro configurazione DNSSEC.

La sfida ingegneristica immediata riguarda le dimensioni. APNIC confronta l'algoritmo DNSSEC 13, ECDSA P-256 con SHA-256, con l'algoritmo 18, ML-DSA-44. La chiave pubblica ECDSA è di 32 byte, la chiave privata è di 32 byte e la firma è di 65 byte. ML-DSA-44 usa una chiave pubblica di 1.312 byte, una chiave privata di 2.560 byte e una firma di 2.420 byte.

Nell'esempio di APNIC, una query DNS per un nome firmato con ECDSA P-256 produceva una risposta di 191 byte, inclusa una firma di 65 byte, che rientrava in un singolo pacchetto UDP non frammentato. La stessa query usando ML-DSA-44 produceva una risposta di 2.551 byte. Il recursive resolver restituiva una risposta UDP troncata, quindi lo stub resolver doveva stabilire una connessione TCP e ripetere la query. La transazione passava da due pacchetti UDP a dieci pacchetti, includendo il messaggio di troncamento, l'handshake TCP e la chiusura della connessione.

La frammentazione IP potrebbe sembrare una soluzione al problema, perché un pacchetto IP può arrivare a 65.536 byte. Tuttavia, la frammentazione è inaffidabile e rischiosa sia su IPv4 sia su IPv6. APNIC cita il DNS Flag Day 2020, che avvertiva che i messaggi DNS frammentati potrebbero non arrivare a destinazione e potrebbero anche consentire lo spoofing di parti di un messaggio senza una facile rilevazione.

Il design originale del DNS limitava il payload UDP a 512 ottetti. Extension Mechanisms for DNS, o EDNS, ha successivamente consentito a un richiedente di dichiarare il payload UDP più grande che poteva riassemblare. Fino al 2019 circa, 4.096 ottetti venivano spesso suggeriti come punto di partenza. Il DNS Flag Day 2020 ha invece raccomandato una dimensione del buffer UDP EDNS di 1.232 byte per evitare la frammentazione su quasi tutte le reti attuali. Le specifiche pertinenti sono RFC 6891 e RFC 4035.

APNIC Labs ha misurato le dimensioni dei buffer EDNS nell'arco di sette giorni terminati il 3 novembre 2026, usando 36 miliardi di query provenienti da 245 milioni di utenti finali registrati. La maggior parte delle query usava 1.410 byte. APNIC ha calcolato che il 75,2% delle query usava una dimensione del buffer che probabilmente evitava la frammentazione all'interno di un pacchetto IP da 1.500 byte, mentre il 24,8% indicava che il recursive resolver poteva accettare una risposta più grande e frammentata. La misurazione non significa che un quarto delle risposte sarà necessariamente frammentato, perché anche i server authoritative impostano i propri limiti. È il limite più piccolo a determinare se una risposta è completa o troncata.

Le grandi risposte post-quantum DNSSEC verrebbero normalmente troncate e ritrasmesse tramite TCP. Questo è importante perché i recursive resolver richiedono comunemente i record DNSSEC anche quando il client finale non ha bisogno di visualizzarli. Il DNSSEC OK, o DO bit, comunica a un resolver che i record DNSSEC come RRSIG, DNSKEY e DS possono essere inclusi. Non richiede di per sé la validazione.

Un recursive resolver consapevole di DNSSEC può impostare il DO bit quando interroga un server authoritative, quindi rimuovere i record DNSSEC prima di restituire la risposta a un client che non li aveva richiesti. In questo modo il resolver può memorizzare nella cache un unico risultato abilitato per DNSSEC ed evitare una seconda ricerca. Il bit Checking Disabled, o CD bit, comunica a un recursive resolver di non bloccare o rimuovere i dati quando la validazione non riesce. Il bit Authenticated Data, o AD bit, in una risposta indica che il resolver ha verificato i record con DNSSEC. Uno stub resolver dovrebbe fidarsi di AD solo attraverso una connessione sicura, attendibile e autenticata a quel resolver.

APNIC Labs ha rilevato il DO bit impostato nel 60,2% di 36.324.963.331 query durante la settimana terminata il 3 novembre 2026. Lo stesso rapporto si applicava alle query di record A, mentre la rimozione delle query duplicate produceva un rapporto del 60,9%. Le misurazioni provenivano da un ampio campione di utenti finali raggiunti attraverso il sistema di distribuzione pubblicitaria di Google e la piattaforma APNIC Labs.

Nello stesso periodo, il 40% degli utenti si trovava dietro recursive resolver che eseguivano la DNSSEC validation. Un altro 8,5% si trovava dietro sistemi che tentavano la validazione, ma riprovavano attraverso un resolver non validante dopo SERVFAIL. Ciò suggerisce che il 48% degli utenti inviasse query a resolver consapevoli della sicurezza, dai quali ci si aspettava che impostassero il DO bit upstream. L'ulteriore 12% sembrava non validare DNSSEC, senza query DNSKEY, sebbene i relativi resolver impostassero comunque il DO bit.

L'impatto pratico è oggi limitato dalla caching e dal fatto che solo circa il 2% dei nomi interrogati è firmato con DNSSEC, secondo i dati del recursive resolver 1.1.1.1 di Cloudflare. Le misurazioni di APNIC usavano deliberatamente label univoche, impedendo alle cache di assorbire le query prima che raggiungessero i server authoritative. La maggior parte degli stub resolver si affida inoltre ai recursive resolver per la validazione e usa AD come segnale.

Se alla fine l'intero spazio DNSSEC passasse a PQC, APNIC osserva che circa il 60% delle query odierne potrebbe inizialmente essere reindirizzato da UDP a TCP. Ciò solleva la questione se le query che trasportano il DO bit debbano passare direttamente a TCP. Una bozza Internet in lavorazione intitolata “No DO for you” propone che i resolver non validanti azzerino il DO bit e memorizzino quindi nella cache se una risposta è stata ottenuta con il bit impostato. Se in seguito un client richiede record DNSSEC, il resolver eseguirebbe una nuova ricerca con il DO bit impostato.