DNS-over-HTTPS vs DNS-over-TLS con VPN nel 2026: cosa scegliere, come configurare senza errori

Perché il DNS con VPN nel 2026 non è più un’opzione, ma una necessità

Cosa è cambiato nel 2026: nuovi standard e dura realtà

Se usi una VPN pensando che il gioco sia fatto, spoiler: non è così. Nel 2026, una connessione “nuda” senza una corretta configurazione DNS è come un ombrello bucato. Funziona fino alla prima pioggia. Nuovi standard sono arrivati, la censura è diventata più intelligente, gli ISP più insistenti. Sono entrati in scena ECH (Encrypted Client Hello), DoQ (DNS-over-QUIC), DDR (Discovery of Designated Resolvers), HTTP/3 si è esteso, e i DPI degli operatori sono migliorati, riconoscendo il traffico non solo per porta ma anche tramite fingerprint TLS. Insomma, il gioco si è fatto più complesso. Ma anche gli strumenti più potenti.

Perché parliamo proprio del DNS? Perché il DNS è la rubrica telefonica di internet. Ogni sito inizia da una richiesta DNS. Se il DNS “scappa”, anche le tue intenzioni diventano visibili. La VPN protegge parte dei canali, ma non sempre copre il DNS. Da qui il problema delle “perdite DNS” — quella fastidiosa situazione in cui sei sotto VPN ma il browser sussurra comunque al provider i siti che vuoi visitare. Nel 2026, una combinazione intelligente di VPN e DNS criptato è una buona prassi, come lavarsi le mani.

Spiegheremo DoH e DoT in modo semplice, li confronteremo sul campo, ti mostreremo come farli convivere senza problemi con la VPN. Inoltre, insidie, casi pratici, checklist — tutto ciò che ci avete chiesto. E sì, qualche opinione personale, perché senza un po’ di punto di vista è tutto un po’ noioso e, onestamente, poco utile.

Come funziona il DNS (e perché è importante proteggerlo)

Digiti l’indirizzo di un sito. Il browser fa una richiesta DNS: “Ehi, qual è l’IP di questo dominio?” Solitamente questa richiesta viaggia in chiaro sulla porta 53 (UDP/TCP), quindi chiunque sul percorso può ascoltare: il tuo provider, l’amministratore di una rete pubblica, un malintenzionato in un bar. Vede cosa visiti, quando e quanto. Per qualcuno sono metadata, per noi sono le tue tracce digitali.

Il DNS criptato risolve questo problema. DoT incapsula il DNS in TLS sulla porta 853. DoH si nasconde all’interno di HTTPS sulla 443, a volte anche in HTTP/3 sopra QUIC. Il provider vede che comunichi con un resolver, ma non quale dominio richiedi. Importante: la VPN può far passare tutto questo traffico dentro un tunnel cifrato. A patto di configurarlo bene, per far passare anche il DNS attraverso la VPN e non lasciarlo libero di andare per i fatti suoi.

Perché la VPN non sempre previene le perdite DNS

In breve: configurazioni. A volte il sistema utilizza il DNS locale del provider. Il browser può attivare un DoH “intelligente” che manda le richieste fuori dalla VPN. Il client VPN potrebbe non forzare il forwarding del DNS attraverso il tunnel. Oppure, semplicemente, in caso di fallback il resolver principale non è raggiungibile e il sistema ne usa uno vicino. Benvenuti alle perdite DNS.

E un altro dettaglio spesso dimenticato: anche se il DNS va nel tunnel, i metadata del traffico verso il resolver possono tradirti attraverso il fingerprint TLS o pacchetti anomali, soprattutto in reti DPI tarate per cacciare traffico “atipico”. Qui si vede la differenza tra DoH e DoT: uno si camuffa meglio da traffico web comune, l’altro è più semplice da diagnosticare e spesso più stabile. Mettiamoli a nudo.

DoH vs DoT (e DoQ): guida pratica senza giri di parole

Cos’è DoH: il DNS dentro HTTPS

