Configurar DNS seguros con DoH y DoT paso a paso

Si te preocupa cada vez más quién ve tus DNS, qué registros puede manipular y cómo blindar tus dispositivos, DoH (DNS over HTTPS) y DoT (DNS over TLS) son dos tecnologías que tienes que conocer sí o sí. No son magia ni te vuelven anónimo, pero sí elevan muchísimo el listón frente al DNS clásico en texto plano que todavía usan la mayoría de routers y sistemas.

En los últimos años se han popularizado decenas de guías, opiniones encontradas y hasta guerras de religiones entre DoH y DoT. Aquí vas a ver de forma ordenada qué protege realmente cada protocolo, qué desventajas tienen, cómo configurarlos en routers, móviles, ordenadores y servidores propios y en qué escenarios tiene sentido usar uno u otro sin caer en promesas imposibles.

Qué son DoH y DoT y por qué el DNS tradicional es un problema

El DNS clásico funciona, a grandes rasgos, como una guía telefónica de Internet que traduce nombres de dominio a direcciones IP. El problema es que se diseñó en una época en la que la prioridad era que fuese rápido y ligero, no que fuese privado o íntegro. Por eso, la mayoría de consultas siguen saliendo por UDP (y a veces TCP) en el puerto 53, sin cifrado ni protección de integridad.

Esto significa que cualquier actor en el camino entre tu dispositivo y el servidor DNS (tu proveedor, la WiFi del hotel, un atacante en una red abierta o un proxy corporativo con malas intenciones) puede ver qué dominios consultas, perfilar tu navegación o incluso inyectar respuestas falsas. Técnicas como el DNS cache poisoning o DNS spoofing consisten precisamente en aprovechar esa falta de protección para mandar registros manipulados y redirigirte a webs falsas, campañas de phishing o páginas plagadas de anuncios.

Para reforzar la seguridad se creó DNSSEC, que firma criptográficamente las zonas y permite validar que la respuesta que recibes es auténtica. Sin embargo, DNSSEC no cifra el canal: el contenido del mensaje sigue siendo legible para cualquiera que pueda espiar el tráfico. Ahí entran en juego DNS over HTTPS (DoH) y DNS over TLS (DoT), que se centran en proteger el tramo de comunicación entre el cliente y el resolutor.

Ambos estándares encapsulan las consultas DNS dentro de un túnel TLS cifrado. Con DoH, ese túnel viaja dentro de una sesión HTTPS normal, generalmente por el puerto 443. Con DoT, el túnel TLS se usa de forma dedicada para DNS, normalmente por el puerto 853. En ambos casos el objetivo es el mismo: que nadie en la ruta pueda cotillear ni alterar fácilmente las consultas y respuestas DNS.

Diferencias técnicas entre DoH y DoT

Aunque el propósito de los dos protocolos es similar, la forma en que se integran en la red y en los sistemas cambia bastante. DoT está definido en el RFC 7858 y utiliza una conexión TLS dedicada sobre TCP, escuchando de manera predeterminada en el puerto 853. El cliente y el servidor negocian una sesión TLS estándar, normalmente autenticando al servidor mediante certificados X.509 (PKIX) asociados a un nombre de dominio, según detalla el RFC 8310.

En DoT se distinguen claramente dos modos de funcionamiento: modo estricto y modo oportunista. En modo estricto, el cliente exige que la conexión TLS se establezca correctamente y que el certificado del servidor sea válido y coincida con el nombre esperado; si algo falla, la resolución se detiene y no se hace «retroceso» al DNS sin cifrar. En el modo oportunista, el cliente intenta primero usar DoT y, si no puede, cae de vuelta al puerto 53 en texto plano, priorizando la disponibilidad sobre la privacidad.

El estándar deja en manos de los proveedores de DNS aspectos como la gestión y revocación de certificados, la integración con Autoridades de Certificación de confianza o el uso de listas de revocación (CRL). Eso implica que no hay una receta única: cada servicio público (Cloudflare, Google, Quad9, CleanBrowsing, etc.) implementa estos detalles a su manera.

