Anche il DNS diventa post-quantum: Cloudflare valida ML-DSA-44 su 1.1.1.1
Una firma DNSSEC oggi pesa 64 byte. Con l'algoritmo post-quantum che Cloudflare ha appena iniziato a validare su 1.1.1.1, ne pesa 2.420 — quasi 40 volte tanto. Non è un dettaglio: è abbastanza per rompere le assunzioni su cui è costruito il trasporto UDP di DNS, e il modo in cui Cloudflare ha risolto il problema dice molto su cosa significa davvero "crypto-agility".
Il 10 settembre 2026 Cloudflare ha annunciato che il resolver pubblico 1.1.1.1 valida le firme DNSSEC generate con ML-DSA-44, uno dei tre algoritmi post-quantum standardizzati da NIST nell'agosto 2024 (insieme a ML-KEM e SLH-DSA). È il primo passo dichiarato verso un obiettivo di piena sicurezza post-quantum entro il 2029 — e il problema tecnico che questo primo passo espone è più interessante dell'annuncio in sé.
Perché DNSSEC è nel mirino, e perché non è "harvest now, decrypt later"
DNSSEC aggiunge autenticità e integrità alle risposte DNS: firma digitalmente i record, così un resolver può verificare che una risposta non sia stata falsificata lungo il percorso. Gli algoritmi oggi in uso — RSA ed ECDSA — si basano su problemi matematici considerati intrattabili per i computer classici alle dimensioni di chiave correnti. Un computer quantico sufficientemente potente potrebbe romperli, permettendo di forgiare firme e reindirizzare gli utenti verso siti malevoli.
È una distinzione tecnica che vale la pena fare esplicita: DNSSEC garantisce autenticità, non confidenzialità. Non è quindi esposto agli attacchi "harvest now, decrypt later" che minacciano invece i protocolli di scambio chiavi (TLS/key exchange) — lì un avversario può registrare oggi traffico cifrato e decifrarlo in futuro. Per DNSSEC il rischio è diverso: un attaccante con un computer quantico potrebbe forgiare firme al momento dell'attacco, non decifrare firme già emesse in passato.
Il problema che nessuno annuncia nei titoli: la dimensione delle firme
Il vero ostacolo tecnico di questa migrazione non è crittografico, è di trasporto. Il confronto è netto:
- ECDSA P-256: 64 byte
- RSA-2048/SHA-256: 256 byte
- ML-DSA-44: 2.420 byte — circa 38 volte più grande di ECDSA
DNS su UDP era storicamente limitato a 512 byte; con l'estensione EDNS(0) il limite è negoziabile, ma RFC 9715 raccomanda un massimo pratico di 1.400 byte. Una singola firma ML-DSA-44 supera questo limite da sola, prima ancora di contare i dati DNS effettivi da trasmettere. Inviare una risposta di queste dimensioni come UDP frammentato è inaffidabile e va evitato: la conseguenza pratica è che i server autoritativi restituiscono risposte troncate, forzando il client a ripetere la richiesta via TCP.
Cloudflare ha già l'infrastruttura per assorbire questo cambiamento senza disagi operativi rilevanti: su 1.1.1.1 circa l'85% delle query arriva via UDP, ma sulla piattaforma DNS complessiva ("Big Pineapple") circa il 60% usa UDP e il 40% si appoggia già a TCP, DoT o DoH. Per chi gestisce un'infrastruttura DNS meno moderna, questo passaggio a TCP come fallback sistematico non è scontato — ed è il primo elemento da verificare prima di considerare l'adozione di firme post-quantum.
Downgrade protection: il dettaglio che rende l'implementazione seria
Durante la fase di transizione, le zone devono pubblicare sia firme classiche sia post-quantum, per restare compatibili con i resolver che non validano ancora ML-DSA-44. Questo crea un problema di sicurezza sottile: RFC 6840 permette ai validatori di accettare "qualunque singolo path valido" tra quelli disponibili. Se in futuro un algoritmo classico dovesse essere compromesso, un attaccante potrebbe forgiare risposte valide solosul path ECDSA — e un validatore permissivo, che accetta il primo path che verifica correttamente, le accetterebbe comunque, anche se l'algoritmo post-quantum è disponibile e non compromesso.
Cloudflare ha scelto una policy di validazione più stringente: quando il DS record autenticato della zona parent include un algoritmo post-quantum, 1.1.1.1 richiede che il path ML-DSA-44 sia valido, non si accontenta di un path ECDSA che passa la verifica. È il meccanismo che previene lo scenario "break once, forge everywhere" sulla root zone — rompere un solo algoritmo compromesso l'intera catena di fiducia per chiunque si accontenti del primo path valido.
Cosa significa in pratica, e per chi
Il doppio firma comporta risposte DNSKEY più grandi e maggiore complessità nella gestione dei key rollover — un costo operativo concreto per chi amministra zone DNS, non solo per i resolver pubblici. Per un'organizzazione che gestisce la propria infrastruttura DNS, o che dipende da fornitori PKI e certificati, questo annuncio non è una notizia da rilanciare e archiviare: è un indicatore che la finestra per pianificare la crypto-agility — la capacità di sostituire un algoritmo crittografico senza dover riprogettare l'intera infrastruttura — si sta restringendo.
ISO/IEC 27001:2022 lo prevede già nel controllo A.8.24 — Use of cryptography: una politica sull'uso della crittografia che comprenda anche la gestione del ciclo di vita degli algoritmi, non solo la loro scelta iniziale. Per i soggetti NIS2 che gestiscono servizi DNS o infrastrutture correlate, questo si traduce in una domanda operativa concreta: se un fornitore DNS/PKI annunciasse domani la fine del supporto per un algoritmo classico, la transizione sarebbe pianificata o improvvisata?
Fonti
La tua infrastruttura è pronta per la transizione post-quantum?
Organizziamo formazione tecnica su crittografia e crypto-agility e affianchiamo i team IT nella valutazione di readiness NIS2/ISO 27001 su algoritmi, certificati e gestione delle chiavi — prima che la migrazione diventi un'emergenza.
Parla con noi →