DNS over HTTPS (DoH) vs DNS over TLS (DoT): diferencias, cuándo usar cada uno y cómo configurarlos

Autor: Jeffry Chaves, Ing. en Sistemas – Diccionario Informático

Qué problema resuelven: por qué cifrar el DNS hoy

Si el DNS clásico fuese una postal, cualquiera en la ruta podría leerla. Cada vez que escribes un dominio, tu dispositivo consulta a un resolutor y, si esa consulta viaja en texto claro, deja un rastro: qué sitios visitas, cuándo y con qué frecuencia. DoH y DoT nacen para cifrar esa postal, de modo que operadoras, middleboxes o puntos Wi-Fi curiosos no puedan inspeccionarla con facilidad.
A nivel práctico, esto no “anonimiza” tu navegación (sigues exponiendo IPs de destino y metadatos de conexión), pero reduce muchísimo la visibilidad trivial que tienen actores intermedios sobre tus consultas DNS. Además, evita manipulaciones básicas como el DNS hijacking o la inyección de respuestas por terceros maliciosos.

Experiencia comunitaria #1 (privacidad realista): en discusiones de administradores de red, el consenso es que DoH/DoT eleva el listón frente a ISPs o hotspots agresivos, pero no sustituye a medidas como HTTPS en los sitios, E2E en apps y una política clara de logging del resolutor que elijas. La recomendación frecuente es “elige un resolutor con política de datos transparente y soporte para ambas opciones”.

DNS plano vs DNS cifrado: amenazas y privacidad

Amenazas comunes: spoofing de respuestas, cache poisoning, redirecciones de ISP, tracking DNS.
Qué mitigan DoH/DoT: espionaje básico de consultas en tránsito y manipulación en salto intermedio.
Qué no cubren: malware en el endpoint, fuga por otros canales (DoH de navegador que se salta tu Pi-hole, por ejemplo), o huellas de tráfico a nivel IP/SNI (aunque ECH/ESNI y QUIC ayudan en otros frentes).

DoH y DoT en contexto de DNSSEC: se complementan, no se sustituyen

DNSSEC asegura la integridad/autenticidad de la respuesta (que venga firmada por la autoridad correcta), mientras que DoH/DoT aseguran la confidencialidad del transporte. Lo ideal es combinar ambos: transporte cifrado + validación criptográfica de la respuesta. En la práctica, muchos resolutores públicos ya validan DNSSEC por ti; tu tarea es activar DoH/DoT en el cliente/sistema para cerrar el círculo.

Cómo funciona cada protocolo

DoT (puerto 853, TLS sobre TCP): arquitectura y flujo

DoT encapsula las consultas DNS tradicionales dentro de una sesión TLS explícita por el puerto 853. Técnicamente es “DNS sobre TLS”: menos capas que DoH, sin cabeceras HTTP.
Ventajas operativas:

Tráfico identificable como DNS cifrado (bueno para redes que quieren reconocer y permitirlo explícitamente).
Implementación limpia para clientes/sistemas (Android “Private DNS” lo usa de base).
Inconvenientes:
Al ser un puerto dedicado (853), algunas redes lo bloquean por defecto.
Menos “camuflaje” frente a inspección superficial.

Experiencia comunitaria #2 (estabilidad): admins reportan que, en entornos gestionados, DoT suele ser más predecible a nivel de políticas corporativas, especialmente cuando se quiere auditar/permitir explícitamente el tráfico DNS cifrado sin abrir la puerta a “cualquier HTTPS”.

DoH (HTTPS/HTTP-2 por 443): arquitectura, “camuflaje” y CDN

DoH mete DNS dentro de peticiones HTTPS (normalmente HTTP/2 o HTTP/3) por el puerto 443, mezclándose con el resto del tráfico web.
Ventajas:

Alta probabilidad de atravesar redes restrictivas (443 rara vez se bloquea).
Puede beneficiarse de CDNs y conexiones persistentes para latencias competitivas.
Riesgos/retos:
Desde la perspectiva de redes/filtrado corporativo, es más difícil distinguirlo de tráfico web normal.
Navegadores pueden forzar su propio resolutor DoH, saltándose políticas locales.

Experiencia comunitaria #3 (bypass de políticas): en foros de MSPs y escuelas se repite la queja: si un navegador trae DoH activado hacia un resolutor externo, los controles de DNS locales (Pi-hole, filtrado por IP) pueden perder eficacia salvo que gestiones listas de excepciones, policies de navegador o interceptes por SNI/mitigaciones avanzadas.

DoH vs DoT en la práctica (red doméstica, empresa, movilidad)

Rendimiento real y latencia: qué esperar

En benchmarks informales compartidos por usuarios, la diferencia media de latencia es pequeña (decenas de ms) entre DoH y DoT cuando el resolutor y la ruta son similares. Donde sí puede notarse es en:

Reutilización de conexiones: DoH sobre HTTP/2/3 puede aprovechar conexiones persistentes y multiplexing.
Ubicación del resolutor/CDN: algunas rutas hacia proveedores con presencia local recortan RTT.
Primer establecimiento: el handshake TLS inicial se paga una vez, luego el cacheo y la sesión ayudan.

Experiencia comunitaria #4 (percepción de usuario): mucha gente reporta que “no nota nada”, y cuando sí lo nota, suele deberse más al resolutor elegido (capacidad, anycast, cercanía) que al protocolo en sí.

Filtrado y cumplimiento: MSPs, escuelas y control parental