DNS-over-HTTPS invia le richieste come traffico web normale. Porta 443, protocolli HTTP/2 o HTTP/3, TLS obbligatorio. Ai filtri sembra un sito HTTPS qualunque. Ecco il trucco di DoH: è estremamente difficile da bloccare senza paralizzare metà del web. DPI può tentare di riconoscerlo dai pattern dei pacchetti, URL distintivi o fingerprint TLS, ma i resolver moderni nel 2026 si mascherano al massimo, e i browser supportano ECH, che nasconde il nome host nella stretta di mano TLS.

I vantaggi di DoH sono evidenti: ottima resistenza ai blocchi, facile integrazione nei browser, HTTP/3 riduce la latenza in caso di perdita pacchetti, e la cache degli user agent è flessibile. Svantaggi? Header HTTP più pesanti, diagnosi più complicate, qualche overhead extra quando il server non supporta HTTP/3 o è lontano. Alcune proxy aziendali bloccano end-point HTTPS non standard.

Cos’è DoT: la classica TLS sulla porta 853

DNS-over-TLS è il DNS “pulito” incapsulato in TLS sopra TCP, porta 853. Semplice, trasparente, prevedibile. Comodo per amministratori per monitoraggio e debug, e per app che non vogliono complicazioni con HTTP. DoT funziona bene su connessioni stabili, con latenze prevedibili e meno sovrastrutture.

Il problema principale di DoT è la visibilità. DPI riconosce facilmente la porta 853 e la blocca. Si può aggirare cambiando porta o usando SNI con ECH, ma DoT è più facilmente bersaglio per la sua “fama”. Dove il blocco è assente o blando, DoT è stabile e spesso veloce, soprattutto con un buon anycast del resolver del provider.

E DoQ e ODoH? Dove stanno nel 2026

DoQ - DNS-over-QUIC - è un protocollo giovane ma promettente basato su QUIC. Combina i vantaggi migliori: RTT minimi, resistenza alle perdite, nessun problema con la frammentazione. Nel 2026 è supportato da un numero crescente di resolver pubblici, e sulle reti mobili spesso è più stabile di DoT. Il suo riconoscimento da parte dei DPI via pattern QUIC è controverso, dipende da paese e provider.

ODoH — Oblivious DoH — cifra la richiesta in modo che il resolver non veda l’IP cliente, e il proxy non veda il contenuto. Privacy al top, ma con maggiori latenze. Usato in abbinamento a VPN diventa uno strato triplo: privato ma più lento. Sotto censura severa può salvare casi sensibili. Nella vita quotidiana basta spesso DoH/DoT.

Privacy e sicurezza: chi vede cosa davvero

Metadata: ECH, nome resolver e realtà

Il DNS cifrato nasconde i nomi di dominio nelle richieste. Ma ogni storia ha una coda: a chi ti connetti? Al resolver, il cui IP è visibile. Se è un servizio pubblico popolare, i DPI possono bloccare in base all’IP. ECH aiuta a occultare il nome host in TLS, ma il fatto stesso della connessione è visibile. Provider intelligenti usano CDN e anycast per distribuire il traffico e non risultare “diversi”.

In modalità VPN, il provider vede solo l’IP del server VPN. Il resto del DNS avviene nel tunnel. Nessuna perdita se tutto è configurato bene. Ma se il browser usa DoH direttamente, fuori VPN, la privacy è compromessa. Controllo e priorità sono essenziali.

DPI e blocchi: resilienza di DoH, DoT e DoQ

L’esperienza 2024–2026 mostra che DoH in HTTP/3 è il più resistente sotto censura dura. È più difficile da scovare e bloccare senza attivare effetti collaterali estesi. DoT su 853 è più spesso bloccato, ma con porte alternative e architetture adeguate sopravvive. DoQ viene intercettato in alcuni paesi tramite pattern QUIC, ma non ovunque — dipende da DPI e regolatori.

Aggiungiamo fingerprinting TLS. Alcuni server/client si riconoscono per aperture cifre e ordine di estensioni. Nel 2026 è di moda mascherarsi da browser popolari. La soluzione sono client con fingerprint adattivo e resolver con ECH e parametri moderni. In combinazione con VPN è un plus: nel tunnel il fingerprinting perde quasi potere se tutto il traffico scorre su un unico canale cifrato.

