Double-Signed Fragmented DNSSEC for Countering Quantum Threat

Informazioni Fondamentali

• ID Articolo: 2411.07535
• Titolo: Double-Signed Fragmented DNSSEC for Countering Quantum Threat
• Autori: Syed W. Shah, Lei Pan, Dinh Duc Nha Nguyen, Robin Doss, Warren Armstrong, Praveen Gauravaram
• Istituzioni: Deakin Cyber Research and Innovation Centre (Australia), Cyber Security Cooperative Research Centre (Australia), Quintessence Labs (Canberra), Tata Consultancy Services (Brisbane)
• Classificazione: cs.CR (Crittografia e Sicurezza)
• Conferenza di Pubblicazione: C'25, Novembre 2025 (versione preliminare accettata da ITNAC 2025)
• Link Articolo: https://arxiv.org/abs/2411.07535

Riassunto

DNSSEC, in quanto estensione di sicurezza del DNS, è fondamentale per la corretta traduzione dei nomi di dominio in indirizzi IP. Le firme digitali forniscono la base per questa traduzione affidabile; tuttavia, lo sviluppo dei computer quantistici rende vulnerabili le firme digitali tradizionali. Il NIST ha recentemente selezionato firme digitali post-quantistiche che funzionano su computer tradizionali e resistono agli attacchi dei computer quantistici. Poiché queste firme digitali post-quantistiche sono ancora in fase iniziale di sviluppo, sostituire le firme digitali pre-quantistiche in DNSSEC con candidati post-quantistici prima di un'analisi di sicurezza approfondita comporta rischi. Questa ricerca esplora la fattibilità dell'adozione di "firme doppie" in DNSSEC, combinando firme digitali post-quantistiche e classiche. Le firme doppie fornirebbero contemporaneamente protezione contro le minacce quantistiche e gli attacchi non-quantistici sconosciuti. Tuttavia, l'inclusione di due firme entra in conflitto con la dimensione massima consentita delle risposte DNSSEC (1232B, limitata dall'MTU del collegamento fisico). Per risolvere questo problema, l'articolo adotta un metodo di frammentazione a livello applicativo per gestire le risposte DNSSEC con firme doppie. La soluzione implementata su OQS-BIND dimostra che le firme doppie e la frammentazione a livello applicativo hanno un impatto minimo sull'efficienza del processo di risoluzione, rendendole adatte all'uso nel periodo di transizione prima della completa implementazione dei computer quantistici.

Contesto di Ricerca e Motivazione

1. Problema Fondamentale

DNSSEC assicura l'autenticità e l'integrità delle risposte DNS attraverso firme digitali, ma affronta un triplo dilemma nell'era quantistica:

• Minaccia Quantistica: I computer quantistici correlati alla crittografia (CRQC) possono rompere le firme tradizionali basate sulla fattorizzazione intera e sui logaritmi discreti in tempo polinomiale mediante l'algoritmo di Shor
• Immaturità Post-Quantistica: Le firme post-quantistiche selezionate dal NIST (FALCON, DILITHIUM, SPHINCS+) non hanno ancora subito un'analisi crittografica sufficiente e potrebbero contenere difetti di progettazione sfruttabili da computer classici
• Rischio nel Periodo di Transizione: Nel "periodo di transizione" dalla situazione attuale fino alla completa implementazione di CRQC, dipendere esclusivamente da firme tradizionali o post-quantistiche comporta rischi di sicurezza

2. Importanza del Problema

• Il DNS è il nucleo dell'infrastruttura di Internet; qualsiasi vulnerabilità di sicurezza potrebbe indirizzare gli utenti verso server malevoli
• Secondo le raccomandazioni dell'ENISA, la semplice sostituzione degli algoritmi crittografici nel periodo di transizione potrebbe ridurre la sicurezza complessiva
• Sia i progressi non divulgati di CRQC che i difetti negli algoritmi post-quantistici potrebbero rendere DNSSEC inefficace

3. Limitazioni degli Approcci Esistenti

