DNS over HTTPS: què és i com protegeix les teves consultes

Guia Alfa » Informàtica » DNS over HTTPS: què és i com protegeix les teves consultes

Quan tecleges una adreça web, hi ha una peça que treballa en segon pla perquè arribis al lloc correcte: el sistema de noms de domini. El DNS tradueix noms fàcils de recordar a adreces IP que entenen els ordinadors. És còmode, sí, però durant anys ha funcionat amb una vulnerabilitat important: aquestes consultes viatjaven sense xifrar. Per això ha cobrat protagonisme el DNS over HTTPS, també anomenat DoH, una capa extra de protecció perquè el teu proveïdor d'Internet no tingui tan fàcil saber quins dominis visites.

Convé deixar una idea clara des del principi: DoH millora la privadesa de les consultes DNS, però no és una VPN ni converteix tota la teva connexió en un túnel secret . Al llarg d'aquest article veurem què és exactament, per què s'ha tornat popular, com s'activa a Chrome, Edge i Firefox, quins avantatges i inconvenients té, en què es diferencia de DNS over TLS i d'una VPN, i fins a quin punt arriben els límits tècnics i pràctics.

Què és DNS i per què el sistema tradicional es queda curt

Els servidors DNS són una d'aquelles peces que gairebé ningú no mira però que sostenen bona part de la navegació. El seu treball consisteix a posar en relació un nom de domini amb l'adreça IP del servidor corresponent . Quan entres a una web, el teu equip no entén de lletres: necessita una IP per saber a quina màquina connectar-se. Molts encaminadors vénen amb servidors DNS ja configurats per l'operadora, i això fa que el procés sigui còmode, encara que també deixa un rastre visible per a qui controli aquesta infraestructura.

El problema de fons és que les consultes DNS clàssiques es fan en text pla i sense protecció . Això obre la porta a escoltes, atacs d'intermediari i manipulacions de la resposta. Un proveïdor d'Internet pot saber quins dominis consultes i quan ho fas; un atacant en una xarxa compartida pot intentar interceptar la petició i tornar una resposta fraudulenta. Aquesta tècnica es coneix com a DNS hijacking i pot acabar portant-te a una pàgina falsa, a publicitat no desitjada oa un lloc pensat per robar dades. Governs i operadores també han aprofitat històricament aquestes debilitats per aplicar censura, bloquejar dominis o mostrar publicitat addicional.

• Escoltes passives: algú observa les consultes i dedueix quins serveis o webs freqüents.
• Home entremig: s'intercepta la comunicació i es modifica la resposta per suplantar un servidor.
• Bloquejos i filtrats: s'impedeix resoldre determinats dominis per controlar l'accés a continguts.

DNS over HTTPS: xifrar la consulta perquè no vagi a la vista de tothom

DNS over HTTPS, o DoH, és una solució que aprofita el protocol HTTPS per transportar les consultes i les respostes DNS de forma xifrada . En lloc d'enviar una petició DNS en clar, el dispositiu l'encapsula en una connexió segura, normalment usant el port 443, el mateix que fan servir les pàgines web segures. Així, tant la pregunta com la resposta queden protegides i un observador extern no les pot llegir amb facilitat.

Perquè això funcioni, el servidor DNS al qual es consulta també ha de suportar DoH . No n'hi ha prou amb activar una opció al navegador: el resolvedor triat ha de parlar aquest estàndard. L'especificació ha anat evolucionant i encara es considera una tecnologia en desenvolupament, encara que des del 2018 empreses com Google i la Fundació Mozilla han fet proves i ho han anat integrant. A més de la millora de privadesa, les proves apunten que DoH pot reduir la latència i fer que les consultes siguin més lleugeres, perquè no sempre cal resoldre el domini complet sinó només la part mínima necessària.

Avantatges de DoH: més privadesa, menys manipulació i millor rendiment

L'avantatge més evident és la seguretat. En viatjar xifrades, les consultes DNS són molt més difícils d'espiar o de modificar . Això complica atacs d'intermediari, redueix l'exposició a xarxes Wi-Fi públiques i evita que un operador local pugui veure amb claredat quins dominis estàs sol·licitant. Com que el trànsit DoH utilitza el port 443, es barreja amb la resta de connexions HTTPS i costa de distingir-lo d'una visita web normal.

