DoH vs DoT: qual è la differenza tra DNS over HTTPS e DNS over TLS?

Ogni volta che clicchi su un link o digiti un indirizzo nel browser, il tuo dispositivo invia una richiesta di risoluzione a un resolver ricorsivo. Per decenni, i server DNS tradizionali hanno elaborato queste richieste tramite UDP e TCP in chiaro sulla porta 53. Poiché questo traffico è completamente non crittografato, chiunque si trovi lungo il percorso di comunicazione può monitorare le tue abitudini di navigazione o manipolare le risposte che ricevi.

Per colmare questa persistente lacuna di sicurezza, l’Internet Engineering Task Force (IETF) ha standardizzato due distinti protocolli di trasporto crittografici: DNS over TLS (DoT) e DNS over HTTPS (DoH). Sebbene entrambi i protocolli crittografino le richieste di dominio tra il client e un resolver, operano a livelli diversi dello stack di rete e producono risultati molto diversi in termini di controllo della rete aziendale, privacy degli utenti e gestione delle minacce.

Ma perché crittografare il DNS?

Il DNS in chiaro rimane una delle maggiori vulnerabilità strutturali dell'architettura Internet tradizionale. Quando le query transitano su connessioni pubbliche o non affidabili senza crittografia, espongono gli utenti e le organizzazioni a tre rischi principali:

1. Intercettazione passiva: qualsiasi entità in grado di monitorare il traffico di rete — inclusi i fornitori di servizi Internet (ISP), gli operatori di reti Wi-Fi pubbliche e i programmi di sorveglianza — può registrare ogni ricerca di dominio effettuata dal tuo dispositivo. Anche se il traffico web successivo utilizza il protocollo HTTPS, le tue query DNS rivelano comunque esattamente con quali servizi, app e domini interagisci.

2. Manomissione e intercettazione lungo il percorso: gli aggressori che condividono una rete locale possono intercettare le richieste in chiaro e inserire risposte falsificate, una tattica nota come attacco “man-in-the-middle”. Ciò consente a un avversario di reindirizzare il traffico legittimo verso un’infrastruttura dannosa senza allertare la vittima.

3. Reindirizzamento e spoofing: in un tipico scenario di spoofing DNS, le risposte di ricerca alterate indirizzano gli utenti verso pagine di destinazione di phishing che imitano i portali interni aziendali, i siti bancari o i provider di Single Sign-On.

La crittografia del canale di trasporto tra il dispositivo client (stub resolver) e il resolver ricorsivo a monte elimina questi vettori di attacco. Ciò garantisce che eventuali intercettatori vedano solo flussi crittografati anziché nomi di dominio in chiaro, assicurando al contempo che le risposte non possano essere modificate dai dispositivi intermedi presenti lungo il percorso.

Che cos’è il DNS over TLS (DoT)?

Il protocollo DNS over TLS, standardizzato dall'IETF nella RFC 7858, protegge i messaggi DNS nel formato classico all'interno di un tunnel crittografato Transport Layer Security (TLS).

Anziché utilizzare la porta standard 53, DoT opera su una propria porta di rete dedicata: la porta 853.

Quando un dispositivo avvia il protocollo DoT, stabilisce una connessione TCP affidabile con la porta 853 di un resolver designato, completa un handshake crittografico TLS standard e scambia query DNS all’interno di quella sessione sicura. La RFC 7858 vieta l’invio di dati in chiaro sulla porta 853; se la negoziazione TLS fallisce, la connessione viene interrotta anziché ricorrere a una trasmissione non crittografata su quella porta.

Poiché DoT non aggiunge alcun wrapper a livello di applicazione, riduce al minimo il sovraccarico delle query. Una volta stabilita la connessione, i client possono riutilizzare le sessioni TLS esistenti e inviare più query contemporaneamente in pipeline, evitando così la latenza dell'handshake ad ogni ricerca.

Supporto per sistemi operativi e piattaforme