DoT a nivel de sistema facilita aplicar políticas globales en endpoints (MDM, GPOs) y auditar orígenes.
DoH por navegador ofrece privacidad individual pero fragmenta el control: cada app puede decidir su resolutor.
Buenas prácticas:
- En empresas/escuelas, definir el canal oficial (DoT o DoH) y bloquear alternativas que lo eludan.
- Lista de resolutores permitidos y policy de navegador (por ejemplo, Firefox/Chrome) para forzar el deseado.
- Complementar con DNSSEC y registros/alertas de anomalías.

Experiencia comunitaria #5 (resolutores mixtos): en despliegues reales, combinar DoT en el SO con DoH desactivado en el navegador (o apuntado al mismo resolutor interno) reduce sorpresas y mantiene coherencia de políticas.

Bloqueos e inspección: por qué DoH suele atravesar 443 y DoT no

DoT: si el puerto 853 está cerrado en la red, no hay trato.
DoH: viaja por 443, comparte autopista con todo el HTTPS y se “camufla”.
Implicación: para un usuario en cafetería/hotel, DoH tiene más probabilidades de funcionar; para un admin, requiere reglas más finas si se necesita control.

Experiencia comunitaria #6 (entornos restringidos): en hoteles y universidades, usuarios reportan que DoH funciona “out-of-the-box” donde DoT falla, precisamente por el bloqueo del 853.

Guías rápidas de activación

Android (Private DNS/DoT)

Ajustes → Red e Internet → DNS privado.
Elige Nombre de host del proveedor de DNS privado y pega el hostname DoT de tu resolutor (p. ej., de Cloudflare/Quad9).
Guarda y verifica: abre https://1.1.1.1/help (o equivalente del proveedor) para confirmar DoT activo.
Tip práctico: si alguna app no resuelve, revisa que el hostname sea correcto y que la red no bloquee 853.

Windows 11 / Server (DoH a nivel de sistema)

Configuración → Red e Internet → Propiedades del adaptador.
Establece servidores DNS y marca usar cifrado (DoH) si tu build lo soporta; alternativamente, usa netsh/Política de Grupo para forzar DoH hacia resolutores conocidos.
Comprueba con nslookup y páginas de verificación del proveedor.
Tip práctico: define los dominios de exclusión si usas resolutores internos para servicios corporativos.

Firefox (DoH por navegador y excepciones)

Ajustes → General → Configuración de red → Activar DNS sobre HTTPS.
Elige proveedor (o personalizado) y guarda.
En entornos gestionados, usa políticas de empresa (JSON/plantillas) para forzar o desactivar DoH según tu estándar.
Tip práctico: si usas Pi-hole o filtrado local, considera apuntar DoH al resolutor interno para no “saltártelo”.

Checklist de elección rápida: qué usar según tu escenario

Empresa/escuela con políticas centralizadas → Prioriza DoT a nivel de sistema, DoH desactivado en navegadores o apuntado al resolutor corporativo.
Usuario en redes públicas/restrictivas → DoH suele “salvar” más situaciones (443 abierto).
Dispositivos Android → Private DNS (DoT) nativo, fácil y limpio.
Objetivo principal: visibilidad y control → DoT, puerto dedicado, logging coherente.
Objetivo principal: conectividad sin fricción → DoH, mejor traversal en redes duras.
En todos los casos → Elige resolutor con DNSSEC, política de datos clara y presencia cercana (anycast).

Tabla comparativa (resumen)

Aspecto	DoT	DoH
Capa	TLS sobre TCP	HTTPS (HTTP/2/3)
Puerto	853 (dedicado)	443 (compartido)
“Camuflaje”	Bajo (fácil de identificar)	Alto (parece web normal)
Facilidad en redes restringidas	Menor (a veces bloqueado)	Mayor (443 abierto)
Gestión corporativa	Muy buena a nivel SO	Requiere políticas por app/navegador
Rendimiento	Similar (depende de ruta)	Similar; +beneficios por HTTP/2/3
Riesgo de bypass de filtrado local	Menor	Mayor si el navegador elige su resolutor

Preguntas frecuentes esenciales

¿Es “más seguro” DoH que DoT?

No. Ambos cifran el canal y ofrecen seguridad comparable. La diferencia no es el “qué” (cifrado) sino el “cómo se integra”: DoT se gestiona como DNS cifrado explícito; DoH se mezcla con web. El “más seguro” dependerá de tu modelo de amenazas y necesidades operativas.

¿Cómo evitar bypasses al filtrado DNS?

Forzar resolutor oficial (DoT/DoH) en SO y políticas de navegador.
Bloquear resolutores externos a nivel de firewall (SNI/IPs si aplica) y el puerto 853 si no se usa DoT.
Supervisar incongruencias (apps que resuelven sin pasar por tu canal autorizado).

¿DoH rompe Pi-hole o filtrado local?

Puede saltar tu Pi-hole si el navegador apunta a un resolutor DoH externo. Solución: desactiva DoH en el navegador o apúntalo al Pi-hole (si expone DoH/DoT) para mantener las reglas locales.

¿Qué elijo si solo quiero “mejorar privacidad” sin líos?

Configura DoT (Private DNS) en Android y DoH a nivel de sistema en Windows con un resolutor público confiable (Cloudflare/Google/Quad9). Es rápido de aplicar y ya te da un salto de privacidad frente a DNS en claro.

Conclusión

DoH y DoT resuelven el mismo problema con enfoques distintos. Si buscas control y claridad operativa, DoT a nivel de sistema brilla. Si priorizas conectividad en cualquier red, DoH tiene ventaja por el 443. La clave para “ganar” no es el protocolo aislado, sino alinear el protocolo con tu escenario (hogar, empresa, movilidad), elegir bien el resolutor y cerrar huecos (políticas de navegador, listas de permitidos, DNSSEC).

Relacionados