També hi ha motius de rendiment. DoH pot disminuir la latència i alleugerir les comunicacions DNS gràcies a canvis en la manera de resoldre noms ia un millor aprofitament de la memòria cau. Per exemple, el mètode GET d'algunes API està pensat per emmagatzemar-se en memòria cau amb més eficàcia. A la pràctica, això es pot traduir en una navegació una mica més ràpida, encara que no és una millora màgica ni es nota sempre. A més, en implementar-se al navegador, l'usuari no ha d'esperar que la seva operadora decideixi activar-lo.

Inconvenients i debats: quan el xifratge complica la vida

No tothom veu DoH amb bons ulls. El mateix xifrat que protegeix l'usuari també dificulta la supervisió de la xarxa . Molts programes de control parental es basen a inspeccionar les consultes DNS per saber quines pàgines intenten obrir els menors; amb DoH, aquesta tasca es torna molt més complicada i fins i tot pot resultar inviable. Una cosa semblant passa amb els administradors de xarxes corporatives, que perden visibilitat sobre els dominis consultats i no poden aplicar certes regles amb la mateixa facilitat.

Els proveïdors dInternet també perden capacitat per monitoritzar accessos i per bloquejar determinats dominis per ordre duna institució. Això genera un debat legítim: hi ha qui ho veu com una victòria de la privadesa i qui ho considera un problema de control i gestió . En el cas de DoT, a més, es critica que faci servir un port propi i reconeixible, cosa que permet identificar que hi ha consultes DNS encara que no se sàpiga exactament què es pregunta. DoH evita aquest senyal tan clar en camuflar-se entre el trànsit HTTPS, però a canvi els administradors de xarxa es queden amb menys eines per gestionar les comunicacions.

Com activar DoH a Chrome, Edge i Firefox

Activar DoH en un navegador modern sol ser senzill, sobretot si està basat en Chromium o si es tracta del Firefox. L'opció existeix, encara que en alguns casos està amagada a menús de configuració avançada . Abans de tocar res, convé tenir clar que el navegador només protegeix les vostres pròpies consultes: altres aplicacions del dispositiu poden seguir usant un altre sistema DNS si no es configura també a nivell del sistema.

Google Chrome

A Chrome, el camí ràpid és escriure chrome://flags/#dns-over-https a la barra de direccions. Això us porta directament als Flags o funcions experimentals de Chrome. Veureu seleccionada una opció anomenada Secure DNS lookups; prem el desplegable que posa Default i tria Enabled. Després hauràs de reiniciar el navegador perquè el canvi faci efecte.

microsoft Edge

A Edge basat en Chromium el procés és pràcticament idèntic. Obre el navegador i escriu edge://flags/#dns-over-https a la barra de cerca. Entraràs als Flags d'Edge i apareixerà la mateixa opció Secure DNS lookups. Canvia Default per Enabled i reinicia el navegador quan t'ho demani.

Mozilla Firefox

A Firefox no cal anar als Flags. Premeu el botó de menú situat a dalt a la dreta i entreu a Opcions . Dins de la secció General, baixa fins al final i prem Configuració de xarxa. A la finestra que s'obre, marca la casella Activar DNS sobre HTTPS. Podràs triar entre proveïdors com Cloudflare i NextDNS per fer el xifratge mitjançant HTTPS.

DNS over TLS (DoT): l'altre camí xifrat

DNS over TLS, o DoT, és una altra manera de protegir les consultes DNS. En lloc d'usar HTTPS, utilitza TLS sobre una connexió TCP i un port estandarditzat, el 853 . TLS és la mateixa base de seguretat que hi ha darrere de HTTPS, així que la idea és semblant: crear un túnel xifrat on només els dos participants puguin desxifrar i processar la informació. D'aquesta manera, es dificulta un atac d'intermediari i s'evita que un tercer llegeixi o manipuli la consulta.

DoT té els seus avantatges, sobretot davant del DNS clàssic, que no ofereix cap mesura de seguretat. El xifratge impedeix que els ciberdelinqüents interceptin les peticions i també posa traves a certes mesures de censura . Ara bé, requereix compatibilitat per part del client i del servidor. Hi ha diversos proveïdors que ofereixen servidors compatibles, però per fer-lo servir en un ordinador de sobretaula o portàtil sol cal instal·lar programari addicional; a Android modern, almenys des d'Android 9, ja ve integrat. A Windows i Linux hi ha solucions, encara que no sempre són tan transparents com un voldria.

