Analisi comparativa delle tecnologie DoH e DoT
Categories:
DNS over HTTPS (DoH) e DNS over TLS (DoT) sono due comuni metodi di trasporto DNS crittografati, che implementano la trasmissione sicura delle query DNS utilizzando diversi stack di protocolli. Lo standard DoT è definito da RFC 7858, mentre DoH è standardizzato da DNS Queries over HTTPS (DoH). Comprendere le differenze fondamentali tra queste due tecnologie richiede un’analisi a partire dalla struttura gerarchica dei protocolli di rete.
Struttura gerarchica dei protocolli di rete
Lo stack di protocolli di rete moderno adotta un design a strati, dove ogni livello fornisce funzionalità diverse. DNS, come protocollo di livello applicazione, non è legato a un metodo di trasporto specifico e può funzionare su vari protocolli di supporto.
Il livello applicazione (L7) include protocolli come HTTP/1.1, HTTP/2, HTTP/3, FTP e DNS. Vale la pena notare che la semantica di HTTP/3 rimane al livello applicazione, con QUIC che funge da trasporto sottostante. Il livello di sicurezza si trova tra il livello applicazione e il livello di trasporto, comprendendo principalmente TLS e le sue varianti. TLS funziona solitamente su TCP, come nel caso di HTTPS e DoT. DTLS è la versione datagram di TLS e può funzionare su UDP. Il protocollo QUIC è particolare perché integra direttamente l’handshake TLS 1.3 e la derivazione delle chiavi all’interno del protocollo.
QUIC può essere considerato un protocollo di livello L4.5; estende UDP fornendo capacità tradizionali del livello di trasporto. Il livello di trasporto (L4) include TCP, UDP e QUIC. Sebbene QUIC sia basato su UDP dal punto di vista dell’implementazione ingegneristica, fornisce affidabilità, controllo della congestione, multiplexing e handshake crittografato, quindi viene trattato ingegneristicamente come un protocollo di trasporto indipendente. Il livello di rete (L3) utilizza il protocollo IP (IPv4/IPv6) per il routing e l’inoltro dei pacchetti. Il livello di collegamento dati (L2) include tecnologie come Ethernet e Wi-Fi (802.11).
TLS, come mezzo di crittografia, opera tra il livello applicazione e quello di trasporto. Se si rimuove la crittografia TLS dal DoT, il DoT diventa essenzialmente DNS over TCP. Questo design a strati rende la crittografia un’opzione, non un vincolo obbligatorio del protocollo stesso.
Caratteristiche del Plain DNS
La forma più comune di DNS è chiamata Plain DNS e può funzionare su UDP o TCP. UDP è il metodo di trasporto più comune perché l’instaurazione della connessione è semplice e la velocità della prima query è elevata. Tuttavia, il punto debole di UDP è la sua inaffidabilità; i pacchetti possono essere facilmente persi nella rete. Sebbene TCP richieda più handshake e la velocità della prima connessione sia circa il 30% più lenta rispetto a UDP, una volta stabilita una connessione lunga, la sua velocità di risposta è identica a quella di UDP.
Gli ISP possono scegliere di scartare i pacchetti UDP per alleviare il carico sui dispositivi quando la rete è congestionata. In aree dove alcuni ISP hanno gravi problemi di perdita di pacchetti UDP, specificare l’uso di TCP per le query DNS potrebbe essere più vantaggioso. TCP ha un meccanismo di ritrasmissione; garantisce l’affidabilità della consegna dei dati anche in caso di perdita di pacchetti, mentre scartare pacchetti UDP non riduce il carico sui dispositivi dei piccoli ISP, ma introduce invece maggiore incertezza a causa dei tentativi di ripetizione.
Nidificazione del livello applicazione
Sia DNS che HTTP appartengono ai protocolli del livello applicazione; DoH è essenzialmente un protocollo del livello applicazione nidificato all’interno di un altro. DoH non è necessariamente DNS over HTTPS; l’uso di HTTP semplice è anche possibile, anche se DoH non crittografato è una richiesta in chiaro e non offre vantaggi rispetto al Plain DNS, venendo utilizzato solo in pochissimi scenari con requisiti speciali.
Teoricamente, DNS può essere trasportato su qualsiasi protocollo del livello applicazione; ad esempio, DNS over FTP è realizzabile, richiedendo solo lo sviluppo del server e del client corrispondenti. Questa flessibilità dimostra le possibilità di combinazione dei protocolli del livello applicazione.
flowchart TD
subgraph L7["应用层"]
A[DNS]
B[HTTP]
C[FTP]
end
subgraph Security["安全层"]
D[TLS]
E[DTLS]
end
subgraph Transport["传输层"]
F[TCP]
G[UDP]
H[QUIC]
end
subgraph L3["网络层"]
I[IP]
end
subgraph L2["数据链路层"]
J[Ethernet]
K[WiFi]
end
A --> D
B --> D
C --> D
D --> F
E --> G
H --> G
F --> I
G --> I
H --> I
I --> J
I --> K
style A fill:#e1f5ff
style B fill:#e1f5ff
style C fill:#e1f5ff
style D fill:#fff4e1
style E fill:#fff4e1
style F fill:#ffe1e1
style G fill:#ffe1e1
style H fill:#e1ffe1Nidificazione del livello di trasporto
Il protocollo QUIC si basa su UDP, fornendo al contempo servizi orientati alla connessione al livello di trasporto. QUIC implementa capacità del livello di trasporto già presenti in TCP, come la connessione orientata, il controllo della congestione, la ritrasmissione, il controllo del flusso, la frammentazione e il riassemblaggio. Rispetto a TCP, QUIC ha una latenza inferiore. Rispetto a UDP, QUIC è più avanzato e affidabile.
Relazioni di combinazione dei protocolli
Non c’è una relazione di vincolo necessaria tra il livello applicazione e il livello di trasporto; la crittografia può essere aggiunta o meno. HTTP può funzionare su TCP o su QUIC. DNS può funzionare su TCP, su UDP o su QUIC.
Basandoci su queste possibilità, possiamo riassumere le seguenti relazioni di combinazione. Plain DNS equivale a UDP o TCP più il protocollo DNS. HTTP/2 equivale a TCP più TLS 1.2 o TLS 1.3 più il protocollo HTTP. HTTP/3 equivale a QUIC più TLS 1.3 più il protocollo HTTP.
DoH (DNS over HTTPS) equivale a HTTP/2 o HTTP/3 più il protocollo DNS. DoT (DNS over TLS) equivale a TCP più TLS 1.2 o TLS 1.3 più il protocollo DNS. DoQ (DNS over QUIC) equivale a QUIC più TLS 1.3 più il protocollo DNS.
flowchart LR
subgraph DoT["DoT DNS over TLS"]
direction LR
T1[TCP] --> T2[TLS]
T2 --> T3[DNS]
end
subgraph DoH2["DoH over HTTP/2"]
direction LR
H1[TCP] --> H2[TLS]
H2 --> H3[HTTP/2]
H3 --> H4[DNS]
end
subgraph DoH3["DoH over HTTP/3"]
direction LR
Q1[QUIC] --> Q2[TLS 1.3]
Q2 --> Q3[HTTP/3]
Q3 --> Q4[DNS]
end
subgraph DoQ["DoQ DNS over QUIC"]
direction LR
D1[QUIC] --> D2[TLS 1.3]
D2 --> D3[DNS]
end
style T1 fill:#e3f2fd
style T2 fill:#fff3e0
style H1 fill:#e3f2fd
style H2 fill:#fff3e0
style Q1 fill:#e8f5e9
style Q2 fill:#fff3e0
style D1 fill:#e8f5e9
style D2 fill:#fff3e0Analisi delle prestazioni e della compatibilità
Una volta compresa la struttura gerarchica dei protocolli, possiamo analizzare i pro e i contro di DoH e DoT.
Il confronto tra TCP e QUIC deve essere discusso in combinazione con l’ambiente di rete effettivo degli ISP. QUIC è un protocollo più recente che risolve alcuni problemi delle reti datate, ma è comunque basato su UDP. Dal punto di vista della latenza di rete, i protocolli basati su QUIC hanno una latenza inferiore di circa il 35% rispetto a TCP; quindi DNS over HTTP/3 e DoQ (DNS over QUIC) sono teoricamente più performanti di DNS over HTTP/2 e DoT.
Tuttavia, nell’ambiente di rete reale esistono problemi di latenza di ritrasmissione causati dalla perdita di pacchetti. Gli ISP possono scegliere di scartare i pacchetti UDP durante la congestione di rete, e QUIC verrà identificato come UDP e scartato. Sebbene QUIC supporti la ritrasmissione, il ritardo introdotto da essa può far sì che la latenza effettiva di QUIC sia superiore a quella di TCP.
In termini di privacy e sicurezza, sia DoH che DoT sono traffico crittografato e non possono essere intercettati o manomessi. Riguardo al problema del blocco di DoT dopo essere stato identificato, è dovuto principalmente al fatto che l’impostazione del DNS crittografato di Android utilizza di default la porta 853, rendendo la porta 853 sensibile. DoT in sé è normale traffico crittografato e non viene identificato come traffico dedicato al DNS. In realtà, qualsiasi porta può fornire il servizio DoT; questo richiede app di terze parti su Android, mentre iOS supporta nativamente DoT su porte arbitrarie.
La scalabilità è un importante vantaggio di DoH. Rispetto al DNS incapsulato in HTTP e al Plain DNS, HTTP ha una scalabilità chiaramente superiore. I provider possono offrire innumerevoli servizi sulla porta 443, incluso DoH, ed estendere facilmente le funzionalità. DoT e DoQ generalmente richiedono una porta dedicata e la capacità di espansione si basa interamente sul Plain DNS. Questa è una differenza dal punto di vista del provider; per l’utente medio non c’è al momento una percezione evidente.
Riguardo alla velocità di elaborazione delle richieste DNS, la velocità di elaborazione di HTTP potrebbe effettivamente essere più lenta di alcuni cicli di clock della CPU rispetto al Plain DNS, ma questa differenza è trascurabile nell’uso pratico. In termini di compatibilità, DoH potrebbe diventare più mainstream grazie alla sua buona scalabilità per i provider.
Il supporto per il DNS crittografato nelle piattaforme attuali varia. I browser basati su kernel Chromium supportano DoH. Windows 11 supporta nativamente DoH. Android 8 e versioni successive supportano nativamente DoT. Android 11 e versioni successive supportano nativamente DoT e DoH. Il sistema macOS supporta nativamente DoT e DoH. Il sistema iOS supporta nativamente DoT e DoH.
Consigli per la scelta pratica
Per l’utente medio, usare DoH è più pratico di DoT. Rispetto a DoT, DoH fornisce una latenza migliore la maggior parte del tempo e una latenza simile per il resto. Rispetto a DoQ, DoH ha una latenza simile la maggior parte del tempo e una latenza migliore per il resto.
Questa conclusione presupponga che il provider offra il servizio DNS over HTTP/3. Se il provider non offre HTTP/3, non c’è una differenza significativa tra DoH e DoT. Quando la qualità della rete è buona, DoH utilizzerà automaticamente DoH/3 per ottenere una latenza inferiore; quando la qualità è scadente, degraderà automaticamente a HTTP/2. Questa capacità adattiva deve essere implementata dal provider, sebbene i principali provider l’abbiano generalmente implementata.
Si consiglia di provare NullPrivate, che supporta DoT e DoH/3, con funzioni native di blocco delle pubblicità e routing DNS. Se è necessario un self-hosting, è possibile utilizzare la sua libreria open source.
La scelta del protocollo di rete richiede la considerazione comprehensiva di molteplici fattori, inclusi la qualità della rete dell’ISP, il supporto del provider e la compatibilità dei dispositivi. Per la maggior parte degli utenti, DoH è una scelta eccellente che bilancia prestazioni, compatibilità e protezione della privacy.