• Solo Firme Tradizionali: Non possono resistere agli attacchi quantistici futuri
• Solo Firme Post-Quantistiche: Potrebbero contenere vettori di attacco classici sconosciuti
• Schemi di Frammentazione Esistenti: ARRF utilizza RR non standard che potrebbero causare problemi di compatibilità con i middlebox; QBF non considera lo scenario di firme doppie
• Meccanismo di Fallback TCP: Molti server dei nomi mancano di supporto TCP, e il TCP è meno leggero dell'UDP

4. Motivazione della Ricerca

Adozione di una strategia di "firme doppie" (interfaccia di messaggio staccato):

• Finché una firma rimane sicura, l'intero sistema mantiene la sicurezza
• Fornisce la massima protezione di sicurezza per il periodo di transizione
• Necessita di risolvere il problema del superamento della dimensione massima del messaggio causato dalle firme doppie (>1232B attiva la frammentazione a livello IP)

Contributi Fondamentali

1. Implementazione Completa di DNSSEC con Firme Doppie: Sviluppo di una piattaforma di test DNSSEC basata su Docker, utilizzando il software BIND9 di livello commerciale, in grado di gestire contemporaneamente firme e chiavi pubbliche pre-quantistiche e post-quantistiche in un singolo messaggio di risposta UDP
2. Meccanismo di Frammentazione e Ricomposizione a Livello Applicativo: Progettazione di uno schema QBF migliorato per lo scenario di firme doppie:
   • Utilizzo di z-bits per identificare il tipo di algoritmo post-quantistico
   • Utilizzo di offset TTL per mantenere l'ordine originale dei RR al fine di evitare errori di puntatori di compressione
   • Supporto di tutte le combinazioni pre-quantistiche (ECDSA256, RSASHA256) e post-quantistiche (FALCON512, DILITHIUM2, SPHINCS+)
3. Modifica del Codice Sorgente di BIND9: Ricerca approfondita e modifica del componente resolver di BIND9 per consentire la verifica di due firme prima di contrassegnare la risposta come autenticata
4. Valutazione delle Prestazioni: Analisi empirica che dimostra come le firme doppie abbiano un impatto trascurabile sul tempo di risoluzione DNSSEC (<9% di aumento), confermando l'applicabilità nel periodo di transizione

Dettagli del Metodo

Definizione del Compito

Input: Query DNS (ad esempio, record A di test.example.com)
Output: Indirizzo IP con verifica di firme doppie
Vincoli:

• Dimensione del messaggio UDP ≤1232B (evitare frammentazione a livello IP)
• Verificare contemporaneamente firme pre-quantistiche e post-quantistiche
• Mantenere la compatibilità con l'infrastruttura DNS esistente

Progettazione dell'Architettura di Firme Doppie

1. Generazione di Firme (Lato Server dei Nomi)

Utilizzo dell'interfaccia di messaggio staccato (detached-message interface):

• Utilizzo di strumenti BIND9 per generare due coppie di chiavi (ZSK e KSK)
• Generazione indipendente di due firme per lo stesso RRSet:
  • Firma pre-quantistica X (ECDSA256 o RSASHA256)
  • Firma post-quantistica Y (FALCON512/DILITHIUM2/SPHINCS+)
• Entrambi gli RRSIG e i DNSKEY sono archiviati nel file della zona firmata

Esempio (Figura 13):
test0.socratescrc. 3600 IN RRSIG A 13 ... (firma ECDSA)
test0.socratescrc. 3600 IN RRSIG A 249 ... (firma post-quantistica)

2. Strategia di Verifica (Lato Resolver)

Modifica della logica di verifica di BIND9:

• Verifica indipendente di due firme
• Accettazione della risposta solo quando entrambe le firme superano la verifica
• Fornire protezione doppia contro attacchi quantistici e classici

Meccanismo di Frammentazione a Livello Applicativo

Sfida Fondamentale

Dimensione tipica della risposta con firme doppie:

• Risposta record A: ~2500B (combinazione minima ECDSA+FALCON512)
• Risposta DNSKEY: 4462B (RSASHA256+FALCON512)
• Molto superiore alla soglia di 1232B

