DoH3, DoQ e DoT: cosa cambia a fine 2025

Di CaptainDNS
Pubblicato il 1 dicembre 2025

#DNS
#DoH
#DoT
#DoQ
#Sicurezza

Schema che confronta DoH3, DoQ e DoT in un'architettura DNS moderna

TL;DR

DoT è diventato il pilastro ampiamente distribuito del DNS cifrato, mentre DoH3 e DoQ generalizzano QUIC per il trasporto delle query.
A fine 2025 sempre più sistemi operativi, browser e resolver attivano il DNS cifrato di default, riducendo la visibilità sul classico porta 53.
Queste evoluzioni impattano direttamente l'architettura DNS aziendale: resolver, firewall, proxy, osservabilità e conformità devono essere adattati.
L'approccio corretto non è “scegliere un vincitore”, ma definire una strategia multi-trasporto: DoT come base, DoH3 e DoQ per i casi in cui latenza, resilienza e mobilità sono critici.

Contesto: dal DNS in chiaro al DNS cifrato

Per decenni la risoluzione DNS è avvenuta principalmente in chiaro su UDP/TCP 53. Semplificava debug e filtraggio di rete, ma lasciava spazio ad ascolto, iniezione di risposte e profilazione massiva del traffico.

Con la spinta sulla privacy e la diffusione di TLS sul web, il DNS ha seguito la stessa traiettoria: cifrare l'“ultimo miglio” tra client (stub resolver) e resolver ricorsivo, e più recentemente adottare trasporti moderni come QUIC.

A fine 2025, tre elementi definiscono il panorama del DNS cifrato per il flusso client → resolver: DoT, DoH (incluso DoH3) e DoQ. Capire le differenze è essenziale per anticipare gli effetti sulle architetture.

Promemoria rapido: DoT, DoH, DoH3 e DoQ

DNS classico (UDP/TCP 53)

Il DNS storico si basa su UDP 53 per la maggior parte delle query, con fallback TCP 53 per i trasferimenti di zona (XFR) e risposte voluminose. È semplice e veloce, ma totalmente in chiaro: un osservatore di rete può vedere i domini risolti, iniettare risposte false o bloccare alcune query.

DNS over TLS (DoT)

DoT incapsula il DNS in un flusso TLS (tipicamente su TCP 853) tra client e resolver. Standardizzato nell'RFC 7858, mira a impedire ascolto e manipolazione delle query lungo il percorso di rete.

In pratica, DoT:

utilizza un canale TCP/TLS dedicato (porta 853);
offre proprietà di riservatezza simili a un HTTPS “classico”;
è ampiamente supportato dai principali resolver pubblici e da molti resolver ricorsivi open source.

Oggi DoT è la base più matura per il DNS cifrato lato infrastruttura, soprattutto perché resta concettualmente vicino al duo DNS + TLS già conosciuto.

DNS over HTTPS (DoH) e DoH3

DoH trasporta le query DNS sopra HTTPS (RFC 8484), quindi sulla porta 443, in un canale HTTP/2 o HTTP/3. Il messaggio DNS è incapsulato nel body della richiesta HTTP, permettendo di sfruttare l'intera stack web: proxy HTTP, autenticazione, CDN, ecc.

Quando DoH è usato sopra HTTP/3 (a sua volta basato su QUIC), si parla spesso di “DoH3”:

stessa semantica DNS di DoH;
stessa porta 443 del traffico web, rendendo il filtraggio più complesso;
stessi benefici di QUIC: 0-RTT possibile, migliore gestione delle perdite, multiplexing efficiente.

DoH3 interessa in particolare browser e alcune applicazioni, perché consente di mascherare il DNS nel flusso HTTPS esistente, beneficiando al contempo di QUIC.

DNS over QUIC (DoQ)

DoQ usa QUIC direttamente come trasporto DNS, senza passare per HTTP. Definito nell'RFC 9250, mira a combinare:

le proprietà di riservatezza di un canale TLS (come DoT);
le prestazioni e la resilienza di QUIC: niente head-of-line blocking a livello di trasporto, migliore recupero in caso di perdita di pacchetti, supporto nativo di 0-RTT e mobilità della connessione.

In pratica:

DoQ utilizza tipicamente la porta UDP 853, già associata storicamente a DNS-over-TLS/DTLS;
ogni connessione QUIC può trasportare più query DNS multiplexate;
il protocollo è particolarmente adatto ad ambienti con latenza variabile (wifi denso, mobile, ecc.).

Cosa cambia davvero a fine 2025

La novità non è l'esistenza di DoT, DoH o DoQ—tutti standardizzati da anni—ma il loro livello di deployment e di attivazione di default.

In sintesi:

DoT è il “baseline” del DNS cifrato per resolver ricorsivi e servizi gestiti.
DoH è ampiamente supportato da browser, OS e librerie applicative, con una crescita dell'uso di HTTP/3 (DoH3).
DoQ esce progressivamente dall'ambito sperimentale per diventare un'opzione seria su diversi server ricorsivi moderni, soprattutto in ambienti sensibili a latenza e resilienza.

Queste tendenze hanno varie conseguenze concrete per i team di rete/DNS.

1. QUIC diventa un trasporto DNS di primo piano (DoH3 e DoQ)

L'adozione di QUIC non riguarda più solo il traffico web: una quota crescente delle risoluzioni DNS tra client e resolver passa ormai tramite HTTP/3 (DoH3) o DoQ.

Impatti chiave:

Latenza: la combinazione 0-RTT + assenza di head-of-line blocking sul trasporto migliora il tempo di risoluzione percepito, soprattutto su reti con perdita o latenza variabile.
Stabilità: QUIC gestisce meglio il cambio di indirizzo IP (roaming wifi ↔ 4G/5G) mantenendo la connessione logica.
Superficie di filtraggio: bloccare “il DNS” non significa più solo ispezionare UDP/TCP 53; vanno considerati QUIC su 443 (DoH3) e UDP 853 (DoQ).

Per un'architettura aziendale, le decisioni di filtraggio DNS devono considerare i trasporti, non solo le porte storiche.

2. Generalizzazione del DNS cifrato in OS e browser

I sistemi moderni (desktop, mobile, server) offrono ora opzioni native per attivare DoT o DoH, talvolta a livello di sistema, talvolta per applicazione (browser, client VPN, agente di sicurezza).

Conseguenze:

Alcune postazioni possono iniziare a bypassare il resolver aziendale per interrogare direttamente un resolver pubblico in DoH3/DoT.
A seconda delle politiche, ciò può entrare in conflitto con esigenze di logging, conformità o filtraggio (proxy di sicurezza, DLP, ecc.).
I team IT devono decidere chiaramente: quali flussi sono autorizzati verso resolver esterni, su quali trasporti e in quali casi?

3. Osservabilità e debug più complessi

Con il DNS cifrato non è più possibile ispezionare il contenuto delle query a livello di rete tra client e resolver senza una terminazione TLS/QUIC controllata.

Questo impatta:

gli strumenti di cattura e analisi del traffico (tcpdump, Wireshark, sonde NDR);
i processi di debug “d'emergenza” (filtraggio inatteso, TTL incoerenti, differenze di cache tra resolver interni ed esterni);
la correlazione tra log DNS e log applicativi.

L'approccio raccomandato: spostare parte dell'osservabilità sul resolver (log strutturati, metriche, trace) invece di puntare solo al livello pacchetto.

4. Maggiore maturità delle implementazioni lato server

I principali resolver ricorsivi open source (e commerciali) offrono ormai implementazioni stabili di DoT, spesso DoH e sempre più DoQ. Questo permette di:

distribuire un resolver interno o “split-horizon” che accetta più trasporti (UDP/TCP 53, DoT, eventualmente DoH/DoQ);
separare il modo in cui i client si connettono da quello usato per interrogare i server autoritativi;
evolvere progressivamente le postazioni client senza rompere l'architettura DNS complessiva.

Confronto rapido DoT / DoH3 / DoQ

Ecco una tabella sintetica per posizionare questi tre trasporti nel tuo design.

