Cloudflare ha abilitato su 1.1.1.1 la validazione delle firme DNSSEC create con ML-DSA-44, un algoritmo di firma post-quantum standardizzato dal NIST. È un passaggio tecnico importante, ma non significa che da oggi tutti i domini siano protetti contro futuri computer quantistici. La novità riguarda per ora il lato resolver: quando una zona pubblica i record DNSSEC necessari, 1.1.1.1 è in grado di verificarli automaticamente. Per imprese e responsabili IT il messaggio corretto non è “cambiare subito il DNS”, bensì iniziare a censire dipendenze, apparati e procedure. Le firme ML-DSA-44 sono molto più grandi di quelle attuali e possono far emergere firewall, proxy o resolver che gestiscono male il passaggio da UDP a TCP. Questo articolo spiega cosa è già operativo, cosa manca per una catena di fiducia davvero post-quantum e quali controlli conviene introdurre nelle reti aziendali.
Che cosa ha attivato Cloudflare su 1.1.1.1
Dal 10 settembre 2026 il resolver pubblico Cloudflare 1.1.1.1 valida firme DNSSEC basate su ML-DSA-44. L’algoritmo è la variante più compatta della famiglia Module-Lattice-Based Digital Signature Algorithm definita dal NIST in FIPS 204. Per l’impiego nel DNSSEC utilizza il numero di algoritmo 18 assegnato da IANA.
La parola decisiva è valida. Cloudflare ha aggiornato il resolver ricorsivo, cioè il servizio che riceve una richiesta DNS dall’utente, interroga la gerarchia del DNS e controlla la catena delle firme. Non sta dicendo che ogni zona gestita da Cloudflare sia già firmata con ML-DSA-44. Il supporto alla firma su Cloudflare Authoritative DNS e ai relativi record DS nel registrar è indicato come passaggio successivo.
Chi usa 1.1.1.1 non deve installare componenti o attivare una nuova opzione: la verifica avviene automaticamente quando la zona interrogata pubblica i record compatibili. Le zone DNSSEC tradizionali continuano a essere validate come prima. Perciò la novità non sostituisce la normale gestione del DNS e non rende superflui inventario, ridondanza e monitoraggio.
DNSSEC post-quantum: cosa protegge e cosa non protegge
Il DNS traduce nomi come servizio.azienda.it negli indirizzi necessari per raggiungere server e applicazioni. Le risposte DNS, di base, non sono autenticate. DNSSEC aggiunge firme digitali che permettono a un resolver validante di controllare che i dati provengano dalla zona corretta e non siano stati alterati durante il percorso.
Questa protezione riguarda autenticità e integrità, non la riservatezza della richiesta. DNSSEC non cifra il nome interrogato e non sostituisce DNS over HTTPS, DNS over TLS, una VPN o un servizio di filtraggio. Sono livelli diversi: DoH e DoT proteggono il trasporto tra client e resolver; DNSSEC verifica l’origine dei dati ricevuti dalla gerarchia DNS.
Gli algoritmi oggi più diffusi, come RSA ed ECDSA, si basano su problemi matematici che un futuro computer quantistico crittograficamente rilevante potrebbe risolvere in modo efficiente. ML-DSA è invece progettato per resistere anche a quel tipo di avversario. Non esiste oggi una macchina in grado di eseguire questo attacco contro il DNSSEC operativo. Prepararsi in anticipo è comunque necessario perché la migrazione coinvolge resolver, server autoritativi, registrar, registri e radice DNS: non può essere completata con un singolo aggiornamento.
Perché una firma da 2.420 byte cambia il comportamento della rete
La difficoltà non sta soltanto nella matematica. Una firma ECDSA P-256 occupa 64 byte; una firma ML-DSA-44 ne occupa 2.420, quasi 38 volte tanto. La chiave pubblica ML-DSA-44 misura inoltre 1.312 byte. Una risposta DNSKEY può contenere più chiavi e più firme, soprattutto durante una migrazione o un rollover.
Molte implementazioni DNS usano un payload UDP prudenziale di 1.232 byte per evitare la frammentazione IP. RFC 9715 raccomanda di non superare 1.400 byte per DNS su UDP. Una sola firma ML-DSA-44 oltrepassa entrambe le soglie ancora prima di aggiungere intestazioni, nomi, record firmati e altri dati DNSSEC.
Dal primo tentativo UDP al retry su TCP
Quando la risposta non entra nel budget UDP, il server autoritativo dovrebbe restituire una risposta troncata. Il resolver ripete quindi la richiesta attraverso TCP. È un comportamento previsto dal DNS, non un errore; tuttavia introduce più scambi, più stato da gestire e una possibile latenza aggiuntiva. Il test pubblicato da Cloudflare mostra proprio l’avviso di risposta UDP troncata e il successivo retry via TCP.
Per una rete aziendale questo dettaglio è concreto. Firewall che permettono il DNS soltanto su UDP/53, dispositivi di ispezione con buffer ridotti, proxy DNS datati o NAT con gestione aggressiva delle sessioni possono interrompere una risposta perfettamente valida. Lo stesso vale per resolver locali che non supportano l’algoritmo o per appliance che modificano i pacchetti DNS.
Il rischio di downgrade durante la transizione
Per anni molte zone dovranno pubblicare firme tradizionali e post-quantum insieme, così da restare raggiungibili anche dai resolver meno recenti. Accettare semplicemente “una qualsiasi firma valida” non garantisce però sicurezza post-quantum: in futuro un attaccante potrebbe presentare soltanto il percorso convenzionale compromesso.
Cloudflare applica una policy più restrittiva quando il record DS autenticato della zona superiore segnala un algoritmo post-quantum supportato. In quel caso 1.1.1.1 richiede almeno un percorso ML-DSA-44 valido; se manca, la validazione fallisce invece di ripiegare silenziosamente sull’algoritmo convenzionale. È una policy locale del resolver e non ancora il comportamento ordinario dell’intero ecosistema.
Cosa cambia davvero per aziende e PMI
Per la maggior parte delle PMI non esiste oggi una migrazione urgente da eseguire. Se la rete usa 1.1.1.1 direttamente o tramite un servizio Cloudflare basato sullo stesso motore di risoluzione, la nuova capacità è trasparente. Se il dominio aziendale usa Cloudflare Authoritative DNS, la firma ML-DSA-44 non è ancora il passaggio da attivare: Cloudflare la indica come sviluppo successivo, insieme al supporto DS del registrar.
La novità è però un buon test di maturità. Molte organizzazioni non sanno quali resolver utilizzano realmente notebook, sedi, VPN, reti guest, server e dispositivi IoT. Altre inoltrano le richieste da Active Directory verso resolver pubblici, ma non verificano se la validazione DNSSEC avviene sul resolver interno, a monte o in entrambi i punti. Una configurazione non documentata rende più difficile diagnosticare problemi quando aumentano dimensioni e varietà delle risposte.
È utile distinguere tre scenari:
- Client che interrogano direttamente 1.1.1.1: nessuna configurazione necessaria, ma va confermato che UDP e TCP sulla porta 53 siano gestiti correttamente.
- Client dietro resolver aziendale: bisogna conoscere versione, supporto DNSSEC e comportamento del forwarding. Il client potrebbe non parlare mai direttamente con Cloudflare.
- Domini pubblici dell’azienda: la capacità del resolver non equivale alla firma post-quantum della propria zona. La catena completa dipende anche da autoritativo, registrar, registro della TLD e radice.
Requisiti, limiti e costi
La validazione ML-DSA-44 su 1.1.1.1 non richiede una nuova licenza al singolo utente. Cloudflare afferma inoltre che il futuro supporto alla firma su Authoritative DNS e ai record DS del registrar sarà disponibile gratuitamente per i clienti. Non sono però ancora indicate in quella comunicazione una data generale di attivazione né una copertura completa della catena DNS.
Il limite principale è proprio la maturità dell’ecosistema. L’impiego di ML-DSA nel DNSSEC è descritto in un Internet-Draft aggiornato l’11 agosto 2026: è un lavoro in corso, non un RFC definitivo approvato dall’IETF. NIST ha standardizzato l’algoritmo di firma in FIPS 204, mentre IANA ha assegnato il numero necessario al protocollo DNSSEC. Questi elementi rendono possibili i test su larga scala, ma non equivalgono a una migrazione globale completata.
Esiste poi un costo operativo potenziale: più traffico, più richieste TCP, maggiore uso di memoria e CPU sui resolver, nuovi casi da osservare nei log. Per una PMI con resolver gestiti il peso sarà spesso trascurabile; per provider, grandi reti e servizi DNS ad alto volume va misurato.
Checklist: cosa controllare adesso nella rete aziendale
- Censire i resolver effettivi. Documentare DNS distribuiti via DHCP, profili VPN, Wi-Fi, MDM, router, firewall e configurazioni manuali.
- Verificare il percorso di forwarding. Capire se Active Directory, appliance o servizi SSE inoltrano le richieste a 1.1.1.1 o a un altro resolver e dove avviene la validazione DNSSEC.
- Consentire DNS su TCP. Controllare regole e state tracking per TCP/53 tra resolver ricorsivi e upstream; non autorizzare indiscriminatamente tutti i client se la policy prevede resolver interni.
- Aggiornare resolver e appliance. Verificare versioni supportate, librerie crittografiche e documentazione del produttore prima di abilitare algoritmi sperimentali in produzione.
- Provare risposte grandi. Eseguire test controllati da più sedi e VPN, osservando retry TCP, latenza, frammentazione, timeout e risposte SERVFAIL.
- Monitorare senza allarmismo. Aggiungere dashboard per errori DNSSEC, timeout e variazioni del rapporto UDP/TCP; distinguere problemi di validazione da blocchi di rete.
- Inventariare i domini pubblici. Registrare provider DNS, registrar, stato DNSSEC, contatti, procedure di rollover e dipendenze di terze parti.
- Preparare un piano crittografico. Inserire DNSSEC, certificati, VPN, firme software e PKI nello stesso inventario di transizione post-quantum, con priorità basate sul rischio.
Chi sta riprogettando la risoluzione interna può confrontare questa novità con la guida EP Consulting su Cloudflare Internal DNS e Active Directory. Per le dipendenze di rete è utile anche il caso del BGP hijack e della sicurezza del traffico DNS. Infine, le verifiche su porte, proxy e allowlist seguono lo stesso metodo operativo descritto per Windows Update dietro firewall e proxy.
La valutazione di EP Consulting
L’abilitazione su 1.1.1.1 è soprattutto un passo di osservabilità e interoperabilità. Porta traffico post-quantum reale su un resolver molto diffuso e permette di scoprire in anticipo assunzioni nascoste sulla dimensione dei messaggi, sul fallback TCP e sulla gestione di più algoritmi.
Per un’azienda la risposta più razionale è evitare sia l’indifferenza sia una corsa all’acquisto. Non serve sostituire subito DNS, firewall o registrar soltanto per questo annuncio. Serve invece verificare che la rete gestisca correttamente il DNS standard, che i sistemi siano aggiornabili e che esista un inventario crittografico. Quando firma autoritativa, registrar e gerarchia superiore saranno pronti, chi ha già svolto questi controlli potrà migrare con meno sorprese.
FAQ sul DNSSEC post-quantum
Devo cambiare qualcosa se uso già Cloudflare 1.1.1.1?
No. Cloudflare dichiara che la validazione ML-DSA-44 avviene automaticamente quando una zona pubblica i record DNSSEC necessari. Conviene però controllare che l’infrastruttura consenta i retry DNS su TCP e che eventuali resolver interni, firewall o proxy non blocchino risposte più grandi.
Il mio dominio è già protetto dai computer quantistici?
Non necessariamente. Il supporto del resolver è soltanto un anello. Per una catena post-quantum completa devono adottare l’algoritmo anche server autoritativi, registrar, registri e radice DNS. Qualsiasi livello ancora basato soltanto su firme convenzionali rimane un possibile punto di downgrade futuro.
DNSSEC post-quantum cifra le richieste DNS?
No. DNSSEC autentica i dati e ne verifica l’integrità, ma non nasconde il nome richiesto. Per cifrare il collegamento fra client e resolver servono protocolli come DNS over HTTPS o DNS over TLS. Le due protezioni sono complementari e rispondono a rischi differenti.
Perché le risposte possono passare da UDP a TCP?
Una firma ML-DSA-44 misura 2.420 byte, più del payload UDP prudenziale comunemente usato per il DNS. Il server può quindi segnalare una risposta troncata e il resolver ripete la richiesta su TCP. Firewall e appliance devono gestire correttamente questo comportamento previsto dal protocollo.
ML-DSA per DNSSEC è già uno standard IETF definitivo?
No. ML-DSA è standardizzato dal NIST in FIPS 204 e IANA ha assegnato al suo uso DNSSEC il numero di algoritmo 18. La specifica che descrive come impiegarlo in DNSSEC è però ancora un Internet-Draft attivo, quindi può essere aggiornata e non ha ancora lo status di RFC definitivo.
Se vuoi verificare resolver, firewall e dipendenze DNS prima che la transizione post-quantum diventi un requisito operativo, EP Consulting può affiancarti con un assessment mirato e un piano di test progressivo.
Fonti
- Cloudflare — 1.1.1.1 now supports post-quantum DNSSEC, all 2,420 bytes of it, 10 settembre 2026.
- NIST — First 3 Finalized Post-Quantum Encryption Standards, con riferimento a FIPS 204.
- IETF Datatracker — Module-Lattice Digital Signature Algorithm for DNSSEC, Internet-Draft aggiornato l’11 agosto 2026.
- IANA — Domain Name System Security (DNSSEC) Algorithm Numbers.
- IETF — RFC 9715, IP Fragmentation Avoidance in DNS over UDP.