DNS over HTTPS: qué es y cómo protege tus consultas

Guía Alfa » Informática » DNS over HTTPS: qué es y cómo protege tus consultas

Cuando tecleas una dirección web, hay una pieza que trabaja en segundo plano para que llegues al sitio correcto: el sistema de nombres de dominio. El DNS traduce nombres fáciles de recordar a direcciones IP que entienden los ordenadores. Es cómodo, sí, pero durante años ha funcionado con una vulnerabilidad importante: esas consultas viajaban sin cifrar. De ahí que haya cobrado protagonismo el DNS over HTTPS, también llamado DoH, una capa extra de protección para que tu proveedor de Internet no tenga tan fácil saber qué dominios visitas.

Conviene dejar una idea clara desde el principio: DoH mejora la privacidad de las consultas DNS, pero no es una VPN ni convierte toda tu conexión en un túnel secreto. A lo largo de este artículo veremos qué es exactamente, por qué se ha vuelto popular, cómo se activa en Chrome, Edge y Firefox, qué ventajas e inconvenientes tiene, en qué se diferencia de DNS over TLS y de una VPN, y hasta qué punto llegan sus límites técnicos y prácticos.

Qué es DNS y por qué el sistema tradicional se queda corto

Los servidores DNS son una de esas piezas que casi nadie mira pero que sostienen buena parte de la navegación. Su trabajo consiste en poner en relación un nombre de dominio con la dirección IP del servidor correspondiente. Cuando entras en una web, tu equipo no entiende de letras: necesita una IP para saber a qué máquina conectarse. Muchos routers vienen con servidores DNS ya configurados por la operadora, y eso hace que el proceso sea cómodo, aunque también deja un rastro visible para quien controle esa infraestructura.

El problema de fondo es que las consultas DNS clásicas se hacen en texto plano y sin protección. Eso abre la puerta a escuchas, a ataques de intermediario y a manipulaciones de la respuesta. Un proveedor de Internet puede llegar a saber qué dominios consultas y cuándo lo haces; un atacante en una red compartida puede intentar interceptar la petición y devolver una respuesta fraudulenta. Esa técnica se conoce como DNS hijacking y puede acabar llevándote a una página falsa, a publicidad no deseada o a un sitio pensado para robar datos. Gobiernos y operadoras también han aprovechado históricamente estas debilidades para aplicar censura, bloquear dominios o mostrar publicidad adicional.

• Escuchas pasivas: alguien observa las consultas y deduce qué servicios o webs frecuentas.
• Man-in-the-middle: se intercepta la comunicación y se modifica la respuesta para suplantar un servidor.
• Bloqueos y filtrados: se impide resolver determinados dominios para controlar el acceso a contenidos.

DNS over HTTPS: cifrar la consulta para que no vaya a la vista de todos

DNS over HTTPS, o DoH, es una solución que aprovecha el protocolo HTTPS para transportar las consultas y las respuestas DNS de forma cifrada. En lugar de enviar una petición DNS en claro, el dispositivo la encapsula en una conexión segura, normalmente usando el puerto 443, el mismo que emplean las páginas web seguras. Así, tanto la pregunta como la respuesta quedan protegidas y un observador externo no puede leerlas con facilidad.

Para que esto funcione, el servidor DNS al que se consulta también tiene que soportar DoH. No basta con activar una opción en el navegador: el resolvedor elegido debe hablar ese estándar. La especificación ha ido evolucionando y todavía se considera una tecnología en desarrollo, aunque desde 2018 empresas como Google y la Fundación Mozilla han hecho pruebas y lo han ido integrando. Además de la mejora de privacidad, las pruebas apuntan a que DoH puede reducir la latencia y hacer que las consultas sean más ligeras, porque no siempre hace falta resolver el dominio completo sino solo la parte mínima necesaria.

Ventajas de DoH: más privacidad, menos manipulación y mejor rendimiento

La ventaja más evidente es la seguridad. Al viajar cifradas, las consultas DNS resultan mucho más difíciles de espiar o de modificar. Eso complica ataques de intermediario, reduce la exposición en redes Wi-Fi públicas y evita que un operador local pueda ver con claridad qué dominios estás solicitando. Como el tráfico DoH utiliza el puerto 443, se mezcla con el resto de conexiones HTTPS y cuesta distinguirlo de una visita web normal.