• Android: A partire da Android 9 (Pie), Google ha aggiunto il supporto nativo per DoT tramite l'impostazione “DNS privato”. Una volta attivata con un nome host specificato, tutte le query DNS a livello di dispositivo vengono instradate tramite DoT.
• Linux: i resolver di sistema come systemd-resolved e i demoni di cache locale come Unbound o Stubby offrono il supporto nativo per DoT.
• Apparecchiature aziendali: i moderni firewall di nuova generazione (NGFW) e i resolver ricorsivi dedicati supportano spesso il protocollo DoT in modo nativo per crittografare le query interne inviate ai resolver di protezione a monte.

Che cos’è il DNS su HTTPS (DoH)?

Il DNS over HTTPS, standardizzato nella RFC 8484, adotta un approccio architetturale diverso. Anziché introdurre un canale di trasporto dedicato per le query sui domini, il DoH incapsula i messaggi di richiesta e risposta DNS all’interno di payload standard HTTP/2 o HTTP/3 crittografati con TLS.

DoH opera sulla porta 443, la stessa porta di rete utilizzata dal traffico web standard.

Ai sensi della RFC 8484, le query DNS vengono trasmesse come richieste HTTP GET o POST con il tipo MIME specifico application/dns-message. Poiché questi scambi sono completamente multiplexati insieme al traffico web sulla porta 443, gli osservatori esterni della rete non sono in grado di distinguere facilmente una ricerca DNS da un normale download di una pagina web protetta.

Questo design garantisce la massima resilienza della privacy dell'utente finale. Se una rete intermedia o un ISP tentasse di ispezionare o filtrare il traffico DNS, il DoH glielo impedirebbe, a meno che non interrompa e ispezioni tutte le connessioni HTTPS in uscita.

Supporto per sistemi operativi e browser

• Browser web: Mozilla Firefox, Google Chrome, Microsoft Edge e Brave dispongono tutti di motori DoH configurabili. Firefox è stato il primo a implementare il DoH come impostazione predefinita in diverse regioni, mentre i browser basati su Chromium supportano l'aggiornamento automatico al DoH quando il sistema operativo sottostante utilizza un resolver compatibile.
• Windows 11: Windows 11 include il supporto integrato per il protocollo DoH a livello di sistema. Gli amministratori di rete e gli utenti possono assegnare indirizzi IP ai server DNS e specificare URL di modelli DoH manuali tramite le proprietà della scheda di rete.
• Apple (macOS e iOS): le piattaforme Apple supportano nativamente DoH e DoT tramite profili di configurazione DNS crittografati o app dedicate di estensione di rete.

DoH vs DoT: confronto diretto

Spiegazione delle principali differenze

Assegnazione delle porte e visibilità della rete

La divergenza operativa più evidente tra il DoT e il DoH riguarda i numeri di porta loro assegnati.

DoT opera sulla porta 853. Questa assegnazione dedicata rende il monitoraggio della rete prevedibile. Un amministratore di sistema può dare un’occhiata ai log del firewall, verificare se il traffico sulla porta 853 è diretto verso un resolver interno autorizzato e bloccare le connessioni non autorizzate con una singola regola. Se un endpoint non gestito tenta di contattare un resolver non autorizzato sulla porta 853, il firewall elimina il pacchetto senza interferire con il normale traffico web.

DoH utilizza la porta 443. Poiché la porta 443 trasporta praticamente tutto il traffico Internet crittografato, una rete non può bloccare la porta 443 senza interrompere l'accesso al World Wide Web. Di conseguenza, gli amministratori di rete non sono in grado di distinguere se un pacchetto in uscita sia una normale chiamata API, un utente che sta caricando un sito di e-commerce o una richiesta DNS crittografata indirizzata a un resolver esterno.

Il compromesso tra sicurezza e privacy

Il Dipartimento della Salute (DoH) e il Dipartimento dei Trasporti (DoT) mettono in luce il dibattito in corso tra la privacy degli utenti finali e la difesa centralizzata della rete.