Entre els inconvenients, molts experts en protecció de dades critiquen que DoT utilitzi un port únic i reconeixible. Encara que no es pugui saber quina pàgina es consulta, sí que es pot detectar que hi ha trànsit DNS . Per a alguns administradors de xarxa això és útil, perquè els permet mantenir una visió general del que passa; per a altres, és un senyal que preferirien amagar. A més, DoT encara no està tan estès com el DNS tradicional i la seva adopció del costat del servidor és limitada. Hi ha preocupació perquè unes poques empreses concentrin cada vegada més les consultes DNS, cosa que podria crear una mena de monopoli internacional.

DoH davant DoT: dues maneres de protegir el mateix

La diferència principal entre DoH i DoT és al port i en com es camufla el trànsit. DoT utilitza el seu propi port, el 853, mentre que DoH recorre al 443 i es barreja amb les connexions HTTPS normals . Aquesta diferència, que sembla menor, ha generat un debat profund. Des del punt de vista de la privadesa, que una consulta DNS no es pugui distingir de la resta del trànsit és un avantatge: si no es reconeix, tampoc es pot manipular amb tanta facilitat. Des del punt de vista de la gestió de xarxes, en canvi, es perd control i és més difícil aplicar polítiques de seguretat o de filtratge.

Al fons hi ha dues visions. L'IETF, el consorci que desenvolupa molts estàndards d'Internet, és darrere de DoT , mentre que Google i la Fundació Mozilla han impulsat amb força DoH. No són tecnologies enemigues, però sí que representen formes diferents d'entendre la privadesa, la visibilitat de la xarxa i el paper dels intermediaris. L'elecció entre l'una i l'altra depèn de què es vulgui protegir i de qui necessiti gestionar la xarxa.

DoH davant una VPN: protegeix la pregunta, no tot el viatge

DoH i una VPN solen aparèixer en les mateixes converses sobre privadesa, però no fan el mateix. DoH protegeix la consulta de noms; una VPN protegeix la ruta que recorren les teves dades . La manera més senzilla d'entendre-ho és pensar que DoH fica una pregunta sensible en un sobre segellat, mentre que una VPN fa que tot el viatge transcorri per un túnel privat abans de tornar a la carretera pública. Tots dos poden millorar la privadesa, però només un està dissenyat per cobrir el trànsit de telèfons, tauletes i ordinadors de forma àmplia.

Què fa el DNS abans que es carregui un lloc

Abans que el navegador pugui carregar una web, el dispositiu necessita saber on és. El DNS funciona com una guia telefònica que converteix un nom de lloc en una adreça IP . Això passa constantment: en obrir una pàgina, llançar una aplicació, actualitzar el correu o reproduir un vídeo. La majoria de les vegades succeeix en silenci i no ho notes, la qual cosa està bé per a la comoditat, però també fa que sigui fàcil passar-ho per alt com a problema de privadesa. Les consultes DNS tradicionals no estan xifrades, així que el vostre proveïdor, la vostra empresa, el vostre centre educatiu, la Wi-Fi d'una cafeteria o la xarxa d'un hotel podrien veure quins dominis intenta assolir el vostre dispositiu. No veuen el contingut complet d'una pàgina HTTPS, però sí un esquema força revelador de la teva activitat.

Una consulta DNS no mostra cada pàgina que heu vist ni el que escriviu en un formulari, però una llista de dominis pot exposar hàbits, interessos, eines de treball, investigacions de salut o serveis financers . Per això el DNS xifrat s'ha convertit en una funció de privadesa útil. No ho ensenya tot, però revela més del que imagina molta gent.

Què amaga DoH i què deixa al descobert

DoH envia les consultes DNS a través de HTTPS, el mateix protocol xifrat que usen les webs segures. La petició surt del dispositiu embolicada amb xifratge i arriba a un resolvedor que suporta l'estàndard . En una Wi-Fi pública, això pot dificultar que l'operador de la xarxa llegeixi les consultes a la lleugera. Si el vostre proveïdor d'Internet gestiona el DNS, canviar a un resolvedor DoH pot evitar que vegeu aquestes cerques de la manera habitual. A més, si una xarxa manipula els resultats de resolució de noms, el DNS xifrat pot reduir algunes maneres de manipulació.