También hay motivos de rendimiento. DoH puede disminuir la latencia y aligerar las comunicaciones DNS gracias a cambios en la forma de resolver nombres y a un mejor aprovechamiento de la caché. Por ejemplo, el método GET de algunas APIs está pensado para almacenarse en caché con más eficacia. En la práctica, esto puede traducirse en una navegación algo más rápida, aunque no es una mejora mágica ni se nota siempre. Además, al implementarse en el navegador, el usuario no tiene que esperar a que su operadora decida activarlo.

Inconvenientes y debates: cuando el cifrado complica la vida

No todo el mundo ve DoH con buenos ojos. El mismo cifrado que protege al usuario también dificulta la supervisión de la red. Muchos programas de control parental se basan en inspeccionar las consultas DNS para saber qué páginas intentan abrir los menores; con DoH, esa tarea se vuelve mucho más complicada e incluso puede resultar inviable. Algo parecido ocurre con los administradores de redes corporativas, que pierden visibilidad sobre los dominios consultados y no pueden aplicar ciertas reglas con la misma facilidad.

Los proveedores de Internet también pierden capacidad para monitorizar accesos y para bloquear determinados dominios por orden de una institución. Eso genera un debate legítimo: hay quien lo ve como una victoria de la privacidad y quien lo considera un problema de control y gestión. En el caso de DoT, además, se critica que use un puerto propio y reconocible, lo que permite identificar que hay consultas DNS aunque no se sepa exactamente qué se pregunta. DoH evita esa señal tan clara al camuflarse entre el tráfico HTTPS, pero a cambio los administradores de red se quedan con menos herramientas para gestionar sus comunicaciones.

Cómo activar DoH en Chrome, Edge y Firefox

Activar DoH en un navegador moderno suele ser sencillo, sobre todo si está basado en Chromium o si se trata de Firefox. La opción existe, aunque en algunos casos está escondida en menús de configuración avanzada. Antes de tocar nada, conviene tener claro que el navegador solo protege sus propias consultas: otras aplicaciones del dispositivo pueden seguir usando otro sistema DNS si no se configura también a nivel del sistema.

Google Chrome

En Chrome, el camino rápido es escribir chrome://flags/#dns-over-https en la barra de direcciones. Eso te lleva directamente a los Flags o funciones experimentales de Chrome. Verás seleccionada una opción llamada Secure DNS lookups; pulsa en el desplegable que pone Default y elige Enabled. Después tendrás que reiniciar el navegador para que el cambio surta efecto.

Microsoft Edge

En Edge basado en Chromium el proceso es prácticamente idéntico. Abre el navegador y escribe edge://flags/#dns-over-https en la barra de búsqueda. Entrarás en los Flags de Edge y aparecerá la misma opción Secure DNS lookups. Cambia Default por Enabled y reinicia el navegador cuando te lo pida.

Mozilla Firefox

En Firefox no hace falta ir a los Flags. Pulsa el botón de menú situado arriba a la derecha y entra en Opciones. Dentro de la sección General, baja hasta el final y pulsa en Configuración de red. En la ventana que se abre, marca la casilla Activar DNS sobre HTTPS. Podrás elegir entre proveedores como Cloudflare y NextDNS para realizar el cifrado mediante HTTPS.

DNS over TLS (DoT): el otro camino cifrado

DNS over TLS, o DoT, es otra forma de proteger las consultas DNS. En lugar de usar HTTPS, emplea TLS sobre una conexión TCP y un puerto estandarizado, el 853. TLS es la misma base de seguridad que hay detrás de HTTPS, así que la idea es parecida: crear un túnel cifrado en el que solo los dos participantes puedan descifrar y procesar la información. De este modo se dificulta un ataque de intermediario y se evita que un tercero lea o manipule la consulta.

DoT tiene sus ventajas, sobre todo frente al DNS clásico, que no ofrece ninguna medida de seguridad. El cifrado impide que los ciberdelincuentes intercepten las peticiones y también pone trabas a ciertas medidas de censura. Ahora bien, requiere compatibilidad por parte del cliente y del servidor. Hay varios proveedores que ofrecen servidores compatibles, pero para usarlo en un ordenador de sobremesa o portátil suele hacer falta instalar software adicional; en Android moderno, al menos desde Android 9, ya viene integrado. En Windows y Linux existen soluciones, aunque no siempre son tan transparentes como uno querría.