Por su parte, DoH está definido en el RFC 8484 y lleva las consultas DNS dentro de peticiones HTTP sobre HTTPS. En lugar de hablar con el puerto 53 de un servidor recurriendo a UDP o TCP, el cliente construye una petición HTTP GET o POST hacia una URL concreta (por ejemplo, https://dns.google/dns-query o https://cloudflare-dns.com/dns-query) y recibe la respuesta en formato DNS encapsulado. El TTL puede indicarse reutilizando la cabecera Cache-Control, de forma bastante ingeniosa.

Desde el punto de vista de la red, el tráfico DoH es simplemente tráfico HTTPS estándar por el puerto 443, indistinguible del resto si no se inspecciona profundo el contenido. Eso lo hace muy robusto frente a bloqueos selectivos, pero también convierte DoH en una pesadilla para algunos equipos de seguridad corporativa, que ven cómo su capacidad de monitorizar y filtrar DNS queda esquivada por el túnel cifrado del navegador.

Ventajas y desventajas reales de DoH y DoT

El gran punto a favor de ambos protocolos es que blindas el tramo entre tu dispositivo y el resolutor DNS. Eso reduce de manera notable la posibilidad de espionaje pasivo en la red local, dificulta ataques de manipulación de respuestas (por ejemplo, en WiFi de aeropuertos o cafeterías) y hace que técnicas como el man-in-the-middle por parte de intermediarios sean mucho más complicadas.

En el caso de DoT, las ventajas adicionales son claras: al usar un puerto dedicado y fácilmente identificable, es sencillo para un administrador permitirlo o bloquearlo a nivel de firewall, registrar estadísticas y aplicar políticas de red sin entrar a inspeccionar el contenido TLS. Además, su implementación en sistemas tipo servidor o en routers resulta bastante directa, ya que solo hay que añadir soporte TLS al servicio DNS y escuchar en el puerto 853.

Por contra, la latencia puede aumentar ligeramente respecto a un DNS sin cifrar, especialmente si se establecen muchas conexiones nuevas o si se usa el modo estricto con validación de certificados completa. Además, en ese modo estricto, si el servidor DoT no responde o el certificado no es válido, las peticiones no se vuelven a enviar por un canal inseguro: simplemente fallan, lo que puede sorprender a usuarios que esperan «que todo funcione siempre».

DoH comparte prácticamente las mismas ventajas criptográficas, pero añade un matiz importante: como va sobre HTTPS, atraviesa mejor redes muy restrictivas donde el puerto 853 se bloquea sistemáticamente. Al mismo tiempo, mezcla las resoluciones DNS con el resto del tráfico web, lo que dificulta tareas como el filtrado centralizado o el análisis de amenazas por parte de equipos de seguridad en empresas.

Una desventaja común a ambos es que no eliminan el problema de confianza, solo lo desplazan. Dejas de confiar en el DNS de tu proveedor o en el router del operador para confiar en el resolutor DoH/DoT que elijas. Ese servidor sigue viendo todos los dominios que consultas, la hora, la frecuencia y puede relacionarlos con tu IP. Por eso es crucial revisar la política de privacidad del proveedor (Google, Cloudflare, Quad9, CleanBrowsing, RocksDNS, etc.) y no dar por hecho que «cifrado» significa «privacidad absoluta».

DoH, DoT y DNSSEC: cómo encajan juntos

Es bastante habitual confundir lo que hace cada tecnología. DNSSEC, DoH y DoT no son rivales, sino capas complementarias. DNSSEC se ocupa de garantizar que los datos DNS no han sido manipulados desde la zona de origen hasta el resolutor, usando firmas digitales. Sin embargo, no protege el canal: cualquiera puede seguir viendo el contenido de las consultas y respuestas.

DoH y DoT se enfocan en otra cosa: cifrar y autenticar el transporte entre el cliente y el resolutor. No comprueban por sí mismos si un registro es el que publicó el propietario del dominio; lo que hacen es evitar que alguien «por el camino» pueda leer o alterar las respuestas de forma transparente. El escenario ideal es usar un resolutor que valide DNSSEC y, además, se conecte con tus dispositivos mediante DoH o DoT.

Si montas tu propio servidor con software como Unbound, la situación es aún mejor. Unbound incluye DNSSEC activado por defecto en instalaciones recientes, y puede configurarse para hablar con los clientes mediante DoT. De esa forma, eliminando intermediarios, tu Raspberry Pi o servidor local resuelve directamente frente a los servidores raíz y TLD firmados con DNSSEC, y ofrece a la red de tu casa o de tu empresa un servicio DNS cifrado y validado.

Para comprobar que DNSSEC está funcionando correctamente, existen sitios específicos de prueba, como los dominios que muestran una «llave verde» o que solo responden correctamente cuando la validación está activa. Si algo falla por culpa de certificados del sistema, en distribuciones Linux suele bastar con instalar o actualizar paquetes como ca-certificates junto con el propio Unbound.

Configurar DoH y DoT en routers y redes domésticas

Un punto clave para aprovechar estas tecnologías es mover la configuración al propio router, de modo que todos los dispositivos de la red se beneficien sin tocar nada en cada equipo. Aquí el soporte varía mucho según el modelo. Por ejemplo, en gamas modernas como algunos routers TP-Link serie AX (AX55 y similares), ya se puede activar tanto DoH como DoT desde la interfaz web.

En este tipo de routers, tras iniciar sesión en la interfaz de administración, suele aparecer un apartado de configuración en la ruta Avanzado → Red → Internet. Allí se puede elegir el nivel de «Privacidad de DNS». Si se deja en «Ninguno», las consultas seguirán saliendo sin cifrar. Si se selecciona DoT o DoH, el firmware muestra además el «Modo DNS», que normalmente ofrece un «Modo predeterminado» y un «Modo ultra seguro» o equivalente.

El modo predeterminado prioriza la continuidad del servicio: si los servidores DoH/DoT dejan de estar disponibles, el router vuelve automáticamente a DNS sin cifrar para que sigas teniendo conexión. El modo ultra seguro, en cambio, corta la resolución DNS cuando los servidores cifrados fallan, forzando a que no haya nunca «retrocesos» inseguros, pero asumiendo que puedes quedarte sin Internet si el proveedor DNS tiene un problema.

Justo debajo se suele encontrar la sección de servidores DoH/DoT disponibles, donde se pueden seleccionar varias direcciones o URLs a la vez (hasta tres en muchos modelos). Ahí aparecen opciones públicas comunes como Cloudflare, Google, Quad9 o servicios más específicos. Tras elegir tus preferidos, conviene usar la función de «detectar servidor DNS» para que el router compruebe la conectividad antes de guardar los cambios.

En routers que solo soportan DoH (caso de muchas gamas AC), la configuración es similar pero más simple: se activa el conmutador de DoH, se escoge el servidor de una lista y se comprueba el estado, que debe aparecer como conectado una vez establecido el túnel con éxito.

DNS privados en Android, iOS y otros sistemas

En el terreno móvil, Android fue uno de los primeros en integrar DoT de forma nativa. A partir de Android 9 (Pie) existe el modo «DNS privado», accesible desde Ajustes → Redes e Internet → Avanzado → DNS privado. Al seleccionar el modo de «nombre de host del proveedor DNS privado», puedes introducir dominios como dns.google o 1dot1dot1dot1.cloudflare-dns.com. El sistema enviará entonces las consultas mediante DoT a esos servidores, sin necesidad de apps adicionales ni VPN.

En versiones anteriores de Android no hay soporte nativo para DNS sobre TLS, por lo que la única forma práctica de usar DoH o DoT es a través de aplicaciones que actúan como VPN local y redirigen las consultas a un resolutor cifrado (ejemplo típico: la app de Cloudflare). El problema es que Android no permite usar dos perfiles VPN simultáneamente, así que si ya dependes de otra VPN para saltar restricciones geográficas o de censura, no podrás combinar ambos enfoques a la vez.

En iOS (14 en adelante) Apple apostó por los perfiles de configuración. Para habilitar DoH o DoT no basta con cambiar un parámetro suelto, sino que hay que instalar un perfil que defina el proveedor DNS cifrado. Existen herramientas web que generan estos perfiles de forma sencilla: indicas el nombre del proveedor, eliges si quieres «DNS over HTTPS» o «DNS over TLS» e introduces la URL o el host correspondientes. Luego descargas el perfil en el propio iPhone o iPad (mejor con Safari), vas a Ajustes → General → VPN y administración de dispositivos y procedes a instalarlo.

En Windows, la situación depende de la versión. Windows 11 ya permite registrar servidores con DoH de forma nativa y asociarlos a las tarjetas de red. Mediante la herramienta de línea de comandos se puede añadir la IP del resolutor junto con la plantilla HTTPS (por ejemplo, la de un proveedor como RocksDNS o Cloudflare) y luego configurar esas IP como DNS preferido y alternativo del adaptador. Windows intentará entonces usar DoH con esos servidores y volverá a DNS tradicional si no es posible.

En Windows 10 el soporte nativo está más limitado y, salvo en builds muy concretas, lo más práctico suele ser recurrir a aplicaciones como YogaDNS o AdGuard que intermedian todas las consultas del sistema hacia resolutores DoH, DoT o incluso DoQ. Estas herramientas permiten definir múltiples proveedores, elegir prioridades y evitar que otros programas o el propio navegador cambien la resolución a sus espaldas.

Montar tu propio DNS con DoT, DoH y Pi-hole

Si quieres ir un paso más allá y no depender de grandes empresas, una opción muy potente es desplegar tu propio servidor DNS recursivo con herramientas como Unbound, normalmente sobre una Raspberry Pi o un VPS, y combinarlo con Pi-hole para filtrar anuncios, rastreadores y dominios maliciosos.

La idea básica es que Pi-hole actúe como servidor DNS de la red local (y servidor DHCP si el router del ISP es muy limitado) y delegue las consultas externas hacia Unbound, que se encargará de resolver recursivamente y validar DNSSEC. De esta forma, los únicos equipos autorizados a hablar con Internet por los puertos DNS serán tu Pi-hole o tu servidor designado, reduciendo al mínimo las fugas de información hacia resolutores externos.

Uno de los problemas más comunes al desplegar Pi-hole es que muchos routers de operadores no permiten configurar un DNS de la LAN apuntando a una IP local. Para sortear esta limitación puedes seguir una estrategia en cuatro pasos: fijar IP estática a la máquina con Pi-hole desde el propio router, desactivar el servicio DHCP del router, activar el servidor DHCP en la interfaz web de Pi-hole (usando como puerta de enlace la IP del router) y, por último, reiniciar los dispositivos para que obtengan las nuevas concesiones.

Si tienes usuarios avanzados o «creativos» en casa, puede que alguno configure manualmente DNS externos (Google, Cloudflare, etc.) en sus dispositivos. Para evitarlo, muchos administradores aplican reglas en el firmware del router (por ejemplo, con DD-WRT) para bloquear por completo las conexiones salientes al puerto 53, 853 y similares, excepto desde la IP del propio Pi-hole. Así, aunque alguien cambie su DNS local, todas las peticiones acabarán pasando por tu servidor.

En el caso de un VPS, y si quieres exponer un servicio DoT propio en el puerto 853 para conectarte desde Android, puedes endurecer bastante la seguridad usando certificados TLS (mejor si son válidos y no solo autofirmados), limitar lo posible los rangos permitidos en el firewall y apoyarte en herramientas como Fail2ban para bloquear rápidamente IP que generen errores constantes de handshake TLS. No es un blindaje perfecto, pero reduce la superficie de ataque de forma considerable para un uso personal.

DoH y DoT en navegadores: Firefox, Chrome y otros

Los navegadores han abrazado sobre todo DoH, porque les permite controlar ellos mismos la resolución DNS sin depender de la configuración del sistema operativo. Mozilla Firefox fue pionero en esto: desde sus opciones de red se puede activar el uso de DoH y elegir proveedores como Cloudflare, NextDNS o uno personalizado. Al hacerlo, el navegador ignora el DNS configurado en el sistema y resuelve directamente vía HTTPS contra el servidor elegido.

Para usuarios avanzados, Firefox ofrece el ajuste network.trr.mode, donde se define el comportamiento de la «Trusted Recursive Resolver» (TRR). El valor 0 desactiva DoH; 1 deja que Firefox elija lo más rápido; 2 usa DoH pero recurre al DNS clásico si falla; 3 fuerza que todas las consultas pasen por DoH sin retroceso; y 5 desactiva cualquier intento de usar DoH. La dirección del resolutor DoH se especifica en network.trr.uri, donde se pueden poner URLs como las ya comentadas.

Google Chrome y navegadores basados en Chromium incluyen una opción similar llamada Secure DNS. En versiones recientes se activa desde la configuración de privacidad, eligiendo usar DNS seguro con el proveedor actual o especificando uno nuevo. Internamente, Chrome puede recurrir también a banderas experimentales donde se habilita o deshabilita la resolución DoH, pero en la práctica, para usuarios finales basta con el menú gráfico.

Un aspecto importante es que esta resolución integrada en el navegador puede chocar con políticas corporativas o controles parentales basados en DNS. Si en una empresa se filtran dominios maliciosos desde un resolutor interno y un navegador decide saltarse esa infraestructura usando DoH hacia un servidor externo, parte de la estrategia de seguridad deja de tener efecto. Por eso muchos administradores bloquean DoH a nivel de firewall o lo gestionan mediante plantillas y directivas en navegadores corporativos.

Además, en el ecosistema TLS sigue habiendo una pieza que filtra información: la SNI (Server Name Indication), que expone el nombre del host durante el handshake TLS inicial. Aunque DNS esté cifrado, un observador en la red aún puede ver a qué host te conectas mirando la SNI. Se está trabajando en mecanismos de SNI cifrado para cerrar ese hueco, pero su adopción todavía es desigual y requiere soporte tanto del cliente como del servidor.

En definitiva, DoH y DoT no son una bala de plata, pero sí son una mejora clara en la higiene de seguridad y privacidad del DNS. Elegir bien el proveedor, combinarlo con DNSSEC y, cuando sea posible, con servidores propios o resolutores de confianza, permite reducir mucho la exposición del historial de navegación a intermediarios indeseados, manteniendo el equilibrio razonable entre control, rendimiento y operatividad en todo tipo de redes.