Ara bé, DoH amaga la pregunta, no tota la conversa. Podeu impedir que alguns observadors vegin amb claredat la cerca de dominis, però no converteix tota la vostra connexió a Internet en un túnel xifrat . Quan el dispositiu coneix l'adreça IP, la resta de la connexió segueix el camí normal, llevat que una altra eina de privadesa canviï aquesta ruta. DoH no amaga la teva adreça IP real als llocs web, aplicacions o serveis als quals et connectes, ni et fa semblar que ets a una altra ciutat o país. Si inicieu sessió en un compte, el servei sap que sou tu. Si el navegador té galetes, sessions desades, identificadors publicitaris o una empremta reconeixible, DoH no esborra aquests senyals.

Tampoc no protegeix cada aplicació a no ser que estigui configurat a nivell del sistema i l'aplicació respecti aquesta configuració. Un navegador pot utilitzar DNS segur mentre una altra aplicació del mateix dispositiu utilitza una ruta DNS diferent . Algunes apps gestionen la seva pròpia xarxa i no sempre s'alineen amb el que heu configurat al sistema o al navegador. Per això DoH pot crear una falsa sensació de protecció completa: millora la privadesa de les consultes DNS, però no protegeix transferències d'arxius, trànsit de missatgeria, videotrucades, connexions de jocs, sincronització en segon pla o aplicacions de streaming com ho faria una VPN.

Què protegeix una VPN i què tampoc pot amagar

Una VPN protegeix una part diferent del viatge. Crea un túnel xifrat entre el dispositiu i un servidor VPN, i fa que el trànsit surti a Internet des d'aquest servidor . El proveïdor o la Wi-Fi local veuen una connexió xifrada al servidor VPN, no una visió clara de cada lloc i servei amb què contactes. A més, la VPN canvia l'adreça IP pública que veuen les webs i aplicacions: en lloc de la IP de casa teva o del teu operador mòbil, la destinació veu la IP del servidor VPN. Això pot reduir el seguiment basat en la ubicació, ajudar a evitar alguns perfils dISP i fer més segur lús de Wi-Fi públic.

Una VPN completa pot protegir navegadors, aplicacions de streaming, clients de correu, eines de còpia de seguretat al núvol, missatgeria, jocs i serveis en segon pla. També podeu encaminar les sol·licituds DNS a través del túnel xifrat quan està ben configurada , i per això convé fer una prova de fugida de DNS. Dit això, una VPN no és màgia. Si inicies sessió en una xarxa social, un correu, un servei de streaming o una botiga en línia, aquest servei segueix sabent qui ets. Podeu amagar el vostre IP original, però no fa anònim el vostre inici de sessió. El mateix val per a qualsevol cosa que envieu directament: el vostre nom, correu, dades de pagament, adreça d'enviament, fotos o missatges.

Les galetes i la petjada del navegador segueixen important. Les aplicacions poden crear problemes semblants mitjançant identificadors de publicitat, permisos, accés a la ubicació, escaneig de Bluetooth, noms de Wi-Fi propers i kits danàlisi. El codi maliciós (malware) és un altre límit difícil, perquè pot capturar dades abans que arribin al túnel VPN . En resum, una VPN oculta i xifra molta activitat, però no disfressa cada empremta digital.

Es poden fer servir DoH i una VPN alhora

Sí, es poden combinar, però la configuració ideal depèn de com gestionin el DNS el dispositiu, el navegador i l'aplicació VPN. En molts casos el més senzill és deixar que la VPN s'encarregue del DNS . Una bona aplicació hauria d'enviar les consultes DNS pel túnel xifrat perquè el proveïdor no les rebi directament. Així obtens privadesa DNS com a part de la connexió VPN sense haver d'ajustar el navegador per separat.

El problema apareix quan el navegador utilitza la seva pròpia configuració de DoH mentre la VPN intenta gestionar el DNS a nivell del sistema. Pot ser que no es trenqui res, però sí que es crea confusió : podries pensar que totes les consultes passen per la VPN i, en realitat, el navegador n'està enviant algunes pel seu compte a un resolvedor diferent. Aquí és on una prova de fugida de DNS resulta útil. Si després de connectar-te a la VPN apareixen els servidors DNS del teu operador, alguna cosa no funciona com esperaves; si apareixen servidors associats a la VPN, és més probable que la configuració vagi bé.

Quan n'hi ha prou amb DoH i quan convé una VPN