Protocollo	Trasporto sottostante	Porta tipica	Multiplexing	Mascherato nel traffico web	Casi d'uso tipici
DoT	TLS su TCP	853/TCP	Limitato al flusso TCP singolo	No	Baseline DNS cifrato tra client/forwarder e resolver aziendali o pubblici
DoH3	HTTP/3 (QUIC) su UDP	443/UDP	Sì, via HTTP/3	Sì (difficile da distinguere dall'HTTPS)	Browser, applicazioni che vogliono integrarsi nella stack HTTP esistente
DoQ	QUIC nativo su UDP	853/UDP	Sì, multiplexing QUIC	No (ma simile a QUIC generico)	Resolver ricorsivi moderni; ambienti sensibili a latenza e resilienza

Da sapere: in tutti i casi questi protocolli non sostituiscono DNSSEC (che protegge l'integrità dei dati DNS tra resolver e autorità), ma lo completano proteggendo la riservatezza e l'integrità del trasporto tra client e resolver.

Impatti architetturali sulle infrastrutture DNS

Flussi DNS cifrati tra client, resolver aziendale e resolver pubblici

Questo schema illustra un'architettura tipica a fine 2025:

A sinistra, il client (postazione, mobile, server) dispone di uno stub resolver che può parlare DNS classico (UDP/TCP 53), DoT, DoH3 o DoQ.
Al centro, uno o più resolver aziendali terminano questi trasporti, applicano cache, split-horizon e filtraggio.
A destra, i resolver pubblici e i server autoritativi sono raggiunti in DNS classico o DNS cifrato a seconda della policy.

La domanda chiave diventa: quali flussi client → resolver aziendale → resolver pubblici sono autorizzati, cifrati e osservabili?

Resolver pubblici vs resolver aziendali

A fine 2025 è frequente che una stessa postazione possa:

usare il resolver interno aziendale in UDP/TCP 53 o DoT;
in parallelo interrogare uno o più resolver pubblici in DoH3 o DoQ tramite applicazioni specifiche (browser, agente di sicurezza, client VPN).

Domande di architettura:

Le postazioni devono obbligatoriamente usare i resolver aziendali per ogni risoluzione?
I resolver aziendali esporranno DoT e/o DoQ ai client interni?
I flussi DoH/DoH3 verso resolver pubblici sono autorizzati, bloccati o reindirizzati (proxy, intercettazione TLS controllata)?

Anycast, CDN e geolocalizzazione

Con il DNS cifrato, i grandi resolver pubblici usano ampiamente Anycast e ripartiscono le connessioni QUIC/TLS in base alla posizione del client. Questo può portare a:

differenze di risoluzione (diversi ingressi CDN secondo l'IP sorgente visto dal resolver);
differenze tra ciò che vede un client in DoH3/DoQ e un altro in UDP 53 verso un resolver diverso;
effetti collaterali quando un proxy o una VPN modifica l'IP sorgente.

Per applicazioni sensibili a latenza o geolocalizzazione (video, gaming, API critiche) può essere utile documentare chiaramente quale resolver è atteso e quale trasporto è consigliato.

Osservabilità, log e conformità

In un mondo in cui il DNS è cifrato di default, la buona pratica è:

centralizzare i log a livello dei resolver (query, risposte, codici d'errore, tempi di risoluzione);
esporre metriche (Prometheus, OpenTelemetry, ecc.) per seguire latenza, errori e volumi per trasporto (UDP, DoT, DoH3, DoQ);
definire cosa si registra per rispettare GDPR e policy interne di privacy.

In altre parole: invece di “sniffare la porta 53”, è necessario attrezzare i resolver.

Sicurezza e controllo accessi

I controlli di sicurezza vanno ripensati:

filtraggio in uscita: quali port/host sono autorizzati per DoT (853), DoQ (853/UDP), DoH3 (443/QUIC)?
segmentazione: quali segmenti di rete possono uscire verso resolver pubblici, quali devono passare obbligatoriamente da un resolver interno?
rilevazione: come individuare una postazione che invia DNS cifrato non autorizzato direttamente a Internet?

Un design robusto combina generalmente:

uno o più resolver interni che espongano almeno DoT;
policy chiare (e applicate) sui flussi DNS cifrati in uscita;
un monitoraggio regolare dei tentativi di risoluzione “fuori perimetro”.

Checklist tecnica a fine 2025

Questa checklist aiuta a valutare rapidamente il livello di preparazione.

Livello	Punto di controllo	Domanda da porsi
Resolver interno	Supporto DoT (e eventualmente DoQ)	I miei resolver interni offrono almeno DoT ai client?
Firewall / proxy	Policy su 53/853/443	Ho regole esplicite per il DNS cifrato (DoT, DoH3, DoQ) e non solo per UDP/TCP 53?
Postazioni client	Configurazione DNS	Chi controlla la configurazione DNS di OS e browser (GPO, MDM, script, ecc.)?
Osservabilità	Log e metriche DNS	Posso correlare un disservizio applicativo con metriche DNS cifrate (latenza, timeout, errori)?
Conformità	Tracciabilità	Ho una risposta chiara a “chi ha risolto cosa, quando, tramite quale resolver” rispettando la riservatezza?

Puoi anche scaricare il confronto in CSV (vedi blocco di download dell'articolo) per usarlo nei tuoi dashboard o documenti interni.

Piano d'azione raccomandato per i team infra

Mappare l'esistente
- Quali resolver vengono usati (interni, esterni)?
- Quali trasporti sono già in produzione (UDP/TCP 53, DoT, DoH, tunnel VPN, ecc.)?
Definire un obiettivo chiaro
- DoT come base obbligatoria tra postazioni e resolver interni.
- DoH3 e/o DoQ attivati in modo controllato, secondo i casi d'uso (mobilità, performance, vincoli applicativi).
Aggiornare i resolver
- Attivare DoT con priorità, con certificati gestiti correttamente.
- Valutare DoQ in un ambiente pilota (latenza, stabilità, osservabilità).
Adattare il filtraggio di rete
- Formalizzare una policy sui flussi DNS cifrati in uscita.
- Documentare le eccezioni (relay DNS di un partner, sito remoto, agente di sicurezza).
Impostare l'osservabilità
- Centralizzare i log DNS a livello dei resolver.
- Monitorare volumi e latenza per trasporto (UDP, DoT, DoH3, DoQ).
Comunicare con i team applicativi
- Spiegare i cambiamenti (nuove porte, nuovi resolver, possibili comportamenti dei browser).
- Documentare le best practice per la scelta dei resolver nelle applicazioni.
Testare regolarmente
- Script o job di monitoraggio che testino la risoluzione tramite ogni trasporto (UDP, DoT, DoH3, DoQ) verso i resolver chiave.
- Analisi delle differenze di latenza e comportamento (timeout, errori sporadici).

FAQ

Devo migrare tutto a DoQ e abbandonare DoT?

No. DoQ non sostituisce bruscamente DoT, ma è un'opzione in più. In pratica, la maggior parte delle architetture resterà multi-trasporto: UDP/TCP 53 per compatibilità, DoT come base cifrata, DoH3 e/o DoQ per perimetri mirati (mobilità, performance, vincoli applicativi).

DoH3 e DoQ sono più sicuri di DoT?

Dal punto di vista crittografico, le tre opzioni si basano su primitive simili (TLS o QUIC su TLS) e offrono un livello di riservatezza comparabile. Le differenze sono sul trasporto: multiplexing, gestione delle perdite, camuffamento nel traffico web, capacità di attraversare alcuni middlebox.

Quali porte devo aprire nei firewall per questi protocolli?

In generale: DoT usa 853/TCP, DoQ 853/UDP, DoH/DoH3 la porta 443 (TCP e/o UDP a seconda di HTTP/2 o HTTP/3). La politica di apertura va ragionata: autorizzare sempre queste porte verso Internet permette alle postazioni di bypassare i resolver interni.

Il DNS cifrato rompe il mio filtraggio DNS esistente?

Può aggirarlo se le postazioni interrogano direttamente resolver pubblici in DoH3/DoT/DoQ. Per questo è cruciale definire una policy chiara: quali flussi DNS cifrati sono autorizzati, quali devono passare obbligatoriamente da un resolver aziendale e come rilevare le deviazioni.

Come verifico se il mio resolver supporta DoT, DoH3 o DoQ?

In genere ogni implementazione documenta comandi di esempio (con kdig, drill, curl per DoH o client specifici DoQ). Puoi integrare questi test nelle procedure di validazione e negli script di monitoraggio per assicurarti che ogni trasporto funzioni come previsto.