In breve: il DNS classico (il protocollo del 1987) invia le query in chiaro tramite UDP sulla porta 53. Chiunque si trovi nel percorso di rete può leggere ogni dominio che stai cercando, modificare le risposte o bloccare query specifiche. DoT (RFC 7858, 2016) avvolge le query DNS in TLS sulla porta 853. DoH (RFC 8484, 2018) le inserisce all'interno di richieste HTTPS sulla porta 443. Entrambi risolvono il problema del testo in chiaro. Divergono su chi controlla il deployment, chi può vedere le query e chi può bloccarle — ed è proprio questa la domanda che la maggior parte delle persone si pone davvero quando chiede "quale dovrei usare". Dipende da cosa stai cercando di proteggere.
Cosa risolve la crittografia DNS — e cosa no
Prima di confrontare i due protocolli, vale la pena chiarire cosa protegge in realtà ciascuno di essi. Il DNS classico espone ogni nome di dominio cercato dal tuo dispositivo. Se visiti example.com, il tuo ISP — o qualsiasi operatore di rete nel percorso — può vedere la query per example.com, ancora prima che il browser invii la prima richiesta HTTPS. Il contenuto effettivo di quella richiesta HTTPS è cifrato; la ricerca DNS che l'ha preceduta non lo è. Il DNS cifrato colma esattamente questa lacuna.
Quello che non risolve: l'indirizzo IP di destinazione a cui ti connetti rimane visibile. Anche il campo TLS Server Name Indication (SNI), nelle versioni TLS più vecchie, espone il nome host durante l'handshake — sebbene Encrypted Client Hello (ECH) affronti questo problema in TLS 1.3. DNS cifrato più ECH chiude le fughe più evidenti. Senza ECH, il DNS cifrato da solo chiude una fuga ma lascia aperta quella SNI, il che significa che il nome host di destinazione è ancora visibile durante l'handshake TLS. La valutazione onesta: il DNS cifrato è necessario ma non sufficiente.
Come funziona DoT — canale dedicato sulla porta 853
DoT (DNS-over-TLS, definito in RFC 7858) è il design concettualmente più semplice. Il tuo dispositivo apre una connessione TCP al server DNS sulla porta 853. Esegue un handshake TLS — lo stesso TLS che protegge HTTPS — e poi invia query DNS standard all'interno del flusso cifrato. Il server DNS risponde con risposte DNS standard, anch'esse all'interno del flusso cifrato. Dal punto di vista del traffico di rete, tutto ciò che si vede è una connessione TLS verso la porta 853.
Poiché la porta 853 è ufficialmente assegnata dall'IANA esclusivamente a DoT, qualsiasi traffico TCP su quella porta è inequivocabilmente DoT. Gli operatori di rete possono identificare DoT in modo banale — non hanno bisogno di un'ispezione approfondita dei pacchetti, basta guardare la porta di destinazione. Se vogliono bloccare DoT, eliminano la porta 853. Se vogliono consentirlo ma registrare l'IP del server DNS di destinazione, anche questo è semplice. DoT è onesto riguardo all'essere DNS, il che è un vantaggio per certi casi d'uso e uno svantaggio per altri.
Come funziona DoH — DNS nascosto nel traffico web
DoH (DNS-over-HTTPS, definito in RFC 8484) adotta un approccio diverso. Il tuo dispositivo invia le query DNS come richieste HTTP POST (o richieste GET con il parametro di query) a un URL specifico sul server HTTPS del provider DNS. Il corpo del POST contiene un messaggio DNS binario; il corpo della risposta contiene una risposta DNS binaria. L'intera operazione avviene su una normale connessione HTTPS sulla porta 443 — la stessa porta che il tuo browser usa per caricare le pagine web.
Dal punto di vista della rete, una richiesta DoH è indistinguibile da una normale richiesta HTTPS allo stesso server. La connessione sembra traffico web. Le dimensioni dei pacchetti sembrano traffico web (dopo la query iniziale, le query successive riutilizzano la stessa connessione HTTP/2 o HTTP/3). L'IP di destinazione appartiene a un endpoint dall'aspetto generico — il 1.1.1.1 di Cloudflare o il 8.8.8.8 di Google gestiscono sia DoH che altro traffico web sugli stessi IP. Per bloccare DoH nello specifico, un operatore di rete deve identificare e bloccare gli endpoint specifici, il che è molto più difficile che bloccare una porta.
Differenze di visibilità sulla rete
La differenza di trasporto produce una differenza di visibilità. Con DoT, il tuo operatore di rete (IT aziendale, ISP, scuola, hotel) può vedere che stai usando DNS cifrato, può vedere quale server DoT stai usando (tramite l'IP di destinazione) e può scegliere di bloccare quel server. Con DoH, l'operatore di rete vede traffico HTTPS cifrato verso l'IP del provider DNS, ma a meno che non mantenga specificamente blocklist di endpoint DoH, non riesce a distinguere DoH dal normale HTTPS verso lo stesso provider.
Questo produce conseguenze prevedibili. I reparti IT aziendali hanno preferito DoT per anni perché possono bloccarlo facilmente: eliminano la porta 853 e il DNS torna al resolver dell'organizzazione, che monitorano e filtrano. Tendono a non gradire DoH per la stessa ragione — aggira la loro visibilità. I sostenitori della privacy dei consumatori preferiscono DoH per lo stesso motivo. Parti diverse vogliono risultati diversi dalla stessa scelta architetturale.
Quale dei due le reti possono bloccare
DoT è facile da bloccare. La porta 853 è l'unica cosa che usa quella porta; una regola firewall per eliminarla e il gioco è fatto. Molte reti aziendali lo fanno già. Anche molti firewall di filtraggio in regioni con forti restrizioni lo fanno. Se configuri un dispositivo per usare DoT e quella rete blocca la porta 853, le query DNS del dispositivo falliscono finché il sistema operativo o l'app non torna al DNS in chiaro — e la maggior parte lo fa silenziosamente.
DoH è molto più difficile da bloccare perché l'unico modo per farlo è identificare e inserire in una blocklist ogni endpoint DoH. Il 1.1.1.1 di Cloudflare è il più noto ed è di solito in quella blocklist; lo stesso vale tipicamente per il 8.8.8.8 di Google. Ma gli endpoint DoH gestiti in modo indipendente proliferano — liste pubbliche come la wiki DoH di curl ne catalogano centinaia. Un operatore di rete che vuole bloccare DoH globalmente deve tenere aggiornata quella lista e accettare di essere sempre un passo indietro rispetto ai nuovi endpoint. Alcune reti con forti restrizioni cercano di rilevare DoH tramite l'analisi dei pattern di traffico (DoH ha caratteristiche distinctive di dimensione delle richieste e temporizzazione), ma questo approccio è fragile e produce falsi positivi.
La documentazione Mozilla su DoH cita esplicitamente questa proprietà — che DoH è difficile da bloccare per le reti — come un obiettivo di design deliberato, non un caso. La stessa proprietà rende DoH controverso in contesti aziendali, dove l'operatore di rete considera la visibilità DNS una parte legittima del proprio stack di sicurezza piuttosto che una violazione della privacy degli utenti.
Implicazioni per le aziende e il controllo parentale
Il filtraggio a livello DNS (quello che alimenta la maggior parte dei software di controllo parentale, il filtraggio aziendale "safe browsing" e le forme più semplici di blocco dei domini malware) funziona intercettando le query DNS e o eliminando quelle per i domini bloccati o restituendo risposte false. Abbiamo analizzato la meccanica nel nostro articolo su come funziona il filtraggio a livello DNS.
Il DNS cifrato aggira tutto questo — sia DoT che DoH indirizzano le query a un resolver diverso da quello della rete locale, quindi qualsiasi filtraggio applicato al resolver locale è irrilevante. Dal punto di vista del fornitore di controllo parentale, questo è un problema. Dal punto di vista dell'utente, dipende interamente dal fatto che il filtraggio sia considerato legittimo o invasivo. La maggior parte degli strumenti di gestione degli endpoint aziendali ora disabilita DoH del browser tramite policy e si affida alla configurazione DNS a livello di sistema operativo o all'ispezione completa del traffico per mantenere la visibilità. I profili iOS gestiti tramite MDM di Apple includono un meccanismo di configurazione DoH/DoT progettato esattamente per questo: l'azienda può specificare un resolver DNS cifrato di propria scelta e impedire agli utenti di sovrascriverlo.
Per le famiglie, la realtà pratica è che attivare DoH in un browser aggira qualsiasi filtraggio dei contenuti basato sul router che hai configurato. Si tratta di una funzionalità o di un difetto a seconda di quale lato della configurazione ti trovi.
Caratteristiche di performance
DoT ha in genere un overhead per query leggermente inferiore rispetto a DoH. Entrambi i protocolli usano TLS, ma DoT invia un involucro molto più piccolo attorno a ogni messaggio DNS — non c'è riga di richiesta HTTP, non ci sono header, nessun Content-Length, nessun metodo HTTP. Il messaggio DNS va direttamente nel flusso TLS. DoH, al contrario, avvolge ogni query DNS all'interno di un HTTP POST o GET, aggiungendo decine o centinaia di byte di overhead per query.
Quell'overhead viene per lo più ammortizzato dal riutilizzo della connessione. Sia DoT che DoH mantengono la connessione TLS aperta su molte query, quindi il costo dell'handshake viene pagato una sola volta. DoH su HTTP/2 effettua il multiplexing delle query sulla stessa connessione, e HTTP/3 (su QUIC) riduce ulteriormente la latenza. In pratica, su una rete moderna, i due protocolli producono una latenza indistinguibile per l'utente — al massimo una differenza di pochi millisecondi. Non scegliere uno rispetto all'altro per ragioni di performance; la scelta riguarda la visibilità, il controllo e il modello di minaccia.
DoT vs DoH a colpo d'occhio
| Proprietà | DNS-over-TLS (DoT) | DNS-over-HTTPS (DoH) |
|---|---|---|
| Porta | 853 (dedicata) | 443 (condivisa con HTTPS) |
| RFC | RFC 7858 (2016) | RFC 8484 (2018) |
| Trasporto | TLS grezzo su TCP | HTTPS (HTTP/2 o HTTP/3) |
| Identificabile sul traffico | Sì — la porta 853 è esclusiva di DoT | No — appare come normale HTTPS |
| Bloccabilità dalla rete | Facile (elimina la porta 853) | Difficile (richiede una blocklist di endpoint) |
| Supporto browser | No (i browser non implementano DoT) | Firefox, Chrome, Edge, Safari lo supportano tutti |
| Supporto OS | Android 9+, iOS 14+, macOS 11+, Linux (systemd-resolved) | Android 9+, iOS 14+, macOS 11+, Windows 11+ |
| Visibilità aziendale | Visibile dalla porta; facile da monitorare o bloccare | Aggira il monitoraggio basato sulle porte; richiede l'ispezione degli endpoint |
| Overhead di latenza per query | Inferiore (involucro minimo) | Leggermente superiore (header HTTP); trascurabile con il multiplexing HTTP/2 |
| Resistenza alla censura | Bassa (bloccabile tramite porta) | Più alta (la porta 443 è essenziale per il web moderno) |
Quale usare — tre scenari
"Quale protocollo è migliore" dipende interamente da cosa stai cercando di ottenere. Ecco tre scenari concreti con risposte concrete:
Scenario 1: Dispositivo personale su reti ostili o non attendibili
Bar, hotel, aeroporti, Wi-Fi di amici. Il modello di minaccia è l'operatore di rete locale che osserva o modifica il tuo DNS. Entrambi i protocolli funzionano per la crittografia in sé; DoH è preferibile perché è molto più difficile per una rete ostile bloccarlo. Se usi DoT su una rete che elimina la porta 853, le tue query tornano silenziosamente in chiaro sulla porta 53 (la maggior parte dei client OS funziona così in modalità fail-open) — e hai esposto tutto quello che stavi cercando di proteggere. DoH raggiunge quasi sempre il suo endpoint.
Scenario 2: Rete domestica con dispositivi dei figli gestiti
Vuoi che i dispositivi dei tuoi figli usino un resolver DNS con filtraggio (NextDNS, OpenDNS Family Shield, Cloudflare for Families) e che non possano aggirarlo. DoT è in realtà più comodo qui — configuri il dispositivo per usare uno specifico resolver DoT, e il bambino non può semplicemente cambiare un'impostazione nel browser per usare un DNS diverso. DoH nel browser può essere disabilitato tramite policy MDM o aziendale, o impostando il dominio canary. La scelta tra DoT e DoH è meno importante che configurare il DNS del dispositivo a livello di sistema operativo piuttosto che lasciare che le singole app decidano.
Scenario 3: Stai già usando una VPN
Se usi una VPN, la rete locale non può vedere le tue query DNS in ogni caso — il tunnel VPN cifra tutto, DNS incluso. La domanda rilevante diventa quale resolver DNS usa la VPN internamente e se supporta il DNS cifrato verso il proprio resolver upstream. La maggior parte delle VPN moderne (incluso Casper's Cloak) usa DNS cifrato internamente e applica il filtraggio threat shield al resolver prima di inviare la risposta attraverso il tunnel. In questa configurazione, DoT vs DoH è per lo più un dettaglio implementativo; ciò che conta è che il resolver non sia il tuo ISP e non registri le tue query.
La questione della fiducia che entrambi i protocolli aggirano
Sia DoT che DoH spostano la fiducia dal tuo operatore di rete locale al provider DNS cifrato che scegli. Cloudflare, Google, Quad9, NextDNS, ControlD — ognuna di queste aziende vede ogni query DNS che gli invii. La crittografia nei loro confronti non significa privacy nei loro confronti. Se la tua preoccupazione è che il tuo ISP non debba vedere il tuo DNS, il DNS cifrato risolve il problema. Se la tua preoccupazione è che nessuna terza parte debba vedere il tuo DNS, nessuno dei due protocolli ti aiuta; devi gestire il tuo resolver ricorsivo (che è un progetto a parte).
Quello che puoi pretendere dal resolver di cui ti fidi: una chiara policy di registrazione, audit di terze parti, supporto per la minimizzazione delle query (in modo che i server autoritativi upstream vedano solo le parti della query di cui hanno bisogno) e la validazione DNSSEC. I principali provider pubblici DoH/DoT pubblicano tutti le loro policy; leggile. La nostra guida più approfondita su questo argomento si trova nel nostro articolo DoH del 2026.
In sintesi
DoT e DoH risolvono lo stesso problema fondamentale — le fughe di DNS in chiaro che espongono le tue destinazioni di navigazione alla rete — con due strategie architetturali diverse. DoT è il design trasparente: una porta dedicata, facile da identificare, facile da gestire, facile da bloccare. DoH è il design camuffato: nascosto nel traffico HTTPS, difficile da identificare senza blocklist di endpoint, difficile da bloccare su larga scala.
Per i consumatori su reti ostili, DoH è la scelta giusta perché è quello che riesce effettivamente a raggiungere il proprio endpoint. Per le aziende che hanno bisogno di visibilità DNS, DoT è la scelta più cooperativa. Per chi gestisce il proprio DNS di filtraggio a casa, DoT è più configurabile e più difficile da aggirare per gli utenti a livello di app. Per gli utenti VPN, la scelta è per lo più invisibile — il client VPN se ne occupa.
La vera domanda è raramente "DoT o DoH" — è "a quale resolver mi sto fidando, e qual è la sua policy di registrazione". Scegli un resolver di cui ti fidi, configuralo a livello di sistema (non per singolo browser) e verifica con un test di DNS leak che la configurazione sia effettivamente corretta. Il protocollo che usi per parlare con esso è meno importante della policy dell'entità all'altro capo.