DNS Over HTTPS spiegato: privacy e filtraggio della rete WiFi pubblica a confronto
DNS over HTTPS crittografa le ricerche all'interno del traffico della porta 443. Scopri cosa nasconde, perché può aggirare il filtraggio WiFi e come le reti mantengono il controllo.
Published 26 ottobre 2026
DNS over HTTPS invia le ricerche DNS all'interno del normale traffico HTTPS sulla porta 443, crittografato tra il dispositivo e il resolver, ed è diventato uno standard IETF nel 2018.
Hai abilitato il filtro contenuti sul tuo WiFi ospiti, ma il browser di un utente apre comunque una categoria che pensavi di aver bloccato. Il firewall è attivo, le impostazioni di rete sembrano corrette e un altro dispositivo visualizza la pagina di blocco prevista. La differenza potrebbe dipendere da quale resolver interpella il browser, non dal fatto che il filtro stia funzionando o meno.
Per i gestori delle sedi e i responsabili IT, questo è il problema centrale con il DoH. Protegge una ricerca durante il suo percorso, ma la scelta della destinazione da parte del browser può anche spostare tale ricerca al di fuori della politica di filtraggio della tua rete.
Indice dei contenuti
- Cosa significa DNS over HTTPS in parole semplici
- Come viaggia una query DoH dal dispositivo al resolver
- Chi può vedere le query quando il DoH è attivo
- Perché il DoH indebolisce il filtraggio DNS sui WiFi condivisi
- Quanto costa il DoH in termini di velocità e cosa continua a fare il filtraggio
- Verificare e modificare il DoH sui dispositivi più comuni
- Scegliere e strutturare i controlli DoH a livelli
Cosa significa DNS over HTTPS in parole semplici
DNS over HTTPS, solitamente abbreviato in DoH, trasporta domande e risposte DNS attraverso una connessione web crittografata. Un resolver DNS è il servizio a cui un dispositivo chiede di tradurre un nome di dominio in un indirizzo di rete.
Pensa al DNS come a una rubrica telefonica. Prima di aprire una connessione, un'applicazione ha bisogno di un indirizzo, sebbene possa già avere una risposta utilizzabile nella sua cache. Il DNS tradizionale invia comunemente tale richiesta in forma leggibile.
Una cartolina è un'analogia calzante: chiunque la maneggi può leggerne il messaggio. Il DoH inserisce la richiesta in una busta sigillata e la trasporta all'interno dello stesso tipo di furgone di consegna utilizzato per il normale traffico web sicuro.
Confrontare il trasporto, non solo la crittografia
DNS over TLS, o DoT, sigilla anch'esso la busta, ma utilizza un ingresso di consegna etichettato separatamente. Ciò rende il suo traffico più facile da identificare per un operatore di rete tramite la sua porta di destinazione.
L'RFC 8484 dell'IETF, pubblicato nell'ottobre 2018, definisce lo scambio HTTPS del DoH, utilizzando tipicamente la porta 443, a differenza del DNS tradizionale sulla porta 53.
Confronto tra DNS tradizionale, DNS over TLS e DNS over HTTPS
| Funzionalità | DNS tradizionale | DNS over TLS (DoT) | DNS over HTTPS (DoH) |
|---|---|---|---|
| Trasporto | UDP o TCP | TLS | HTTPS |
| Porta consueta | 53 | 853 | 443 |
| Leggibile dalla rete locale | Sì | No | No |
| Facile da individuare tramite porta | Sì | Sì | No, condivide la porta 443 con il traffico web |
| Facile da bloccare tramite porta | Sì | Sì | No, non in modo selettivo tramite la sola porta |
| Definito in | Specifiche DNS originali | Specifica DNS over TLS | RFC 8484 |
Il blocco di una porta DNS dedicata è un'operazione semplice. Bloccare la porta utilizzata dai siti web sicuri fermerebbe anche il traffico web legittimo, motivo per cui il DoH richiede controlli più selettivi.
La crittografia non decide cosa viene filtrato. Un resolver può decrittografare una richiesta DoH in entrata, applicare una policy sui contenuti o sulle minacce e restituire la risposta in modo sicuro. Le domande fondamentali sono chi gestisce quel resolver e di chi è la policy applicata.
Tenere a mente questo confronto durante la revisione dei controlli. Una regola che gestisce il DNS tradizionale o DoT non gestisce automaticamente il DoH.
Come viaggia una richiesta DoH dal dispositivo al resolver
Un corriere ha bisogno di un indirizzo prima di consegnare un pacco. Allo stesso modo, un browser necessita di un indirizzo di destinazione prima di potersi connettere a una pagina di prenotazione alberghiera, a meno che non abbia già memorizzato la risposta nella cache.
Questo diagramma segue la risoluzione dei nomi dal browser al resolver e viceversa.
Segui la richiesta e la risposta
Il browser ha bisogno di un indirizzo. Verifica se dispone già di una risposta utilizzabile per il sito di prenotazione. Un hit nella cache può evitare del tutto una nuova ricerca, quindi la rete locale non vedrà uno scambio DNS per tale azione.
Crea una richiesta DNS. Se ha bisogno di una risposta aggiornata, il browser prepara una query contenente il nome di dominio. In questo momento, la richiesta è ancora all'interno del dispositivo e non sta viaggiando attraverso il WiFi.
Seleziona il resolver DoH. Il browser prepara una richiesta HTTPS per il resolver configurato. La rete locale può osservare l'indirizzo di destinazione e i metadati della connessione, ma non può leggere direttamente il dominio all'interno del messaggio DNS crittografato.
Stabilisce o riutilizza una connessione sicura. Se necessario, il dispositivo completa un handshake TLS prima di inviare la richiesta protetta. Con una connessione HTTP persistente, le query successive possono riutilizzare tale connessione; la rete vede il traffico crittografato, compresi i tempi e le dimensioni.
Il resolver restituisce la risposta. Il resolver elabora la richiesta e inserisce la risposta DNS all'interno di una risposta HTTP crittografata. La rete può vedere il traffico di ritorno dal resolver, ma non il contenuto leggibile della risposta.
Il browser si connette al sito web. Utilizza l'indirizzo restituito per avviare la connessione al sito web. La rete locale può osservare quella nuova destinazione, il che è un'azione distinta dalla lettura della precedente richiesta DNS.
Per maggiori dettagli sulla memorizzazione nella cache e sulla risoluzione, la spiegazione di cosa fa una ricerca DNS separa il processo di ricerca dell'indirizzo dalla connessione al sito web vera e propria.
Identifica il punto di filtraggio
Per una nuova connessione che richiede la risoluzione DNS, la ricerca avviene prima del caricamento del contenuto della pagina. Ciò offre a un resolver approvato l'opportunità di rifiutare una destinazione bloccata prima che il browser si connetta.
Un browser configurato in modo indipendente può inviare tale decisione altrove. Il resolver della struttura non riceve quindi alcuna richiesta da valutare.
Il video correlato offre un ulteriore modo per seguire il processo.
Chi può vedere le tue ricerche quando il DoH è attivo
Il DoH non nasconde la navigazione a chiunque. Protegge lo scambio DNS da osservatori ordinari tra il dispositivo e il resolver scelto, ma quel resolver deve leggere la richiesta per poter rispondere.
Questa distinzione è importante su una rete WiFi condivisa. Un ospite può ragionevolmente desiderare protezione contro l'intercettazione locale, mentre un ospedale o una scuola devono avere la certezza che i propri controlli di protezione e minaccia continuino ad applicarsi.
Il DoH modifica l'entità a cui si affida l'attività DNS; non elimina la necessità di fidarsi di qualcuno.
Separare la visibilità DNS dalla visibilità di navigazione
La tabella descrive l'uso ordinario del DoH senza un relay per la privacy aggiuntivo, una VPN o un sistema di intercettazione. Leggere un messaggio DNS e desumere una destinazione da altre attività di rete sono funzionalità diverse.
Chi può vedere le ricerche DNS quando si utilizza DoH
| Osservatore | Vede i nomi di dominio | Vede che il DoH è in uso | Perché è importante |
|---|---|---|---|
| Altri dispositivi sulla stessa rete WiFi | No, non dalla ricerca crittografata | Raramente tramite il normale accesso peer | La lettura passiva del messaggio DNS è bloccata |
| Rete della struttura o dell'ISP | No, non all'interno dello scambio DoH | Spesso, attraverso il traffico verso un indirizzo resolver noto | I controlli DNS locali non possono valutare le query inviate altrove |
| Siti web visitati | Solo il sito a cui ti connetti | Non dalla sola connessione al sito web | Un sito non riceve le tue query DNS non correlate |
| Gestore del resolver DoH | Sì, ogni query che riceve | Sì | Una connessione diretta espone tali query insieme al tuo indirizzo di origine |
| Fornitore del browser o del sistema operativo | Solo se gestisce il resolver o riceve la telemetria pertinente | Il software conosce la modalità configurata; i report del fornitore richiedono la telemetria | La configurazione del software non equivale alla visibilità automatica del fornitore |
Il resolver non vede necessariamente ogni ricerca effettuata dal dispositivo. Un'altra applicazione potrebbe utilizzare un resolver diverso e le risposte in cache potrebbero non richiedere alcuna query. Vede solo le richieste che gli vengono inviate.
Allo stesso modo, il fornitore del browser non riceve automaticamente la cronologia DNS solo perché fornisce il browser. La gestione del resolver, le impostazioni del software e la raccolta della telemetria sono ruoli distinti.
Rendi esplicita la decisione di affidabilità
Per le installazioni gestite di Firefox, la documentazione sulla policy DNS over HTTPS di Mozilla fornisce controlli per la configurazione del resolver e per consentire o meno agli utenti di modificarla. Si tratta di un modo pratico per allineare il comportamento del browser con la governance DNS dell'organizzazione.
Una struttura o un ISP possono comunque osservare gli indirizzi di destinazione, le tempistiche di connessione e i volumi di traffico. Altri metadati di protocollo possono anche aiutare a identificare un sito, quindi una query DNS crittografata non è una garanzia di navigazione anonima.
Utilizzare una breve valutazione di affidabilità prima di approvare un resolver:
- Individua l'operatore. Stabilisci quale organizzazione riceve le richieste, anziché affidarti all'etichetta predefinita di un browser.
- Leggi i termini di conservazione. Controlla quali informazioni sulla query e sulla connessione vengono archiviate, per quanto tempo e per quali scopi.
- Verifica la giurisdizione e l'accesso. Comprendi dove l'operatore elabora le informazioni e chi può ottenerle.
- Associa la visibilità alla responsabilità. Decidi quali eventi di sicurezza il tuo team IT deve analizzare e quali dettagli di navigazione non deve conservare.
La domanda utile non è se la privacy o la gestibilità abbiano più importanza in astratto. È se il percorso DNS scelto offra agli utenti un'adeguata riservatezza consentendo al contempo all'organizzazione di svolgere le proprie responsabilità dichiarate.
Perché il DoH indebolisce il filtraggio DNS su WiFi condiviso
Un hotel fornisce agli ospiti il numero della reception per aiutarli a trovare servizi locali. La maggior parte degli ospiti chiama la reception, ma un altro ospite utilizza invece un'app di elenchi. La reception può controllare le proprie raccomandazioni, non le risposte fornite da quell'app.
Il DNS di rete funziona in modo simile. La rete fornisce un resolver, ma un browser con una propria configurazione DoH può interrogare un servizio esterno.
L'illustrazione mostra il percorso alternativo che aggira la gestione DNS della rete.
Il bypass riguarda il percorso
Il problema non è che una query crittografata non possa mai essere filtrata. Il punto è che il filtro non può applicare le direttive a una query che non riceve mai.
Su una rete guest per visitatori di un'attrazione per famiglie, ciò potrebbe significare che un blocco per contenuti per adulti non si applica a un browser specifico. Su una rete aziendale per il personale, un'applicazione malevola potrebbe risolvere un dominio di comando e controllo attraverso un resolver non approvato.
Le conseguenze dipendono da quali controlli si basano sul DNS:
- Policy specifiche per la rete. Le regole assegnate a un SSID o a una VLAN non gestiranno le richieste inviate al di fuori del percorso resolver approvato.
- Restrizioni di ricerca. L'applicazione del Safe Search basato su DNS può essere bypassata, sebbene possano ancora essere valide le restrizioni a livello di account o di endpoint.
- Blocco delle minacce. Un filtro DNS non può rifiutare una ricerca non visibile, anche se il suo elenco di minacce contiene il dominio richiesto.
Uno studio di misurazione dell'implementazione del DNS crittografato riporta i dati telemetrici di Firefox, secondo cui circa il 13,91% di 9,54 mila miliardi di handshake desktop ha utilizzato DoH nel corso del 2025. Descrive inoltre un set di dati di misurazione in cui DoH è risultato circa 6,4 volte più diffuso rispetto a DoT.
Tali osservazioni non stabiliscono la quota di dispositivi che aggirano il filtro della tua struttura. Le impostazioni predefinite del browser, il roll-out regionale, la compatibilità del resolver e le policy degli amministratori influiscono tutti sull'attivazione del DoH.
Testa la copertura anziché darla per scontata
Un blocco riuscitosi su un laptop aziendale non dimostra una copertura equivalente sullo smartphone personale di un ospite. I dispositivi potrebbero utilizzare browser, impostazioni DNS o tunnel differenti.
Considera il tuo filtro contenuti WiFi come un controllo con un percorso di traffico definito. Testa quel percorso utilizzando i dispositivi e le applicazioni che i tuoi visitatori portano con sé.
Il filtraggio basato solo sul resolver fornito dalla rete non garantisce più una copertura completa di default. Richiede controlli di supporto e una valutazione accurata di ciò che rimane al di fuori della politica aziendale.
Quanto costa il DoH in termini di velocità e cosa continua a fare il filtraggio
La crittografia aggiunge carico di lavoro, ma la questione pratica è se gli utenti notino una sessione più lenta. La configurazione iniziale della connessione e le ricerche ripetute hanno costi diversi, quindi testare una singola nuova richiesta può fornire un'immagine fuorviante.
Un confronto empirico dei trasporti DNS ha registrato risposte UDP e TLS inferiori a 1 millisecondo nella sua baseline locale senza ritardi, mentre HTTP/2 è rimasto costantemente al di sotto dei 10 millisecondi; i risultati riportati di seguito mantengono il contesto sperimentale dello studio anziché presagire le prestazioni effettive della struttura.
Latenza delle richieste DNS per protocollo nello studio citato
| Protocollato | Risultato segnalato | Contesto |
|---|---|---|
| UDP | Inferiore a 1 ms | Baseline locale senza ritardo |
| TLS | Inferiore a 1 ms | Baseline locale senza ritardo |
| HTTP/2 | Inferiore a 10 ms, in modo costante | Il riutilizzo della connessione e il multiplexing aiutano a ridurre il sovraccarico |
| HTTP/1.1 | Fluttua notevolmente | Attribuito ai limiti di pipelining |
| DoH pubblico rispetto al DNS tradizionale | Più lento per nome | Nessun aumento significativo del tempo di caricamento complessivo della pagina osservato |
Misurare la sessione, non solo l'handshake
Le connessioni persistenti consentono a un client di distribuire i costi di configurazione sulle query successive. Il multiplexing permette di gestire più scambi senza stabilire una connessione sicura separata per ciascuna richiesta.
Il filtraggio DNS può comunque rifiutare un dominio prima che inizi una nuova connessione, a condizione che la richiesta raggiunga il resolver di filtraggio. Il blocco di annunci e tracker può ridurre le richieste successive, ma la sola crittografia non rimuove gli annunci né accelera una pagina.
Tracciare i segnali operativi che rivelano problemi reali:
- Errori di handshake. Cerca errori di configurazione della connessione e tentativi successivi.
- Tassi di cache-hit. Separa le risposte memorizzate nella cache dalla risoluzione ex novo.
- Tempo di risposta del resolver. Misura il comportamento durante le sessioni guest ad alto traffico.
- Comportamento di fallback. Verifica se eventuali errori causano l'interruzione della risoluzione nei dispositivi o il passaggio a un altro percorso senza preavviso.
Regola pratica: Testare la navigazione, l'applicazione delle policy e il ripristino in caso di guasto insieme, non come verifiche di accettazione separate.
Un endpoint resolver vicino e resiliente rappresenta un punto di partenza migliore rispetto alla scelta di un protocollo basata unicamente su presupposti di latenza. Verificare il risultato sulla propria rete in condizioni di carico reali.
Verificare e modificare il DoH sui dispositivi più comuni
L'impostazione di un browser può spiegare perché i dispositivi connessi alla stessa rete WiFi si comportino diversamente. Le etichette dei menu cambiano tra le varie versioni, pertanto utilizzare la ricerca nelle Impostazioni se il percorso indicato di seguito non è visibile.
Ispezionare il browser e il sistema operativo
- Chrome: Apri Impostazioni, Privacy e sicurezza, Sicurezza, quindi Usa DNS sicuro. Verifica se segue il provider corrente o se specifica un altro servizio.
- Firefox: Apri Impostazioni, Privacy e sicurezza, quindi DNS su HTTPS. Controlla la modalità di protezione, tra cui Disattivata, Protezione predefinita o Protezione massima, e il resolver selezionato.
- Edge: Apri Impostazioni, Privacy, ricerca e servizi, Sicurezza, quindi Usa DNS sicuro. I criteri gestiti potrebbero bloccare l'impostazione.
- Android: Apri Impostazioni, Rete e Internet, quindi DNS privato. Questa impostazione utilizza DoT anziché DoH; il DNS sicuro a livello di browser richiede una verifica separata.
- iOS e macOS: Esamina i profili di configurazione installati, le impostazioni di gestione dei dispositivi e le app relative al DNS. Un profilo DNS crittografato può funzionare in modo indipendente dal browser.
Verifica il percorso effettivo
Una VPN di sistema può instradare il DNS attraverso il proprio tunnel a prescindere dalle impostazioni del browser. Verificare inoltre se un'applicazione fornisce un servizio DNS crittografato separato.
Conferma quale resolver riceve una nuova ricerca di prova dal browser o dall'app reale. Utilizza la diagnostica del browser o un test di identificazione del resolver insieme ai log del resolver approvato, invece di fidarti solo della schermata delle impostazioni.
Scegli e applica a strati i tuoi controlli DoH
Applica i controlli a livelli in base alla proprietà del dispositivo e alle esigenze di policy. I laptop aziendali gestiti possono seguire una configurazione vincolata; gli smartphone personali degli ospiti generalmente no. Applicare le stesse restrizioni a entrambi i gruppi genera lacune evitabili o blocchi non necessari.
Puoi consentire il DoH esterno accettando una ridotta visibilità del DNS locale, limitarlo e accettare rischi di compatibilità, oppure combinare la policy sui dispositivi gestiti con controlli selettivi sulla rete ospiti. L'approccio multilivello offre una panoramica più chiara su ciò che è protetto e ciò che non lo è.
Associa ogni controllo al suo ambito effettivo
I controlli di rete sono utili, ma non rendono identificabile ogni resolver crittografato. Un resolver privato, un indirizzo variabile o un tunnel VPN possono vanificare le decisioni basate su un elenco di servizi noti.
Controlli per DoH su reti condivise e gestite
| Controllo | Cosa blocca | Dove si applica | Compromesso |
|---|---|---|---|
| Blocca la porta in uscita 853 | DNS over TLS su porta standard | Firewall o gateway | Non ha alcun effetto su DoH gestito tramite HTTPS ordinario |
| Forza la porta 53 verso il resolver di rete | Bypass del DNS non crittografato | Applicazione a livello di gateway, supportata dalla configurazione DHCP | Ignora completamente DoH; il solo DHCP non forza la conformità |
| Blocca gli indirizzi di resolver DoH pubblici noti | Connessioni ai resolver in elenco | Firewall o gateway idoneo | Gli elenchi diventano obsoleti, appaiono nuovi resolver, alcune app smettono di funzionare |
| Disabilita DoH nel browser tramite policy gestita | Bypass a livello di browser nei browser supportati | Laptop gestiti e dispositivi dello staff | Non può intervenire sui telefoni personali collegati al WiFi ospiti |
| Imponi il resolver di rete tramite MDM | Modifiche DNS non autorizzate coperte dalle policy del dispositivo | Dispositivi aziendali e dello staff registrati | Richiede la registrazione e il supporto della piattaforma; gli ospiti ne rimangono esclusi |
| Accetta DoH ed effettua il filtraggio sull'endpoint | Nessun blocco lato rete | Solo endpoint gestiti | I dispositivi degli ospiti rimangono esclusi dalle policy degli endpoint |
Il blocco dell'indirizzo di un resolver potrebbe bloccare anche servizi non correlati ospitati presso il medesimo indirizzo. Si consiglia di non considerare la categoria DNS crittografato di un firewall come un inventario permanente ed esaustivo.
Laddove necessiti di un controllo superiore alla risoluzione del dominio, valuta un secure web gateway insieme ai criteri per gli endpoint e per la rete. Verifica attentamente i requisiti di distribuzione, in particolare quando i dispositivi non sono di proprietà dell'organizzazione.
Crea una politica operativa verificabile
Inizia con il servizio che devi erogare. Una rete amministrativa del personale, una connessione in una biblioteca pubblica e una struttura per attività per bambini possono ragionevolmente necessitare di restrizioni e spiegazioni agli utenti differenti.
Utilizza questa checklist di distribuzione:
- Elenca le policy necessarie. Identifica gli SSID, le VLAN e i gruppi di dispositivi che richiedono controlli sui contenuti o filtraggio delle minacce, e assegna un responsabile a ciascuno.
- Separa i dispositivi gestiti dal BYOD degli ospiti. Registra dove è possibile applicare le policy del browser o l'MDM e dove sono disponibili solo i controlli di rete.
- Chiudi le normali rotte di bypass del DNS. Laddove la tua policy lo richieda, blocca il DoT in uscita e limita il DNS tradizionale al resolver approvato. Copri entrambe le famiglie di indirizzi di rete supportate.
- Applica la policy per i browser gestiti. Configura il percorso DNS approvato ed evita modifiche manuali non supportate da parte degli utenti sulle apparecchiature del personale.
- Mantieni le restrizioni del resolver per la rete ospiti. Rivedi regolarmente gli indirizzi dei resolver bloccati, testa le eccezioni e rimuovi le regole che causano blocchi collaterali inaccettabili.
- Pubblica un'informativa semplice per gli ospiti. Spiega quali categorie vengono filtrate, quali informazioni di rete vengono registrate ed eventuali restrizioni sull'uso di DNS crittografato o VPN.
- Testa un dispositivo reale su ogni rete. Verifica i siti consentiti, le categorie bloccate, le destinazioni di test di sicurezza approvate, i guasti del resolver e il comportamento della VPN.
Prima del lancio: Una pagina di blocco dimostra che una specifica richiesta è stata filtrata, non che ogni applicazione sul dispositivo segua lo stesso percorso.
Rendere il DNS crittografato parte dei test di accettazione
Per utilizzare Shield, è sufficiente puntare il DNS della rete verso Shield. Rispondiamo a ogni ricerca DNS sulla rete che proteggiamo, su qualsiasi dispositivo, senza nulla da disattivare sul dispositivo stesso; i percorsi verso resolver esterni e tunnel devono quindi essere inclusi nella progettazione della protezione di rete.
Prima di provare Purple Shield, il nostro esperto ti mostrerà come la tua rete gestisce le VPN e il DNS crittografato. Utilizza questa discussione per stabilire quali richieste raggiungono il percorso DNS protetto, quali controlli lo applicano e cosa succede quando un dispositivo tenta un altro percorso.
Stabilisci i criteri di accettazione prima di modificare l'accesso ospiti. Un resolver approvato, un processo di eccezione documentato e test ripetibili sui dispositivi forniscono una base più solida rispetto all'assunzione che un filtro abilitato veda tutto.
Purple Shield offre DNS protettivo, filtro contenuti, difesa dalle minacce e blocco degli annunci senza installare agenti sui dispositivi degli ospiti. Visita Purple Shield per organizzare un colloquio preliminare sui tuoi SSID, le policy di filtraggio e la gestione del DNS crittografato e delle VPN sulla tua rete.