Log e giurisdizione: di chi fidarsi

Non giriamo intorno. Fidarsi del provider DNS e VPN è fondamentale. Log zero, audit indipendenti, regole chiare per conservare metadata sono il minimo. La giurisdizione e la gestione delle richieste legali sono altrettanto importanti. Nel 2026 i migliori giocatori pubblicano regolarmente report di trasparenza e fanno controlli esterni sul codice e infrastruttura.

Consigliamo di guardare oltre il marketing: leggi SLA, la geografia dei POP, supporto ECH, DoQ, DDR. Chiedi se conta da dove ti connetti: alcuni provider in regioni specifiche inseriscono filtri extra per richieste di regolatori. Trasparenza non è uno slogan, ma PDF e pagine tecniche concretamente accessibili, anche se non linkate qui.

Modello di minacce: chi è il tuo avversario

Se viaggi, la minaccia sono manomissioni nelle reti pubbliche, intercettazioni DNS e iniezioni HTTP. Per te DNS cifrato + VPN sono indispensabili. Se vivi sotto censura attiva, l’avversario è DPI e blocchi. Allora DoH sopra VPN è preferibile, talvolta con ODoH per casi sensibili. In reti aziendali con logging esteso, devi accordarti sulle regole o sarai escluso. Giornalisti e attivisti puntano su privacy massima e verifica perdite costante.

Performance e stabilità: la velocità conta

Latenze, TCP vs QUIC e 0-RTT

DoT usa TCP+TLS. Due handshake, più possibilità di TLS 1.3 0-RTT in scenari di riconnessione. DoH su HTTP/2/3 può multiplexare richieste su una sola connessione, in HTTP/3 su QUIC è più resistente a perdite e riordini. Su rete mobile instabile QUIC spesso vince in stabilità, evitando blocchi per frammentazione e recuperando più velocemente.

Nel 2025–2026 i test reali dicono: DoH/HTTP3 vince su DoT di 10–25% in risoluzione DNS su LTE instabile a cache fredda; in Wi-Fi la differenza è minima. Su fibra veloce, DoT a volte è più rapido per stack semplice e meno overhead. Conclusione: non conta solo il protocollo ma il server, la distanza al POP e funzioni moderne come 0-RTT e anycast.

Reti mobili e roaming

In roaming le policy sono più rigide, NAT più complessi, perdite più frequenti. DoH su HTTP/3 quasi sempre più prevedibile. Ma soprattutto dipende dal protocollo VPN: WireGuard è solitamente più veloce e stabile di OpenVPN-TCP; con MTU e keepalive corretti la differenza è netta. VPN su UDP + DNS su QUIC = doppio vantaggio in resistenza alle perdite. Diagnosi però più complicata.

Geografia, anycast e cache

I buoni provider DNS mantengono reti anycast: raggiungi il nodo più vicino automaticamente. Ma il “più vicino” non è sempre il più veloce se la route è strana. Inoltre la VPN può indirizzarti in un altro paese, creando situazioni curiose: sei a Varsavia ma il resolver risponde da Amsterdam. Non è un problema se il POP è rapido, ma per chi valuta millisecondi (gaming) è meglio scegliere VPN e DNS geograficamente vicini.

Cache locale e stub resolver

Per non bombardare il resolver remoto ad ogni richiesta, usa uno stub cache locale: systemd-resolved, Unbound in forwarder mode, Stubby, dnscrypt-proxy o cloudflared. Riduce RTT e carico. Fondamentale è proibire fallback a porta 53 non cifrata e configurare upstream rigidi DoH/DoT dentro la VPN. Sì, un’altra configurazione, ma quella che non tocchi per mesi.

Come far convivere DoH/DoT e VPN: topologie efficaci

DNS nel tunnel: la soluzione più sicura

