3. Design Considerations (Considerazioni di progettazione)
Questa sezione e le sue sottosezioni presentano le linee guida di progettazione utilizzate per DoQ. Mentre tutte le altre sezioni di questo documento sono normative, questa sezione è di natura informativa.
3.1. Provide DNS Privacy (Fornire la privacy DNS)
DoT [RFC7858] definisce come mitigare alcuni dei problemi descritti in "DNS Privacy Considerations" [RFC9076] specificando come trasmettere messaggi DNS su TLS. I "Usage Profiles for DNS over TLS and DNS over DTLS" [RFC8310] specificano profili di utilizzo rigorosi e opportunistici per DoT, incluso come i resolver stub possono autenticare i resolver ricorsivi.
La configurazione della connessione QUIC include la negoziazione dei parametri di sicurezza utilizzando TLS, come specificato in "Using TLS to Secure QUIC" [RFC9001], abilitando la crittografia del trasporto QUIC. La trasmissione di messaggi DNS su QUIC fornirà essenzialmente le stesse protezioni della privacy di DoT [RFC7858], inclusi i profili di utilizzo rigorosi e opportunistici [RFC8310]. Ulteriori discussioni su questo argomento sono fornite nella sezione 7.
3.2. Design for Minimum Latency (Progettazione per la latenza minima)
QUIC è specificamente progettato per ridurre i ritardi indotti dal protocollo, con funzionalità quali:
-
Supporto per dati 0-RTT durante la ripresa della sessione.
-
Supporto per procedure avanzate di recupero della perdita di pacchetti come specificato in "QUIC Loss Detection and Congestion Control" [RFC9002].
-
Mitigazione del blocco head-of-line consentendo la consegna parallela di dati su più flussi.
Questo mapping di DNS su QUIC sfrutterà queste funzionalità in tre modi:
-
Supporto opzionale per l'invio di dati 0-RTT durante la ripresa della sessione (le implicazioni sulla sicurezza e sulla privacy sono discusse nelle sezioni successive).
-
Connessioni QUIC di lunga durata su cui vengono eseguite più transazioni DNS, generando il traffico sostenuto richiesto per beneficiare delle funzionalità di recupero avanzate.
-
Mappatura di ogni transazione di query/risposta DNS su un flusso separato, per mitigare il blocco head-of-line. Ciò consente ai server di rispondere alle query "fuori ordine". Consente inoltre ai client di elaborare le risposte non appena arrivano, senza dover attendere la consegna in ordine delle risposte precedentemente inviate dal server.
Queste considerazioni si riflettono nel mapping del traffico DNS ai flussi QUIC nella sezione 4.2.
3.3. Middlebox Considerations (Considerazioni sui middlebox)
L'uso di QUIC potrebbe consentire a un protocollo di mascherare il suo scopo dai dispositivi sul percorso di rete utilizzando tecniche di resistenza alla crittografia e all'analisi del traffico come il padding, il pacing del traffico e lo shaping del traffico. Questa specifica non include alcuna misura progettata per evitare tale classificazione; i meccanismi di padding definiti nella sezione 5.4 sono destinati a offuscare i record specifici contenuti nelle query e risposte DNS, ma non il fatto che si tratti di traffico DNS. Di conseguenza, i firewall e altri middlebox potrebbero essere in grado di distinguere DoQ da altri protocolli che utilizzano QUIC, come HTTP, e applicare un trattamento diverso.
La mancanza di misure in questa specifica per evitare la classificazione del protocollo non è un'approvazione di tali pratiche.
3.4. No Server-Initiated Transactions (Nessuna transazione avviata dal server)
Come indicato nella sezione 1, questo documento non specifica il supporto per transazioni avviate dal server all'interno di connessioni DoQ stabilite. Cioè, solo l'iniziatore della connessione DoQ può inviare query sulla connessione.
DSO supporta transazioni avviate dal server all'interno di connessioni esistenti. Tuttavia, DoQ come definito qui non soddisfa i criteri per un trasporto applicabile per DSO perché non garantisce la consegna in ordine dei messaggi; vedere la sezione 4.2 di [RFC8490].