Entre los inconvenientes, muchos expertos en protección de datos critican que DoT utilice un puerto único y reconocible. Aunque no se pueda saber qué página se consulta, sí se puede detectar que hay tráfico DNS. Para algunos administradores de red eso es útil, porque les permite mantener una visión general de lo que ocurre; para otros, es una señal que preferirían ocultar. Además, DoT todavía no está tan extendido como el DNS tradicional y su adopción del lado del servidor es limitada. Hay preocupación por que unas pocas empresas concentren cada vez más las consultas DNS, lo que podría crear una especie de monopolio internacional.

DoH frente a DoT: dos formas de proteger lo mismo

La diferencia principal entre DoH y DoT está en el puerto y en cómo se camufla el tráfico. DoT usa su propio puerto, el 853, mientras que DoH recurre al 443 y se mezcla con las conexiones HTTPS normales. Esa diferencia, que parece menor, ha generado un debate profundo. Desde el punto de vista de la privacidad, que una consulta DNS no se pueda distinguir del resto del tráfico es una ventaja: si no se reconoce, tampoco se puede manipular con tanta facilidad. Desde el punto de vista de la gestión de redes, en cambio, se pierde control y resulta más difícil aplicar políticas de seguridad o de filtrado.

En el fondo hay dos visiones. El IETF, el consorcio que desarrolla muchos estándares de Internet, está detrás de DoT, mientras que Google y la Fundación Mozilla han impulsado con fuerza DoH. No son tecnologías enemigas, pero sí representan formas distintas de entender la privacidad, la visibilidad de la red y el papel de los intermediarios. La elección entre una y otra depende de qué se quiera proteger y de quién necesite gestionar la red.

DoH frente a una VPN: protege la pregunta, no todo el viaje

DoH y una VPN suelen aparecer en las mismas conversaciones sobre privacidad, pero no hacen lo mismo. DoH protege la consulta de nombres; una VPN protege la ruta que recorren tus datos. La forma más sencilla de entenderlo es pensar que DoH mete una pregunta sensible en un sobre sellado, mientras que una VPN hace que todo el viaje transcurra por un túnel privado antes de volver a la carretera pública. Ambos pueden mejorar la privacidad, pero solo uno está diseñado para cubrir el tráfico de teléfonos, tabletas y ordenadores de forma amplia.

Qué hace el DNS antes de que se cargue un sitio

Antes de que el navegador pueda cargar una web, el dispositivo necesita saber dónde está. El DNS funciona como una guía telefónica que convierte un nombre de sitio en una dirección IP. Eso ocurre constantemente: al abrir una página, lanzar una aplicación, actualizar el correo o reproducir un vídeo. La mayoría de las veces sucede en silencio y no lo notas, lo cual está bien para la comodidad, pero también hace que sea fácil pasarlo por alto como problema de privacidad. Las consultas DNS tradicionales no están cifradas, así que tu proveedor, tu empresa, tu centro educativo, la Wi-Fi de una cafetería o la red de un hotel podrían ver qué dominios intenta alcanzar tu dispositivo. No ven el contenido completo de una página HTTPS, pero sí un esquema bastante revelador de tu actividad.

Una consulta DNS no muestra cada página que has visto ni lo que escribes en un formulario, pero una lista de dominios puede exponer hábitos, intereses, herramientas de trabajo, investigaciones de salud o servicios financieros. Por eso el DNS cifrado se ha convertido en una función de privacidad útil. No lo enseña todo, pero revela más de lo que mucha gente imagina.

Qué oculta DoH y qué deja al descubierto

DoH envía las consultas DNS a través de HTTPS, el mismo protocolo cifrado que usan las webs seguras. La petición sale del dispositivo envuelta en cifrado y llega a un resolvedor que soporta el estándar. En una Wi-Fi pública, eso puede dificultar que el operador de la red lea a la ligera tus consultas. Si tu proveedor de Internet gestiona el DNS, cambiar a un resolvedor DoH puede evitar que vea esas búsquedas de la forma habitual. Además, si una red manipula los resultados de resolución de nombres, el DNS cifrado puede reducir algunas formas de manipulación.