Schema classico: la VPN si avvia, passa al client gli indirizzi DNS dentro al tunnel, e tutto il traffico DNS passa dal server VPN verso il resolver. Idealmente il resolver criptato verso i server autoritativi o ricorsivi. Vantaggi: minime perdite, politica semplice. Svantaggi: dipendenza dal provider VPN e dalla qualità DNS.

Così funziona la maggior parte delle VPN decenti nel 2026: offerte proprie di DNS anycast nel tunnel. I migliori hanno ECS-off, QNAME minimization, resilienza e protezione da cache poisoning. Se il tuo provider non offre DNS cifrato nel tunnel, puoi mettere un client DoH locale sopra la VPN: doppia cifratura, perché no?

DoH/DoT locale con routing VPN

Installa uno stub resolver sul dispositivo che comunica col DoH/DoT pubblico; traffico verso IP resolver passa attraverso VPN. L’esterno vede solo traffico verso server VPN; dentro c’è DNS cifrato verso un provider scelto. Comodo, flessibile, controlli il resolver. Attenzione a non far partire lo stub prima della VPN, per evitare di inviare richieste in chiaro. Ritardi di avvio e dipendenze da interfaccia sono indispensabili.

Split tunneling per DNS: quando si può e quando no

A volte serve che certe richieste escano senza VPN: domini locali, risorse aziendali, smart home. È lo split-tunneling. Per DNS è rischioso se la rete non è sicura. Su router casalinghi con DoT si può, se ti fidi del canale. In reti pubbliche è sconsigliato. In azienda solo secondo regole concordate e con proxy DoT/DoH interni.

Policy OS e browser: chi comanda

Android con Private DNS (DoT), iOS con profili DNS, Windows con policy DoH, Firefox e Chrome con proprie configurazioni: un vero orchestra. Il direttore? Il client VPN. Deve forzare il DNS di sistema e bloccare richieste dirette alle porte 53/443 verso resolver sospetti. Altrimenti il browser si fa furbo e attiva “Secure DNS” fuori tunnel. Consigliamo: centralizza le regole, verifica che la policy VPN abbia priorità e impedisca bypass.

Pratica: ricette passo-passo per configurazioni comuni

WireGuard + DoH tramite systemd-resolved o cloudflared

Scenario Linux e Windows con WSL comodo e semplice: lancia WireGuard, setta in config DNS 127.0.0.1 (o ::1), il resolver locale (es. cloudflared) punta all’upstream DoH. La rotta verso IP provider passa per il tunnel. Trucchetto: aggiungi regole firewall in PreUp per bloccare DNS fuori interfaccia wg per prevenire rare perdite in riavvio.

Dettagli pratici: controlla MTU, di solito 1280–1420 a seconda della rete. MTU errata causa timeout invisibili e perdite. Attiva PersistentKeepalive=25 per NAT mobile. Disabilita fallback DNS in systemd-resolved, configura solo DoH, disattiva LLMNR e Multicast-DNS dove inutili.

OpenVPN + DoT tramite Stubby o Unbound

OpenVPN è vivo e vegeto. Con UDP latenze ok, con TCP su TCP occhio al blocking “head-of-line” specie mobile. DoT con Stubby/Unbound funziona bene: OpenVPN spinge il client su host interno doT-proxy, blocca uscite porte 53. Attiva verifica certificati in Stubby per evitare MITM da NAC alberghieri.

Consiglio: attiva QNAME minimization in Unbound per ridurre dati su navigazione trapelati ai server root e superiori. Controlla che il server OpenVPN non faccia forwarding DNS non criptato verso ISP. Il resolver lato server dovrebbe essere cifrato o ricorsivo con politiche corrette.

iOS/iPadOS: profilo DNS + VPN

Su iOS hai due strade: VPN con proprio DNS cifrato in tunnel o profilo configurazione DoH/DoT via MDM. Nel 2026 molte VPN iOS forzano DNS, ma browser possono avere profili propri. Il segreto: un profilo “principale”. Se hai iPhone aziendale in MDM, coordina con admin o rischi conflitti e perdite fastidiose.

