
DNS over HTTPS protegge le richieste, non rende anonima la navigazione

DNS over HTTPS (DoH) cifra le richieste con cui il browser cerca l’indirizzo IP di un dominio e le risposte ricevute dal resolver. La spiegazione di Cloudflare descrive questo scambio DNS trasportato tramite HTTPS: chi osserva il collegamento non può leggere il nome richiesto mentre la ricerca è in transito.
La protezione finisce ai confini di quello scambio. Il resolver deve conoscere il dominio per rispondere, mentre il sito riceve la connessione successiva; DoH non nasconde l’indirizzo IP con cui ti colleghi al sito né cambia cookie, accessi agli account o dati inseriti nelle pagine. La scelta del resolver e le regole della rete contano quindi quanto l’attivazione della funzione.
Il percorso di una richiesta DNS
Quando apri un sito, il browser deve trovare l’indirizzo IP associato al suo nome. Se usa il DNS tradizionale senza cifratura, la richiesta e la risposta possono essere lette da chi osserva il tratto fra il dispositivo e il resolver. Anche una pagina servita tramite HTTPS può essere preceduta da una ricerca DNS in chiaro: sono due comunicazioni distinte.
Con DoH, il browser invia la ricerca a un resolver compatibile attraverso HTTPS. Un osservatore della rete locale può vedere che il dispositivo comunica con quel servizio, ma non leggere il dominio contenuto nella richiesta cifrata. Il resolver, invece, riceve il nome da cercare e può rispondere: cambiare fornitore significa cambiare il soggetto a cui affidi le ricerche DNS.
Ottenuto l’indirizzo, il browser si collega al sito. La protezione dei contenuti scambiati in questa fase dipende dalla connessione al sito, in particolare da HTTPS, e non da DoH. Inoltre, un’impostazione attivata nel browser non implica che tutte le altre applicazioni del dispositivo inviino le proprie ricerche DNS nello stesso modo.
Che cosa resta visibile durante la navigazione
DoH riduce la possibilità che un osservatore sul percorso della richiesta DNS legga o modifichi quel messaggio. Non elimina però le informazioni prodotte dalla connessione successiva: gli indirizzi IP delle destinazioni restano necessari per instradare il traffico e possono offrire indizi sui servizi usati. Un indirizzo IP può anche essere condiviso da più siti, quindi non equivale sempre al nome preciso della pagina visitata.
Il sito raggiunto può vedere la connessione e riconoscere chi accede a un account. Può inoltre usare cookie e altri dati forniti dal browser secondo le proprie regole. La cifratura DNS non interviene su questi meccanismi: protegge la ricerca del nome lungo il percorso verso il resolver, senza trasformare la visita in una sessione anonima.
DoH, DoT e DNSSEC hanno ruoli diversi
DNS over TLS (DoT) cifra a sua volta la comunicazione con il resolver, ma usa un canale distinto dal normale traffico HTTPS. DoH trasporta le richieste nel traffico HTTPS, rendendole più difficili da distinguere per chi gestisce la rete. Entrambi riguardano il trasporto delle ricerche DNS; la differenza può incidere sulla capacità di una rete di riconoscere e gestire quelle comunicazioni.
DNSSEC affronta un altro problema: permette di verificare che i dati DNS ricevuti non siano stati alterati lungo la catena di risoluzione, ma non cifra richieste e risposte. Può quindi affiancare una connessione cifrata al resolver. Se il dubbio è chi possa leggere una ricerca in transito, la sola presenza di DNSSEC non risolve quel problema.
Come gestire DoH in Chrome e Firefox
Su Chrome per computer, apri Impostazioni, poi Privacy e sicurezza, Sicurezza e, nella sezione Avanzate, «Usa DNS sicuro». Le istruzioni di Chrome indicano che puoi attivare o disattivare l’opzione e scegliere il fornitore attuale o uno personalizzato. Nella modalità automatica, se la ricerca sicura incontra problemi, Chrome può riprovare senza cifratura; con un fornitore personalizzato non adotta quel ripiego come comportamento predefinito.
In Firefox, apri Impostazioni, entra in Privacy e sicurezza e raggiungi la sezione «DNS su HTTPS». Da lì puoi modificare il livello di protezione, scegliere un fornitore o disattivare la funzione. Lo stato mostrato dal browser è utile perché un livello selezionato può risultare non attivo quando il resolver non è raggiungibile o la rete richiede un comportamento diverso.
Se dopo la scelta di un fornitore personalizzato un nome non si risolve, ripristinare la modalità precedente aiuta a capire se il problema dipende dalla configurazione DNS. Il risultato riguarda l’accesso a quel nome, non misura la privacy complessiva della navigazione. Su un dispositivo gestito, alcune impostazioni possono dipendere dai criteri dell’organizzazione.
Filtri domestici e DNS delle reti aziendali
Un controllo parentale o un filtro aziendale può funzionare attraverso il resolver scelto dalla rete. Se il browser invia le ricerche a un resolver DoH esterno, quel filtro potrebbe non riceverle. Le FAQ di Mozilla spiegano che Firefox può disattivare automaticamente DoH quando rileva criteri aziendali o segnali di controllo parentale. Una configurazione manuale più restrittiva può però comportarsi diversamente.
Le aziende possono usare anche nomi disponibili soltanto nel DNS interno. Se la ricerca tramite DoH non trova uno di questi nomi, Firefox può ricorrere al DNS ordinario. Il caso più insidioso è un dominio pubblico che nella rete aziendale deve restituire un indirizzo diverso: il resolver esterno può fornire una risposta valida per Internet ma inadatta al servizio interno. Qui la configurazione va concordata con chi amministra la rete.
La stessa attenzione serve a casa quando il router o il fornitore della connessione applica un filtro DNS. Prima di sostituire il resolver nel browser, verifica se il blocco dei siti dipende proprio da quel servizio: la cifratura della richiesta non conserva automaticamente le regole del resolver che smette di riceverla.
Quando mantenere la modalità predefinita
Su una rete domestica senza nomi interni o filtri DNS, la modalità predefinita del browser è un punto di partenza ragionevole. Può proteggere le richieste quando il servizio cifrato è disponibile e gestire alcuni problemi di compatibilità. Se scegli un fornitore personalizzato, valuta a chi vengono inviate le ricerche e quale comportamento preferisci quando quel servizio non risponde.
Su una rete aziendale, scolastica o con controllo parentale, è più utile conservare le impostazioni previste dalla rete finché non sai come vengono risolti i nomi e applicati i filtri. Se un servizio interno smette di funzionare, l’amministratore può indicare un resolver cifrato compatibile o una configurazione del browser adatta a quella rete.
Leggi anche:
Articoli correlati


Prompt injection negli agenti IA: il filtro da solo non basta

Passkey o password: il phishing perde presa, ma il recupero resta critico

Un RAG sui documenti non basta: senza citazioni gli errori restano invisibili

Disinformazione, nuovi report UE: i dati delle piattaforme non bastano

Il backup 3-2-1 non basta se non provi davvero il ripristino
Iscriviti alla nostra newsletter
Ricevi le ultime notizie su Web3, IA e cripto direttamente nella tua casella di posta.