Ahora bien, DoH oculta la pregunta, no toda la conversación. Puede impedir que algunos observadores vean con claridad la búsqueda de dominios, pero no convierte toda tu conexión a Internet en un túnel cifrado. Una vez que el dispositivo conoce la dirección IP, el resto de la conexión sigue su camino normal, salvo que otra herramienta de privacidad cambie esa ruta. DoH no oculta tu dirección IP real a los sitios web, aplicaciones o servicios a los que te conectas, ni te hace parecer que estás en otra ciudad o país. Si inicias sesión en una cuenta, el servicio sabe que eres tú. Si el navegador tiene cookies, sesiones guardadas, identificadores publicitarios o una huella reconocible, DoH no borra esas señales.

Tampoco protege cada aplicación a menos que esté configurado a nivel del sistema y la aplicación respete esa configuración. Un navegador puede usar DNS seguro mientras otra aplicación del mismo dispositivo utiliza una ruta DNS distinta. Algunas apps gestionan su propia red y no siempre se alinean con lo que hay configurado en el sistema o en el navegador. Por eso DoH puede crear una falsa sensación de protección completa: mejora la privacidad de las consultas DNS, pero no protege transferencias de archivos, tráfico de mensajería, videollamadas, conexiones de juegos, sincronización en segundo plano o aplicaciones de streaming como lo haría una VPN.

Qué protege una VPN y qué tampoco puede ocultar

Una VPN protege una parte distinta del viaje. Crea un túnel cifrado entre tu dispositivo y un servidor VPN, y hace que el tráfico salga a Internet desde ese servidor. Tu proveedor o la Wi-Fi local ven una conexión cifrada al servidor VPN, no una visión clara de cada sitio y servicio con el que contactas. Además, la VPN cambia la dirección IP pública que ven las webs y aplicaciones: en lugar de la IP de tu casa o de tu operador móvil, el destino ve la IP del servidor VPN. Eso puede reducir el seguimiento basado en la ubicación, ayudar a evitar algunos perfiles de ISP y hacer más seguro el uso de Wi-Fi público.

Una VPN completa puede proteger navegadores, aplicaciones de streaming, clientes de correo, herramientas de copia de seguridad en la nube, mensajería, juegos y servicios en segundo plano. También puede enrutar las solicitudes DNS a través del túnel cifrado cuando está bien configurada, y por eso conviene hacer una prueba de fuga de DNS. Dicho esto, una VPN no es magia. Si inicias sesión en una red social, un correo, un servicio de streaming o una tienda online, ese servicio sigue sabiendo quién eres. Puede ocultar tu IP original, pero no hace anónimo tu inicio de sesión. Lo mismo vale para cualquier cosa que envíes directamente: tu nombre, correo, datos de pago, dirección de envío, fotos o mensajes.

Las cookies y la huella del navegador siguen importando. Las aplicaciones pueden crear problemas parecidos mediante identificadores de publicidad, permisos, acceso a la ubicación, escaneo de Bluetooth, nombres de Wi-Fi cercanos y kits de análisis. El malware es otro límite difícil, porque puede capturar datos antes de que lleguen al túnel VPN. En resumidas cuentas, una VPN oculta y cifra mucha actividad, pero no disfraza cada huella digital.

Se pueden usar DoH y una VPN a la vez

Sí, se pueden combinar, pero la configuración ideal depende de cómo gestionen el DNS el dispositivo, el navegador y la aplicación VPN. En muchos casos lo más sencillo es dejar que la VPN se encargue del DNS. Una buena aplicación debería enviar las consultas DNS por el túnel cifrado para que tu proveedor no las reciba directamente. Así obtienes privacidad DNS como parte de la conexión VPN sin tener que ajustar el navegador por separado.

El problema aparece cuando el navegador usa su propia configuración de DoH mientras la VPN intenta gestionar el DNS a nivel del sistema. Puede que no se rompa nada, pero sí se crea confusión: podrías pensar que todas las consultas pasan por la VPN y, en realidad, el navegador está enviando algunas por su cuenta a un resolvedor distinto. Ahí es donde una prueba de fuga de DNS resulta útil. Si después de conectarte a la VPN aparecen los servidores DNS de tu operador, algo no está funcionando como esperabas; si aparecen servidores asociados a la VPN, es más probable que la configuración vaya bien.

Cuándo basta con DoH y cuándo conviene una VPN