Test: dopo connessione VPN visita sito test perdite DNS (qualsiasi test affidabile), assicurati che resolver sia del provider VPN o DoH scelto. Se vedi ISP, c’è un problema. Disattiva iCloud Private Relay in reti specifiche se interferisce e stravolge routing/regole.

Android 14–16: Private DNS + VPN

Android offre Private DNS (DoT) con modalità “Strict”, inserisci host resolver e tutte le richieste di sistema vanno lì. Il client VPN deve forzare il traffico attraverso tunnel, per fortuna quota importante di provider lo fa già. Se il tuo client non ce la fa, prova un altro. Ideale che la VPN fornisca un host DoT accessibile solo dentro al tunnel.

Attenzione: alcuni produttori aggiungono ottimizzazioni di risparmio energia che spengono il client DNS in background. Risultato: spike di latenze e fallback. Soluzione: escludere da ottimizzazione aggressiva le app VPN e DNS, aggiungerle agli esclusi batteria e bloccare ottimizzatori di rete. Fastidioso ma salva tempo e nervi preziosi.

Insidie: dove si inciampa più spesso

Perdite DNS, WebRTC e fallback inattesi

Il più frustrante: tutto configurato bene ma perdite ci sono. Colpevole tipico: WebRTC nel browser, che espone indirizzi locali e aggira DNS con regole proprie. Disabilita o limita WebRTC nei settaggi, usa estensioni che vietano DNS del browser, e blocca richieste dirette alle porte 53/853/443 verso resolver esterni fuori VPN con firewall.

Secondo motivo: fallback. Resolver irraggiungibile, sistema sostituisce con uno vicino senza preavviso. Soluzione: elenchi rigidi, “only use configured DNS” nei sistemi, blocco firewall su DNS non autorizzati, controlli periodici. Abitua a verificare perdite dopo aggiornamenti OS o client VPN. Salvaguardia lo stress.

Blocchi SNI e fingerprint TLS

Prima dell’ECH, SNI rivela il nome host del resolver. Nel 2026 ECH è ampiamente supportato da browser moderni e provider importanti, ma non ovunque. Se il tuo resolver non ha ECH valuta un cambio o instrada traffico via VPN per mascherare l’esposizione. Inoltre, osserva il fingerprint TLS del client DoH/DoT: alcune soluzioni “out of the box” mostrano set di estensioni esotico che attira DPI.

MTU, frammentazione e timeout "fantasma"

MTU sbagliato rompe anche la configurazione più elegante. QUIC soffre meno, TCP di più. Se vedi timeout strani, richieste ripetute e ICMP 'filtered', verifica subito MTU sul tunnel. WireGuard preferisce valori 1420 o sotto, OpenVPN è ancora più pignolo. A volte aiuta MSS clamping sul router. Tre lettere noiose ma magiche per la stabilità.

Browser diversi, caratteri diversi

Firefox ama il suo DoH, può ignorare il DNS di sistema. Chrome si protegge se vede supporto del provider, Edge cerca di essere utile ma a volte esagera. Soluzione: policy manuali. In ambiente aziendale usa ADMX, in casa regola e disattiva DoH automatico se usi DNS sistema o VPN. Ricorda: un solo capitano sulla nave, meglio il client VPN.

Ambito aziendale e DevOps: regole a parte

Split-horizon DNS e zone interne

Nel business serve split-horizon: stessi domini danno IP diversi dentro e fuori. Usare DoH pubblico sopra VPN per risolvere internal.company.local porta problemi. Serve un resolver interno nel tunnel, che conosce le zone locali e poi esce verso DoT/DoH pubblici. Profili che cambiano in base a posizione sono utili: in ufficio corporate, fuori ufficio pubblico.

Cifra tutto: client — resolver interno — upstream pubblico. Non dimenticare controllo accessi: mTLS tra servizi, ACL su resolver. Non è paranoia ma buon senso quando hai decine di microservizi e dipendenti remoti.

DoH per applicazioni e service mesh