Strategia di Frammentazione

Principi Fondamentali:

• L'RRSIG pre-quantistico e il DNSKEY sono sempre inviati completamente nel primo frammento (dimensioni inferiori)
• Le firme/chiavi post-quantistiche vengono frammentate secondo necessità

Frammentazione della Risposta del Record A (Figura 8a):

1. Il primo frammento contiene: Header + Question + RRSIG/DNSKEY pre-quantistico completo + parte dell'RRSIG post-quantistico
2. Il resolver deduce il numero totale di frammenti dal primo frammento
3. Richiesta parallela dei frammenti rimanenti (formato: ?n?domain_name)

Frammentazione della Risposta DNSKEY (Figura 8b):

• Alcune combinazioni (come RSASHA256) causano l'impossibilità del primo frammento di contenere dati post-quantistici
• Soluzione Innovativa:

Metodo di Identificazione Z-bits:

Utilizzo degli z-bits (3 bit) in RFC 1035:
- Codifica del tipo di algoritmo post-quantistico (FALCON/DILITHIUM/SPHINCS+)
- Il resolver deduce la dimensione totale in base agli z-bits e ai RR pre-quantistici già ricevuti

Meccanismo di Offset TTL:

Problema: I puntatori di compressione DNS dipendono dall'ordine dei RR
Soluzione: Aggiunta di un offset nel campo TTL della risposta DNSKEY
Funzione: Ripristino della posizione originale dei RR durante la ricomposizione, evitando errori di "bad compression pointer"

Flusso di Lavoro (Figura 10)

Daemon del Server dei Nomi:

1. Intercettazione della risposta DNS, verifica se la dimensione è >1232B
2. Calcolo del numero di frammenti necessari
3. Impostazione degli z-bits (se necessario) e dell'offset TTL
4. Impostazione del flag TC=1, invio del primo frammento
5. Memorizzazione in cache dei frammenti rimanenti

Daemon del Resolver:

1. Ricezione del primo frammento, verifica del flag TC
2. Analisi degli z-bits per determinare l'algoritmo post-quantistico
3. Utilizzo delle informazioni dei RR pre-quantistici per dedurre il numero totale di frammenti
4. Richiesta parallela di tutti i frammenti rimanenti (?2?test.socrates, ?3?test.socrates...)
5. Dopo la raccolta di tutti i frammenti, ricomposizione:
   • Utilizzo dell'offset TTL per ripristinare l'ordine originale dei RR
   • Ripristino del flag TC e di altri valori di header
6. Passaggio del messaggio completo al verificatore OQS-BIND

Punti di Innovazione Tecnica

1. Compatibilità RR Standard: A differenza di ARRF che utilizza RR personalizzati, l'utilizzo del formato DNS standard assicura la compatibilità con i middlebox
2. Riutilizzo degli Z-bits: Utilizzo innovativo di header bits sottoutilizzati per risolvere il problema dell'insufficienza di informazioni nella risposta DNSKEY
3. Schema di Offset TTL: Risoluzione del conflitto tra il meccanismo di compressione DNS e la ricomposizione della frammentazione, un problema specifico dello scenario di firme doppie
4. Richieste di Frammenti Paralleli: Il resolver ottiene tutti i frammenti in parallelo, minimizzando la latenza
5. Indipendenza dall'Algoritmo: Supporto di qualsiasi combinazione di algoritmi post-quantistici selezionati dal NIST e algoritmi pre-quantistici comuni

Configurazione Sperimentale

Architettura della Piattaforma di Test

Infrastruttura:

• Istanza Amazon EC2 t2.xlarge (4 core Intel Xeon 2.3GHz, 16GB RAM)
• Distribuzione containerizzata con Docker (Docker 25.0.3)
• Componenti: Client, Resolver, Root Server, Authoritative Server

Stack Software:

• OQS-BIND: Versione migliorata di BIND9 post-quantistica
  • OpenSSL 1.1.1
  • OQS liboqs 0.7.2
  • Supporto per FALCON512, DILITHIUM2-AES, SPHINCS+-SHA256-128S (livello di sicurezza 128-bit)