DoH puede ser suficiente cuando tu principal preocupación es la privacidad básica de las consultas DNS en el navegador. En una red doméstica de confianza, activar DNS seguro reduce la exposición en texto plano sin necesidad de cambiar de ubicación ni proteger todas las aplicaciones. También es útil en redes donde preocupa el filtrado o la manipulación de DNS, porque al viajar por HTTPS resulta más difícil de inspeccionar o modificar de forma simple. Eso no significa que esquive cualquier restricción ni que sea una herramienta a prueba de censura, pero sí es una mejora notable frente al DNS sin cifrar. Además, es ligero: no hay que elegir un servidor VPN ni cambiar gran cosa del enrutamiento, y normalmente no se nota un impacto apreciable en la velocidad.

Una VPN tiene más sentido cuando quieres protección en todo el dispositivo y no solo en las búsquedas DNS. Eso incluye aeropuertos, hoteles, escuelas, espacios de coworking, cafeterías y alojamientos de alquiler. En redes compartidas no sabes quién controla el router, quién más está conectado ni si alguien intenta interceptar el tráfico. La VPN también ayuda cuando no quieres que tu ISP construya un perfil a partir de tus patrones de navegación: aunque HTTPS proteja el contenido de las páginas, los metadatos de red todavía pueden revelar patrones útiles. Viajar es otro caso claro: una VPN puede hacer que la conexión sea más consistente, protegerte en redes desconocidas y hacer que los sitios vean la ubicación del servidor VPN en lugar de tu conexión local temporal.

Detalles técnicos de las API DoH de Google Public DNS

Google Public DNS ofrece dos APIs DoH distintas. Una está pensada para RFC 8484 y acepta GET y POST en la URL https://dns.google/dns-query; la otra es una API JSON que solo admite GET en https://dns.google/resolve. También existe una interfaz web en https://dns.google/ que muestra resultados JSON en el navegador, pero no implementa una API como tal. No conviene confundir esa interfaz con las URLs de la API ni con https://dns.google/query. El servicio no admite URLs http sin seguridad, y DoH también es compatible con el servicio DNS64 público de Google, aunque en ese caso solo IPv6. La documentación de transporte seguro de Google incluye ejemplos con curl y detalles de TLS, DoT y DoH.

Métodos HTTP disponibles

El método GET puede reducir la latencia porque se almacena en caché con más eficacia. Las solicitudes GET de RFC 8484 deben incluir un parámetro ?dns= con un mensaje DNS codificado en Base64Url, y es el único método que admite la API JSON. El método POST solo está disponible en la API RFC 8484 y utiliza un mensaje DNS binario con application/dns-message en el cuerpo de la solicitud y de la respuesta. El método HEAD ahora mismo no está soportado y devuelve un error 400 Bad Request. Otros métodos muestran errores 501 Not Implemented.

Códigos de estado y errores

La API devuelve varios códigos HTTP que conviene conocer. Un 200 OK indica que el análisis HTTP y la comunicación con el agente de resolución DNS se completaron correctamente; el cuerpo puede ser una respuesta DNS binaria o JSON según el extremo, la cabecera Accept y los parámetros GET. Ojo: un error HTTP puede ser también un fallo de DNS, así que conviene revisar el código de respuesta DNS, por ejemplo el campo «Estado» del JSON, para ver errores como SERVFAIL, FORMERR, REFUSED o NOTIMP.

• 301 Moved Permanently: el cliente debe reintentar en la URL indicada en Location. Si la petición original era POST, solo debe reintentar con GET si la nueva URL especifica un parámetro dns; en caso contrario, debe repetir con POST. También pueden aparecer 302, 307 y 308, y los clientes DoH deben manejar los cuatro. Los 301 y 308 permanentes se pueden cachear de forma indefinida. Las solicitudes POST que reciben 307 o 308 deben reintentarse siempre con POST.
• 400 Bad Request: problemas al analizar los parámetros GET o un mensaje de solicitud DNS no válido. La mayoría de mensajes DNS inválidos reciben un 200 OK con FORMERR, pero hay errores HTTP para mensajes ilegibles sin sección Question, con una marca QR que indica respuesta o con combinaciones de marcas sin sentido.
• 413 Payload Too Large: el cuerpo de una solicitud POST RFC 8484 supera el tamaño máximo de mensaje de 512 bytes.
• 414 URI Too Long: la cabecera de la consulta GET era demasiado grande o el parámetro dns superaba los 512 bytes.
• 415 Unsupported Media Type: el cuerpo de la POST no tenía la cabecera de tipo de contenido application/dns-message.
• 429 Too Many Requests: se han enviado demasiadas solicitudes en un periodo. El cliente debe esperar hasta el momento indicado en la cabecera Retry-After.
• 500 Internal Server Error: errores internos del servicio DoH.
• 501 Not Implemented: solo se implementan GET y POST; el resto devuelve este error.
• 502 Bad Gateway: el servicio DoH no pudo comunicarse con los agentes de resolución de Google Public DNS. Reintentar en otra dirección alternativa puede servir, pero un plan de respaldo más eficaz es probar otro servicio DoH o cambiar al DNS tradicional por UDP o TCP en 8.8.8.8.