Dal punto di vista della privacy individuale, il DoH offre prestazioni eccellenti. Sulle reti Wi-Fi pubbliche o nelle aree in cui i fornitori di servizi registrano e monetizzano la cronologia di navigazione dei clienti, il DoH nasconde i metadati delle richieste all’interno dei normali flussi di navigazione web, proteggendo gli utenti dal tracciamento invasivo.

Dal punto di vista della sicurezza aziendale, il DoH non gestito comporta rischi significativi. Molti sistemi moderni di prevenzione delle minacce si avvalgono del filtraggio DNS per intercettare domini di comando e controllo (C2) noti, bloccare i tunnel di esfiltrazione dei dati e bloccare gli endpoint coinvolti in attacchi di phishing prima ancora che possano avviarsi le procedure di handshake TCP.

Quando un browser o un'applicazione non autorizzata all'interno di una rete aziendale passa di default al DoH esterno:

• Bypassa completamente i firewall DNS locali e i resolver di Active Directory.
• Impedisce agli strumenti di gestione delle informazioni e degli eventi di sicurezza (SIEM) di accedere ai log delle query degli endpoint.
• Gli autori di minacce avanzate possono sfruttare i canali DoH per comunicare in modo occulto con infrastrutture di comando esterne, nascondendo payload dannosi all’interno di normali sessioni sulla porta 443.

Per questo motivo, i team IT aziendali spesso bloccano gli endpoint DoH non autorizzati al confine della rete IP oppure distribuiscono criteri di gruppo che impongono l'uso di resolver approvati dall'azienda.

Prestazioni e latenza

In contesti di uso quotidiano, entrambi i protocolli garantiscono risposte rapide una volta stabilite le connessioni iniziali. Tuttavia, i meccanismi alla base di ciascuno di essi determinano sottili differenze in termini di prestazioni.

DoT utilizza payload DNS non elaborati su TLS. Ciò consente di mantenere il framing compatto, richiedendo un numero inferiore di byte per transazione. Si avvale dei meccanismi standard di keep-alive TCP e della ripresa della sessione TLS per ridurre al minimo l'overhead di connessione.

Il DoH comporta un carico di elaborazione leggermente superiore, poiché deve incapsulare le query DNS all’interno delle intestazioni HTTP e gestire le macchine a stati HTTP. Tuttavia, poiché il DoH beneficia del multiplexing di HTTP/2 e HTTP/3, è in grado di gestire centinaia di richieste simultanee su un unico flusso senza blocchi “head-of-line”, sfruttando al contempo i meccanismi di cache HTTP. Nella navigazione web standard, la differenza di latenza effettiva tra DoT e DoH è raramente percepibile dagli utenti.

Quale scegliere?

La scelta tra DoT e DoH dipende dall'ambiente, dai requisiti operativi e da chi gestisce l'infrastruttura di rete.

Utenti individuali su reti non affidabili o pubbliche

Se viaggi spesso, lavori dai bar o utilizzi provider di servizi Internet residenziali che monitorano le tue ricerche, il DoH è in genere l’opzione più sicura. Abilitare il DoH nel tuo browser preferito garantisce che gli operatori di rete locali non possano registrare i domini che visiti né inserire script di tracciamento.

Reti aziendali e d’impresa

Le organizzazioni dovrebbero dare la priorità al DoT o al DoH gestito in modo rigoroso.

Negli ambienti aziendali, la visibilità è un requisito imprescindibile. I team IT devono garantire che tutte le postazioni di lavoro, i dispositivi mobili e l'hardware IoT effettuino la risoluzione dei nomi tramite resolver protetti approvati.

Per mantenere il controllo senza rinunciare alla crittografia, le aziende dovrebbero:

• Configurare gli endpoint per l'utilizzo di resolver ricorsivi interni tramite DoT.
• Applicare le politiche amministrative in browser come Chrome, Edge e Firefox per impedire che gli utenti o gli aggiornamenti attivino o disattivino i resolver DoH pubblici non gestiti.
• Bloccare il traffico in uscita verso gli indirizzi IP noti dei resolver DoH pubblici sui firewall per impedire che i controlli di sicurezza interni vengano aggirati.
• Applicare le migliori pratiche consolidate in materia di sicurezza DNS per garantire una protezione uniforme in tutte le zone interne.

Dispositivi mobili

I dispositivi mobili passano continuamente dalle reti Wi-Fi aziendali affidabili ai router domestici e alle ripetitrici dei gestori di telefonia mobile. Android gestisce questa situazione in modo trasparente grazie alla funzione Private DNS integrata che utilizza il protocollo DoT, garantendo una crittografia uniforme su tutte le app presenti sul dispositivo senza richiedere software aggiuntivo. I dispositivi iOS e macOS possono ottenere la stessa protezione tramite profili di configurazione che supportano il protocollo DoT o DoH.

E il DNS su QUIC (DoQ)?

Con l'evoluzione delle architetture di trasporto, è entrato in scena un nuovo protocollo: il DNS over QUIC (DoQ), standardizzato nella RFC 9250.

Mentre DoT e il DoH tradizionale funzionano su TCP, DoQ funziona su QUIC tramite la porta UDP 853. QUIC integra la crittografia TLS 1.3 direttamente nella procedura di handshake di trasporto. Questa struttura risolve il problema dell’head-of-line blocking, accelera lo stabilimento della connessione grazie alla ripresa della sessione con 0-RTT e supporta una migrazione senza interruzioni della connessione quando i dispositivi mobili passano dalla rete Wi-Fi alla rete dati mobile.

Sebbene DoQ rappresenti l'avanguardia nella ricerca e nelle prestazioni relative al DNS crittografato, la sua adozione in ambiente di produzione è ancora agli inizi rispetto agli ecosistemi ormai consolidati di DoT e DoH.

DoH/DoT vs DNSSEC: perché servono entrambi

Un errore comune è ritenere che l'attivazione di DoH o DoT renda superflui gli altri protocolli di sicurezza DNS. In realtà, il trasporto crittografato e le estensioni di sicurezza del sistema dei nomi di dominio (DNSSEC) riguardano due aspetti completamente diversi del ciclo di vita della sicurezza.

• I protocolli DoH e DoT proteggono il percorso di trasmissione: crittografano la connessione tra il tuo dispositivo e il resolver ricorsivo. Impediscono a chi potrebbe intercettare i dati sulla tua rete locale o al tuo ISP di spiare la query. Tuttavia, non forniscono alcuna garanzia sul fatto che il resolver a monte stia fornendo una risposta accurata proveniente dal vero proprietario del dominio.
• Il protocollo DNSSEC garantisce l'integrità dei dati: il protocollo DNSSEC utilizza firme digitali crittografiche (record RRSIG) pubblicate nel file di zona per verificare che i dati DNS restituiti non siano stati alterati a livello di server autoritativo né compromessi nelle cache dei resolver.

Se un malintenzionato compromette un server dei nomi autorevole a monte o sferra un attacco di tipo “DNS cache poisoning”, DoH e DoT invieranno quella risposta falsificata direttamente al tuo dispositivo attraverso un tunnel sicuro e crittografato.

Per garantire la completa integrità dell'infrastruttura, le organizzazioni devono implementare il protocollo DNSSEC nelle proprie zone di dominio, configurando al contempo i resolver in modo che verifichino la validità delle firme. È possibile verificare se i propri domini attuali pubblicano firme crittografiche valide sottoponendoli al nostro strumento automatizzato di verifica DNSSEC.

Domande frequenti

DoH è più sicuro di DoT?