• Daemon QBF Modificato: Implementazione della logica di frammentazione/ricomposizione di firme doppie

Topologia di Rete (Figura 11):

Client → Resolver → Root Server → Authoritative Server
        ↑                            ↓
        └────────────────────────────┘

Configurazione del Dataset

• Nomi di Dominio di Test: 10 record A (test0.socratescrc - test9.socratescrc)
• Combinazioni di Firme: 6 configurazioni di firme doppie
  • Pre-quantistiche: ECDSA256, RSASHA256
  • Post-quantistiche: FALCON512, DILITHIUM2, SPHINCS+-SHA256-128S
• Catena di Fiducia: Record DS correttamente configurati, stabilimento di una catena di fiducia completa

Metriche di Valutazione

1. Tempo di Risoluzione: Latenza end-to-end dal invio della query alla ricezione della risposta verificata
2. Numero di Frammenti: Numero di frammenti necessari per le risposte dei record A e DNSKEY
3. Overhead di Prestazioni: Percentuale di aumento del tempo per le firme doppie rispetto alle firme post-quantistiche singole

Simulazione delle Condizioni di Rete

Utilizzo dello strumento Linux tc per simulare:

• Larghezza di Banda: 50 Mbps
• Latenza: 10 ms
• Simulazione di condizioni Internet realistiche

Metodologia Sperimentale

1. Iterazione delle query di risoluzione per ogni nome di dominio
2. Registrazione del tempo di risoluzione per ogni query
3. Calcolo del tempo medio di risoluzione per 10 query
4. Confronto delle prestazioni tra firme doppie e firme post-quantistiche singole

Risultati Sperimentali

Analisi del Numero di Frammenti (Tabella 1)

Scoperte Chiave:

• Le combinazioni FALCON e DILITHIUM aumentano solo di 1 frammento
• Le combinazioni SPHINCS+ non aumentano frammenti aggiuntivi (ottimizzazione del daemon rimuove RR non critici)
• L'incremento di frammentazione è controllabile, senza crescita esponenziale

Tempo Medio di Risoluzione

Combinazioni FALCON (Tabella 2):

Combinazioni DILITHIUM (Tabella 3):

Combinazioni SPHINCS+ (Tabella 4):

Risultati Principali

1. Overhead di Prestazioni Accettabile:
   • Tutte le combinazioni di firme doppie hanno un overhead <9%
   • Significativamente inferiore all'overhead del fallback TCP (tipicamente >50%)
2. Configurazione Ottimale:
   • FALCON+RSASHA: 204.5ms (firma doppia più veloce)
   • DILITHIUM+RSASHA: 220.7ms
   • 14-22% più veloce della firma singola SPHINCS+ (245.6ms)
3. RSA Superiore a ECDSA:
   • In tutte le combinazioni, la velocità di verifica RSA è superiore
   • Esempio: DILITHIUM+RSA (220.7ms) vs DILITHIUM+ECDSA (225.6ms)
4. Tasso di Successo della Verifica della Firma:
   • Tutte le combinazioni di firme doppie vengono verificate correttamente
   • Il resolver BIND9 modificato verifica con successo due firme (Figura 14)

Scoperte Sperimentali

1. Vantaggi degli Algoritmi Basati su Reticoli:
   • FALCON e DILITHIUM (basati su reticoli) hanno dimensioni di firma più piccole
   • Tempo di risoluzione significativamente superiore a SPHINCS+ (basato su hash)
2. Svantaggi di SPHINCS+:
   • Dimensione della firma massima (23 frammenti per record A)
   • Il NIST lo ha scelto principalmente per evitare dipendenza eccessiva da algoritmi basati su reticoli
   • Non è la scelta ottimale nello scenario di firme doppie
3. Affidabilità della Ricomposizione dei Frammenti:
   • Il meccanismo di offset TTL risolve efficacemente il problema dei puntatori di compressione
   • Lo schema z-bits comunica accuratamente le informazioni dell'algoritmo
   • Nessuna perdita di messaggi o errore di verifica