Buenas prácticas de privacidad y rendimiento

Los desarrolladores de aplicaciones DoH deberían limitar las cabeceras HTTP. Cabeceras como Cookie, User-Agent o Accept-Language pueden revelar información sobre la implementación del cliente y ayudar a desanonimizarlo. Lo recomendable es enviar solo las cabeceras necesarias para DoH: Host, Content-Type en el caso de POST y, si hace falta, Accept. El User-Agent debería incluirse en versiones de desarrollo o prueba. También conviene usar opciones de relleno EDNS para rellenar las consultas hasta longitudes comunes y dificultar el análisis de tráfico. El relleno HTTP/2 es posible, pero a diferencia del de EDNS no genera relleno en las respuestas del servidor DoH.

El método POST de RFC 8484 solo debería usarse en aplicaciones o modos de navegador sensibles a la privacidad. Usar POST reduce la capacidad de caché y puede aumentar la latencia, así que en general no se recomienda. Ahora bien, reducir la caché puede ser aconsejable en aplicaciones que quieren evitar ataques de sincronización de apps web destinados a averiguar qué dominios ha visitado el usuario recientemente. El enfoque HTTPS también tiene ventajas prácticas: las APIs HTTPS están ampliamente disponibles y son compatibles, lo que simplifica la implementación; un servicio HTTPS da a las apps web acceso a todo tipo de registros DNS, evitando las limitaciones de las APIs del navegador o del sistema operativo que suelen limitarse a búsquedas de host a dirección; y los clientes que implementan HTTPS sobre UDP con QUIC pueden evitar problemas como el bloqueo de cabeza de línea que ocurre con TCP. Si encuentras un fallo o quieres pedir una función nueva, lo suyo es informar del problema relacionado con DoH por los cauces habituales.

Dudas habituales sobre DoH y VPN

Una de las preguntas más repetidas es si tiene sentido usar DoH cuando ya se utiliza una VPN. Se puede usar, pero lo más práctico suele ser dejar que la VPN gestione el DNS y comprobar con una prueba de fugas que las consultas salen por donde deben. Si el navegador envía sus propias consultas por un lado y la VPN por otro, puedes llevarte una sorpresa desagradable.

Otra duda frecuente es si DoH impide que el proveedor de Internet vea qué webs visitas. DoH oculta las consultas DNS frente a muchos observadores, pero no elimina todos los metadatos ni oculta tu IP: el ISP todavía puede ver a qué direcciones IP te conectas y otra información de red. Para una protección más amplia hace falta una VPN o combinar varias capas de privacidad.

También se pregunta si DoH basta en una Wi-Fi pública. Puede ayudar a que el operador de esa red no lea tus consultas DNS con facilidad, pero no protege toda la conexión ni el tráfico de todas las aplicaciones. En aeropuertos, hoteles y cafeterías suele ser más completo usar una VPN, sobre todo si no sabes quién controla el router o si hay más gente conectada.

DoH y las VPN no son rivales absolutos, sino herramientas con alcances distintos. DoH cifra la búsqueda de dominios y reduce la exposición de esa parte del proceso; una VPN cifra el recorrido entre tu dispositivo y un servidor y cambia la IP que ven los destinos. Ninguna de las dos te hace invisible: las cuentas, las cookies, las huellas del navegador, los permisos de las aplicaciones, el malware y cualquier dato que compartas directamente pueden seguir identificándote. Pero eso no las hace inútiles. Simplemente significa que cada una tiene su papel. DoH protege la consulta de direcciones; una VPN protege mucho más del camino que recorren tus datos.