DoH pot ser suficient quan la teva principal preocupació és la privadesa bàsica de les consultes DNS al navegador. En una xarxa domèstica de confiança, activar DNS segur redueix l'exposició en text pla sense necessitat de canviar d'ubicació ni protegir totes les aplicacions . També és útil en xarxes on preocupa el filtratge o la manipulació de DNS, perquè en viatjar per HTTPS resulta més difícil d'inspeccionar o modificar de manera simple. Això no significa que esquivi qualsevol restricció ni que sigui una eina a prova de censura, però sí que és una millora notable davant del DNS sense xifrar. A més, és lleuger: no cal triar un servidor VPN ni canviar gran cosa de l'encaminament, i normalment no es nota un impacte apreciable a la velocitat.

Una VPN té més sentit quan vols protecció a tot el dispositiu i no només a les cerques DNS. Això inclou aeroports, hotels, escoles, espais de coworking, cafeteries i allotjaments de lloguer . A xarxes compartides no saps qui controla el router, qui més està connectat ni si algú intenta interceptar el trànsit. La VPN també ajuda quan no voleu que el vostre ISP construeixi un perfil a partir dels vostres patrons de navegació: encara que HTTPS protegeixi el contingut de les pàgines, les metadades de xarxa encara poden revelar patrons útils. Viatjar és un altre cas clar: una VPN pot fer que la connexió sigui més consistent, protegir-te en xarxes desconegudes i fer que els llocs vegin la ubicació del servidor VPN en lloc de la teva connexió local temporal.

Detalls tècnics de les API DoH de Google Public DNS

Google Public DNS ofereix dues APIs DoH diferents. Una està pensada per a RFC 8484 i accepta GET i POST a la URL https://dns.google/dns-query; l'altra és una API JSON que només admet GET a https://dns.google/resolve . També hi ha una interfície web a https://dns.google/ que mostra resultats JSON al navegador, però no implementa una API com a tal. No convé confondre aquesta interfície amb els URL de l'API ni amb https://dns.google/query. El servei no admet URLs http sense seguretat, i DoH també és compatible amb el servei DNS64 públic de Google, encara que en aquest cas només IPv6. La documentació de transport segur de Google inclou exemples amb curl i detalls de TLS, DoT i DoH.

Mètodes HTTP disponibles

El mètode GET pot reduir la latència perquè s'emmagatzema a la memòria cau amb més eficàcia. Les sol·licituds GET de RFC 8484 han d'incloure un paràmetre ?dns= amb un missatge DNS codificat a Base64Url , i és l?únic mètode que admet l?API JSON. El mètode POST només està disponible a l'API RFC 8484 i utilitza un missatge DNS binari amb application/dns-message al cos de la sol·licitud i de la resposta. El mètode HEAD ara mateix no està suportat i torna un error 400 Bad Request. Altres mètodes mostren errors 501 Not Implemented.

Codis d'estat i errors

L'API retorna diversos codis HTTP que cal conèixer. Un 200 OK indica que l'anàlisi HTTP i la comunicació amb l'agent de resolució DNS es van completar correctament ; el cos pot ser una resposta DNS binària o JSON segons lextrem, la capçalera Accept i els paràmetres GET. Compte: un error HTTP pot ser també una fallada de DNS, així que convé revisar el codi de resposta DNS, per exemple el camp «Estat» del JSON, per veure errors com SERVFAIL, FORMERR, REFUSED o NOTIMP.

• 301 Moved Permanently: el client ha de reintentar a la URL indicada a Location. Si la petició original era POST, només heu de reintentar amb GET si la nova URL especifica un paràmetre dns; en cas contrari, heu de repetir amb POST. També poden aparèixer 302, 307 i 308, i els clients DoH han de gestionar tots quatre. Els 301 i 308 permanents es poden escorcollar de forma indefinida. Les sol·licituds POST que reben 307 o 308 s'han de tornar a intentar sempre amb POST.
• Sol·licitud incorrecta de 400: problemes en analitzar els paràmetres GET o un missatge de sol·licitud DNS no vàlid. La majoria de missatges DNS invàlids reben un 200 OK amb FORMERR, però hi ha errors HTTP per a missatges il·legibles sense secció Question, amb una marca QR que indica resposta o amb combinacions de marques sense sentit.
• 413 Payload Too Large: el cos d'una sol·licitud POST RFC 8484 supera la mida màxima de missatge de 512 bytes.
• 414 URI Too Long: la capçalera de la consulta GET era massa gran o el paràmetre dns superava els 512 bytes.
• 415 Tipus de suport no compatible: el cos de la POST no tenia capçalera de tipus de contingut application/dns-message.
• 429 Too Many Requests: s'han enviat massa sol·licituds en un període. El client ha d'esperar fins al moment indicat a la capçalera Retry-After.
• Error intern del servidor 500: errors interns del servei DoH.
• No implementat 501: només s'implementen GET i POST; la resta torna aquest error.
• Passarel·la incorrecta de 502: el servei DoH no es va poder comunicar amb els agents de resolució de Google Public DNS. Reintentar en una altra direcció alternativa pot servir, però un pla de suport més eficaç és provar un altre servei DoH o canviar el DNS tradicional per UDP o TCP a 8.8.8.8.