4. Guadagno di Sicurezza:
   • Le firme doppie forniscono un meccanismo "fail-safe"
   • Anche se gli algoritmi basati su reticoli vengono compromessi, RSA/ECDSA fornisce ancora sicurezza classica
   • Anche se il computer quantistico viene implementato, gli algoritmi post-quantistici forniscono protezione

Lavori Correlati

Ricerca DNSSEC Post-Quantistica

1. Müller et al. (2020):
   • Analisi dei requisiti dei candidati della terza fase NIST per DNSSEC
   • Non considera lo schema di firme doppie
2. Beernink (2022):
   • Propone metodi di trasmissione fuori banda di chiavi di grandi dimensioni
   • Non risolve il problema della dimensione del messaggio per firme doppie
3. Goertzen & Stebila (2022) - ARRF:
   • Frammentazione a livello applicativo su richiesta
   • Introduce pseudo-RR RRFRAGS (non standard)
   • Rischio di attacchi di esaurimento della memoria
4. Rawat & Jhanwar (2024) - QBF:
   • Frammentazione basata su QName, utilizzo di RR standard
   • Richieste di frammenti paralleli per migliorare l'efficienza
   • Non supporta firme doppie

Confronto dei Contributi

Ricerca su Combinatori Crittografici

• ENISA (2022) consiglia l'utilizzo di sistemi crittografici ibridi nel periodo di transizione
• Questo articolo è il primo a implementare e valutare le firme doppie in DNSSEC
• Utilizzo dell'interfaccia di messaggio staccato (più facile da integrare)

Conclusioni e Discussione

Conclusioni Principali

1. Fattibilità Tecnica: Le firme doppie DNSSEC sono completamente fattibili su infrastrutture esistenti, senza richiedere modifiche a livello di protocollo
2. Prestazioni Accettabili: Overhead di prestazioni <9%, significativamente inferiore al fallback TCP, non influisce notevolmente sull'esperienza dell'utente
3. Miglioramento della Sicurezza: Fornisce protezione doppia contro attacchi quantistici e classici, adatto per la distribuzione nel periodo di transizione
4. Migliore Pratica: Consigliato l'utilizzo della combinazione FALCON o DILITHIUM con RSA, bilanciando sicurezza e prestazioni

Limitazioni

1. Scala di Test Limitata:
   • Test solo su una singola istanza EC2
   • Mancanza di simulazione di scenari di distribuzione su larga scala Internet
   • Mancanza di test con traffico di rete reale
2. Condizioni di Rete Semplificate:
   • Simulazione solo di larghezza di banda 50Mbps e latenza 10ms
   • Non considerazione di perdita di pacchetti, jitter e altre situazioni complesse
   • Mancanza di test in ambienti con MTU diversi
3. Overhead del Daemon:
   • Logica di frammentazione/ricomposizione implementata in daemon separato
   • La comunicazione tra processi potrebbe introdurre latenza aggiuntiva
   • Non integrato direttamente nel nucleo di BIND9
4. Compatibilità con Middlebox:
   • Mancanza di test completo del comportamento di firewall, NAT e altri middlebox
   • Il riutilizzo degli z-bits potrebbe causare problemi in alcune implementazioni
5. Impatto sulla Cache:
   • Mancanza di analisi dell'impatto della frammentazione sull'efficienza della cache DNS
   • Più frammenti potrebbero aumentare la complessità della cache
6. Analisi di Sicurezza Insufficiente:
   • Mancanza di prove di sicurezza formali
   • Mancanza di valutazione della robustezza contro attacchi DoS
   • Mancanza di analisi dei rischi di canale laterale della ricomposizione dei frammenti

Direzioni Future

1. Integrazione Diretta in BIND9:
   • Integrazione della logica di frammentazione nel nucleo di BIND9
   • Previsione di ulteriore riduzione del tempo di risoluzione