Da un punto di vista puramente crittografico, nessuno dei due protocolli è intrinsecamente più sicuro dell’altro. Entrambi utilizzano una crittografia TLS robusta per proteggere le query DNS dall’osservazione e dalla manipolazione. La vera differenza risiede nella visibilità di rete: DoH garantisce una maggiore privacy contro il monitoraggio della rete locale condividendo la porta 443 con il traffico web, mentre DoT offre funzionalità di gestione superiori ai team di sicurezza aziendali utilizzando la porta dedicata 853.

È meglio attivare o disattivare il DNS su HTTPS?

Per gli utenti individuali che utilizzano dispositivi personali, mantenere abilitata la funzione DoH offre vantaggi immediati in termini di privacy, impedendo agli operatori di rete locali e agli ISP di registrare le ricerche.

Tuttavia, negli ambienti aziendali, il protocollo DoH non gestito dovrebbe in genere essere disabilitato o reindirizzato verso resolver approvati dall'azienda. Se lasciato non gestito, il protocollo DoH a livello di browser aggira i firewall della rete interna, le regole di filtraggio dei contenuti e i dispositivi di monitoraggio delle minacce.

È possibile bloccare DoH su una rete?

Sì. Sebbene non sia possibile bloccare il DoH chiudendo una porta specifica senza disabilitare anche il traffico web HTTPS sulla porta 443, le organizzazioni possono limitare l’uso del DoH ricorrendo a controlli alternativi. Gli amministratori di rete possono bloccare l’accesso agli indirizzi IP pubblici dei resolver DoH commerciali noti, limitare l’accesso tramite proxy web oppure utilizzare firewall di nuova generazione dotati di motori di identificazione delle applicazioni (App-ID) in grado di riconoscere le firme del traffico DoH.

Una VPN rende superfluo l'uso di DoH o DoT?

Una rete privata virtuale (VPN) crittografa tutto il traffico di rete in uscita dal dispositivo, comprese le richieste DNS, all’interno di un tunnel crittografato che conduce al gateway VPN. Se ti fidi del tuo provider VPN e configuri il sistema in modo che risolva le richieste tramite i suoi resolver ricorsivi privati, non hai necessariamente bisogno di DoH o DoT, poiché l’intero tunnel è già crittografato.

Tuttavia, l'utilizzo di DoH o DoT all'interno o all'esterno di una VPN aggiunge un livello di protezione approfondita, garantendo che le query rimangano protette anche nel caso in cui lo split tunneling causi la fuga di pacchetti DNS standard.

Considerazioni finali: proteggete i vostri resolver e i vostri record

Sia il DNS over HTTPS che il DNS over TLS offrono notevoli miglioramenti in termini di privacy rispetto allo standard UDP su porta 53 in chiaro, ormai vecchio di quarant'anni. La scelta tra i due dipende dal contesto: il DoH garantisce ai singoli utenti anonimato e privacy sulle reti pubbliche, mentre il DoT offre alle organizzazioni i chiari confini e la visibilità necessari per applicare le politiche di sicurezza aziendali.

Tuttavia, la crittografia delle modalità con cui il vostro team effettua le ricerche sui domini di terze parti risolve solo metà del problema di vulnerabilità della vostra infrastruttura. È necessario inoltre proteggere i record DNS pubblici che indirizzano il resto del mondo verso i servizi web, le applicazioni e i server di posta elettronica della vostra azienda.

Le zone di dominio non monitorate sono esposte a modifiche non autorizzate dei record, alla mancanza di firme crittografiche e alla scadenza dei certificati. PowerDMARC aiuta le organizzazioni a mantenere il controllo totale sui domini attraverso il monitoraggio della sicurezza DNS e la conformità.

Abbinando il monitoraggio continuo dei record e gli avvisi sulle modifiche alla cronologia DNS al nostro strumento gratuito di verifica DNSSEC, potrete garantire che l’infrastruttura DNS della vostra azienda rimanga verificabile, conforme e protetta contro lo spoofing da ogni punto di vista.