Anche i microservizi vogliono DNS. Se hai service mesh (Istio, Linkerd ecc.), pensa a un proxy locale che risolva con DoH/DoT e cache. Riduce latenza e problemi di rete. In Kubernetes puoi usare NodeLocal DNSCache con forwarding DoT/DoH sopra. Importante: evita catene di tanti proxy, 2–3 livelli è il limite ragionevole.

Zero Trust e ZTNA

Nel modello Zero Trust il DNS è segnale di sicurezza. Ma non significa loggare tutto. Nel 2026 compromesso: anonimizzazione, aggregazione, conservazione metadata limitata, e protezione da DNS-exfiltration attiva. Resolver smart rilevano query TXT lunghe e tunneling. Migliora la policy, non solo la cifratura.

Log, SIEM e dati personali

Raccogli log? Bene. Rispetta leggi locali e privacy dipendenti. Conserva hash, non domini completi o usa pseudonimizzazione. Notifica trasparentemente gli utenti. Lato resolver attiva minimizzazione richieste e vieta feature sperimentali “arcobaleno” comode ma invasive.

Casi reali e dati

Caso 1: utente sotto blocchi

Situazione: rete mobile, DPI attivo, porta 853 bloccata a intermittenza, blocchi selettivi su QUIC. Soluzione: VPN WireGuard con MTU 1280, DoH su HTTP/3 dentro tunnel anycast provider, routing solo tunnel, vietato DNS fuori interfaccia. Risultato: riduzione errori risoluzione da 12% a 1–2% in orario di punta, caricamento siti +15–20% rispetto a DoT con perdita TCP.

Nota: di notte DPI cambia profili e DoQ migliora, ma lasciamo DoH come principale per prevedibilità. ECH nel browser riduce blocchi mirati su SNI.

Caso 2: gamer e streaming

Situazione: fibra 300 Mbps, rete stabile, target latenza minima. Soluzione: DoT con Unbound locale e forwarding a provider con POP in città, VPN opzionale per geo-restrizioni. Risultato: latenza risoluzione a cache fredda 12–16 ms, calda 1–3 ms. DoH non porta miglioramenti in stabilità, aggiunge latenza per overhead HTTP. Conclusione: senza censura DoT è onesto e veloce.

Caso 3: giornalista in Wi-Fi pubblico

Situazione: Wi-Fi aeroporto, proxy MITM HTTPS, captive portal sospetti. Soluzione: VPN WireGuard, blocco assoluto DNS fuori tunnel, DoH client locale cloudflared, fingerprint TLS camuffato da browser popolare, verifica perdite pre-pubblicazione. Risultato: zero perdite, accesso stabile a strumenti, latenza migliorata del 25% dopo tuning MTU.

Caso 4: piccola impresa con team remoto

Situazione: dipendenti in 6 paesi, livelli di internet variegati. Soluzione: ZTNA provider con filtro DNS DoH integrato in tunnel, Unbound locale in ufficio, modalità Forward Secure, Vietato fallback, policy browser via MDM. Risultato: incidenti perdite DNS azzerati, supporto ridotto di un terzo. Passaggio parte traffico a DoQ nei paesi mobile migliora stabilità videochiamate.

Consigli e checklist 2026

Quando scegliere DoH

Scegli DoH se sei sotto censura, rete instabile o spesso in movimento, VPN supporta HTTP/3 e vuoi mascherarti come traffico web normale. Utile per gestire policy centralizzate su browser/app. Vantaggi: avvio rapido, molti client già pronti.

• Verifica accuratamente supporto ECH e HTTP/3 sul resolver.
• Blocca trafiico diretto verso resolver pubblici fuori VPN.
• Attiva cache locale e monitora fallback.

Quando scegliere DoT

Opta per DoT se rete stabile, censura leggera o assente, desideri semplicità e prevedibilità. Admin apprezzano facilità di monitoraggio. Su fibra è spesso più veloce. In azienda si integra facilmente in policy e firewall.

• Usa porte non standard solo se necessario.
• Controlla supporto 0-RTT e anycast del provider.
• Elimina fallback sulla porta 53 ovunque possibile.

Quando considerare DoQ e ODoH