2. Test di Distribuzione su Larga Scala:
   • Pilota su infrastruttura DNS reale
   • Valutazione della compatibilità con vari tipi di middlebox
3. Ottimizzazione della Selezione dell'Algoritmo:
   • Selezione dinamica della combinazione di algoritmi in base al tipo di query
   • Esplorazione di strategie di frammentazione adattive
4. Promozione della Standardizzazione:
   • Presentazione di bozze all'IETF
   • Promozione delle firme doppie come pratica standard nel periodo di transizione
5. Miglioramento della Sicurezza:
   • Aggiunta di meccanismi di protezione DoS
   • Ricerca sulla difesa da attacchi di timing nella ricomposizione dei frammenti

Valutazione Approfondita

Punti di Forza

1. Identificazione Accurata del Problema:
   • Chiara identificazione del dilemma di sicurezza nel periodo di transizione
   • La strategia di firme doppie è conforme alle raccomandazioni di autorità come ENISA
   • Risoluzione degli ostacoli tecnici critici nella distribuzione pratica
2. Soluzione Tecnica Completa:
   • Gli z-bits e l'offset TTL sono soluzioni ingegneristiche innovative
   • Bilanciamento di prestazioni, compatibilità e sicurezza
   • Dettagli di implementazione sufficienti (modifica del codice sorgente, progettazione del daemon)
3. Progettazione Sperimentale Ragionevole:
   • Utilizzo del software BIND9 di livello commerciale aumenta l'utilità pratica
   • Test di tutte le principali combinazioni di algoritmi
   • Simulazione delle condizioni di rete conforme agli scenari reali
4. Risultati Convincenti:
   • Dati di prestazioni chiari (<9% overhead)
   • Verifica della correttezza di tutte le combinazioni
   • Raccomandazioni di distribuzione esplicite (FALCON/DILITHIUM+RSA)
5. Valore Ingegneristico Elevato:
   • Basato su OQS-BIND open source, buona riproducibilità
   • Distribuzione containerizzata con Docker facilita la diffusione
   • Fornisce un percorso fattibile per la distribuzione pratica

Insufficienze

1. Mancanza di Analisi Teorica:
   • Mancanza di prove di sicurezza formali dello schema di firme doppie
   • Mancanza di discussione sulla forza crittografica della combinazione di firme
   • Mancanza di argomentazione rigorosa per l'assunzione che "una firma rimane sicura se l'altra fallisce"
2. Ambito di Valutazione Limitato:
   • Solo 10 nomi di dominio di test, piccolo campione
   • Mancanza di test in scenari ad alto carico e alta concorrenza
   • Mancanza di test di stabilità a lungo termine
3. Confronto Insufficiente con Soluzioni Esistenti:
   • Mancanza di confronto diretto delle prestazioni con il fallback TCP
   • Mancanza di valutazione dei vantaggi rispetto a soluzioni alternative come EDNS(0) padding
   • Mancanza di analisi comparativa della sicurezza rispetto alle distribuzioni pure FALCON e DILITHIUM
4. Considerazioni di Praticità Incomplete:
   • Mancanza di discussione sulla complessità della gestione delle chiavi (due set di chiavi)
   • Mancanza di analisi dei costi di aggiornamento dell'infrastruttura DNSSEC esistente
   • Mancanza di test di compatibilità all'indietro (resolver versioni precedenti)
5. Miglioramenti Possibili nella Scrittura:
   • Alcuni dettagli tecnici sono descritti in modo prolisso (Sezione 2 sui fondamenti DNS)
   • I diagrammi potrebbero essere più chiari (Figure 8, 10 piuttosto complesse)
   • Mancanza di pseudocodice degli algoritmi

Impatto

Contributi al Campo:

• Pioneristico: Primo lavoro a implementare e valutare le firme doppie DNSSEC
• Tempestivo: Risposta tempestiva al processo di standardizzazione PQC del NIST
• Pratico: Fornisce una soluzione di transizione immediatamente distribuibile

Valore Pratico:

• Breve Termine: Fornisce agli operatori DNS una soluzione di miglioramento della sicurezza nel periodo di transizione
• Medio Termine: Fornisce dati empirici per la standardizzazione IETF
• Lungo Termine: Fornisce riferimento per la transizione quantistica sicura di altri protocolli

Riproducibilità:

• ✓ Basato su software open source (OQS-BIND)
• ✓ Descrizione dettagliata dell'implementazione
• ✗ Codice non pubblicato pubblicamente (nessun link GitHub menzionato nell'articolo)
• ✓ Distribuzione containerizzata con Docker riduce la difficoltà di riproduzione

Impatto Potenziale:

• Potrebbe promuovere l'adozione della strategia di firme doppie dalla comunità DNS
• Fornisce riferimento per strategie di frammentazione di altri protocolli a livello applicativo (come TLS, SSH)
• Contribuisce ad accelerare la distribuzione pratica della crittografia post-quantistica

Scenari di Applicazione

Scenari di Applicazione Ideali:

1. DNS di Infrastrutture Critiche: Domini di istituzioni finanziarie, governative e altre organizzazioni con requisiti di sicurezza estremamente elevati
2. Distribuzione nel Periodo di Transizione: 2025-2030, quando la minaccia CRQC si avvicina ma gli algoritmi post-quantistici richiedono ancora verifica
3. Obiettivi di Alto Valore: Organizzazioni facilmente bersaglio di attacchi di attori a livello nazionale

Scenari Non Applicabili:

1. Ambienti con Risorse Limitate: Dispositivi IoT, sistemi embedded (overhead computazionale e di archiviazione)
2. Requisiti di Bassa Latenza: Sistemi di comunicazione in tempo reale (l'8% di latenza aggiuntiva potrebbe essere inaccettabile)
3. Era Post-Quantistica: Una volta che gli algoritmi post-quantistici sono completamente maturi, la necessità di firme doppie diminuisce

Raccomandazioni di Distribuzione:

• Priorità di distribuzione su server root e server TLD
• Utilizzo della combinazione FALCON+RSA o DILITHIUM+RSA
• Coesistenza con l'infrastruttura DNSSEC esistente (aggiornamento progressivo)
• Stabilimento di meccanismi di monitoraggio per tracciare prestazioni e sicurezza

Riferimenti Bibliografici (Riferimenti Chiave)

1. Shor (1994): "Algorithms for quantum computation" - Base teorica della minaccia quantistica
2. NIST PQC Standardization: Specifiche degli algoritmi FALCON, DILITHIUM, SPHINCS+
3. RFC 4034: Specifica dei record di risorse DNSSEC
4. RFC 6891: Meccanismo di estensione EDNS(0)
5. ENISA (2022): "Post-Quantum Cryptography Integration Study" - Base politica per la strategia di firme doppie
6. Goertzen & Stebila (2022): Schema di frammentazione ARRF
7. Rawat & Jhanwar (2024): Schema di frammentazione QBF (base diretta di questo articolo)

Sintesi

Questo articolo affronta la sfida unica del periodo di transizione della sicurezza quantistica di DNSSEC, proponendo una soluzione di firme doppie fattibile dal punto di vista ingegneristico. Attraverso un'intelligente progettazione della frammentazione a livello applicativo (identificazione z-bits, schema di offset TTL), risolve con successo il problema del superamento della dimensione massima del messaggio causato dalle firme doppie. Gli esperimenti dimostrano che l'overhead di prestazioni è controllabile (<9%), rendendolo adatto alla distribuzione pratica. Questo è un tipico caso di "ricerca guidata dall'ingegneria", dove sebbene l'innovazione teorica sia limitata, il valore ingegneristico è significativo, fornendo alla comunità DNS una soluzione di transizione tempestiva e pratica. Il valore principale dell'articolo risiede nella prima implementazione e verifica, piuttosto che nel breakthrough teorico, che è ugualmente importante nel campo della crittografia applicata. Si consiglia agli autori di integrare analisi di sicurezza formali e test di distribuzione su larga scala nei lavori successivi, e di promuovere l'open source del codice per aumentare l'impatto.