Bones pràctiques de privadesa i rendiment

Els desenvolupadors d'aplicacions DoH haurien de limitar les capçaleres HTTP. Capçaleres com Cookie, User-Agent o Accept-Language poden revelar informació sobre la implementació del client i ajudar a desanonimitzar-lo . El que és recomanable és enviar només les capçaleres necessàries per a DoH: Host, Content-Type en el cas de POST i, si cal, Accept. L'User-Agent hauria d'incloure's en versions de desenvolupament o prova. També convé fer servir opcions de rebliment EDNS per emplenar les consultes fins a longituds comunes i dificultar l'anàlisi de trànsit. El farciment HTTP/2 és possible, però a diferència del d'EDNS no genera farciment en les respostes del servidor DoH.

El mètode POST de RFC 8484 només s'hauria d'usar en aplicacions o modes de navegador sensibles a la privadesa. Utilitza POST redueix la capacitat de memòria cau i pot augmentar la latència, així que en general no es recomana . Ara bé, reduir la memòria cau pot ser aconsellable en aplicacions que volen evitar atacs de sincronització de apps web destinats a esbrinar quins dominis ha visitat lusuari recentment. L'enfocament HTTPS també té avantatges pràctics: les APIs HTTPS estan àmpliament disponibles i són compatibles, cosa que simplifica la implementació; un servei HTTPS dóna a les apps web accés a tot tipus de registres DNS, evitant les limitacions de les API del navegador o del sistema operatiu que solen limitar-se a cerques de host a adreça; i els clients que implementen HTTPS sobre UDP amb QUIC poden evitar problemes com el bloqueig de cap de línia que passa amb TCP. Si trobes una fallada o vols demanar una funció nova, el seu fort és informar del problema relacionat amb DoH per les vies habituals.

Dubtes habituals sobre DoH i VPN

Una de les preguntes més repetides és si té sentit fer servir DoH quan ja s'utilitza una VPN. Es pot fer servir, però el més pràctic sol ser deixar que la VPN gestioni el DNS i comprovar amb una prova de fuites que les consultes surten per on deuen. Si el navegador envia les vostres pròpies consultes per una banda i la VPN per l'altra, pots emportar-te una sorpresa desagradable.

Un altre dubte freqüent és si DoH impedeix que el proveïdor d'Internet vegi quins webs visites. DoH amaga les consultes DNS davant de molts observadors, però no elimina totes les metadades ni amaga la teva IP : l'ISP encara pot veure a quines adreces IP et connectes i una altra informació de xarxa. Per a una protecció més àmplia cal una VPN o combinar diverses capes de privadesa.

També es pregunta si DoH és suficient en una Wi-Fi pública. Podeu ajudar a fer que l'operador d'aquesta xarxa no llegeixi les vostres consultes DNS amb facilitat, però no protegeix tota la connexió ni el trànsit de totes les aplicacions . A aeroports, hotels i cafeteries sol ser més complet fer servir una VPN, sobretot si no saps qui controla el router o si hi ha més gent connectada.

DoH i les VPN no són rivals absoluts, sinó eines amb diferents abasts. DoH xifra la cerca de dominis i redueix l'exposició d'aquesta part del procés; una VPN xifra el recorregut entre el teu dispositiu i un servidor i canvia la IP que veuen les destinacions . Cap de les dues et fa invisible: els comptes, les galetes, les empremtes del navegador, els permisos de les aplicacions, el codi maliciós (malware) i qualsevol dada que comparteixis directament poden seguir identificant-te. Però això no les fa inútils. Simplement vol dir que cadascuna té el seu paper. DoH protegeix la consulta d'adreces; una VPN protegeix molt més del camí que recorren les dades.