DoQ: se rete mobile con perdite e provider solido sul QUIC. ODoH: per scenari sensibili, dove privacy conta più della velocità: difensori diritti umani, giornalisti in zone calde, investigazioni private. DoQ accelera l’esperienza quotidiana, ODoH alza l’anonimato a costo di latenza.

Come scegliere provider DNS e VPN

Criteri chiari ma rigorosi: audit e trasparenza, supporto ECH, HTTP/3, DoQ, report indipendenti, SLA comprensibili. Osserva geografia POP, tempi risposta locali, stabilità sotto carico, supporto DDR per scelta automatica di resolver protetto. Per VPN: WireGuard stabile, kill switch efficace, blocco bypass DNS, DNS cifrato in tunnel.

Conclusioni: riflessioni finali e piano veloce

Checklist in 5 passi per oggi

Primo: scegli modalità principale — DoH o DoT — in base a rete e minacce. Secondo: decidi dove risiede il DNS — dentro VPN o localmente con routing tunnel. Terzo: disabilita fallback e blocca vie traverse con firewall. Quarto: configura browser e OS per evitare conflitti. Quinto: testa perdite e misura latenza, annota risultati.

Cosa aspettarsi nel futuro

Nel 2026–2027 vedremo ampia diffusione di ECH, DoQ e DDR. Browser abilitano DNS protetto di default più aggressivamente. DPI più sofisticati nel fingerprint, ma VPN con mascheramento e routing intelligente mitigheranno i rischi. Il consiglio? Mantieniti su una o due configurazioni stabili, evita rincorse a ogni moda.

In sintesi: non esiste il “migliore” universale, ma il “migliore per te”

Sintetizzando e onestamente: sotto censura e reti instabili scegli DoH con VPN. In condizioni serene e fibra, DoT con buon anycast. Per mobile e perdite guarda a DoQ. Per privacy estrema ODoH. Non temere test e errori. L’importante è tenere DNS nel tunnel, spegnere fallback e verificare configurazioni regolarmente. Il resto è tecnica.

FAQ: il succo

Cosa scegliere con VPN: DoH o DoT nel 2026?

Se hai censura aggressiva o rete instabile, spesso vince DoH sopra VPN grazie alla mimetizzazione in HTTPS e HTTP/3. Se la rete è pulita e vuoi prevedibilità, DoT può essere più veloce e semplice. Valuta latenza e stabilità nella tua realtà.

DoQ è pronto per l’uso in produzione?

Sì, se il resolver lo supporta e la rete non blocca QUIC. Su mobile DoQ spesso offre esperienza migliore. Alcuni paesi limitano QUIC, controlla. Se bloccato, torna a DoH/HTTP3 o DoT.

Come verificare perdite DNS sotto VPN?

Dopo connetterti visita un noto servizio test perdite DNS e confronta resolver visti con quelli attesi. Se vedi ISP, c’è perdita. Disabilita WebRTC e blocca uscite dirette a 53/853/443 verso resolver estranei fuori tunnel.

Conviene attivare ECH?

Sì, se disponibile. ECH nasconde nome host in TLS e complica vita DPI. Abbinato a DoH/HTTP3 migliora robustezza. Se resolver o browser non lo supportano, con VPN non è grave, ma senza VPN ECH aiuta molto.

ODoH ha senso per uso comune?

Di solito no, per via di latenze. Ma in scenari sensibili offre privacy in più: resolver non vede chi sei, proxy non vede cosa chiedi. Abbinato a VPN è una vera armatura, però lenta.

Perché a volte DoT è più veloce di DoH?

Perché usa uno stack più semplice, meno overhead HTTP, e provider con DoT ottimizzato e vicini geograficamente. Su rete cablata stabile vince. Su mobile con perdite il vantaggio può andare a DoH/HTTP3 o DoQ.

Basta scegliere un “buon” VPN?

No. VPN è solo metà strada. L’altra metà è DNS corretto: niente fallback, cifratura, routing in tunnel, policy OS e browser adatte. Senza tutto questo, anche il miglior VPN non evita perdite o latenze anomale.