La versión corta: el DNS clásico (el protocolo de 1987) envía las consultas en texto plano por UDP port 53. Cualquier nodo en la ruta de red puede leer cada dominio que estás consultando, modificar las respuestas o bloquear consultas específicas. DoT (RFC 7858, 2016) envuelve las consultas DNS en TLS sobre port 853. DoH (RFC 8484, 2018) las incluye dentro de peticiones HTTPS en port 443. Ambos resuelven el problema del texto plano. Divergen en quién controla el despliegue, quién puede ver las consultas y quién puede bloquearlas — y esa es la pregunta que la mayoría de la gente se hace en realidad cuando pregunta "¿cuál debería usar?". Depende de contra qué te estás protegiendo.
Qué arregla el cifrado DNS — y qué no
Antes de comparar los dos, conviene dejar claro qué protege realmente cada protocolo. El DNS clásico filtra cada nombre de dominio que tu dispositivo consulta. Visita example.com y tu ISP — o cualquier operador de red en la ruta — puede ver la consulta de example.com, incluso antes de que tu navegador envíe la primera petición HTTPS. El contenido real de esa petición HTTPS está cifrado; la consulta DNS que la precedió no lo está. El DNS cifrado cierra exactamente esa brecha.
Lo que no arregla: la dirección IP de destino a la que te conectas sigue siendo visible. El campo TLS Server Name Indication (SNI), en versiones anteriores de TLS, también filtraba el nombre de host durante el handshake — aunque Encrypted Client Hello (ECH) resuelve eso en TLS 1.3. DNS cifrado más ECH cierra las filtraciones obvias. Sin ECH, el DNS cifrado por sí solo cierra una fuga pero deja abierta la del SNI, lo que significa que el nombre de host de destino sigue siendo visible durante el handshake TLS. El encuadre honesto: el DNS cifrado es necesario, pero no suficiente.
Cómo funciona DoT — canal dedicado en port 853
DoT (DNS-over-TLS, definido en RFC 7858) es el diseño conceptualmente más sencillo. Tu dispositivo abre una conexión TCP al servidor DNS en port 853. Realiza un handshake TLS — el mismo TLS que protege HTTPS — y luego envía consultas DNS estándar dentro del flujo cifrado. El servidor DNS responde con respuestas DNS estándar, también dentro del flujo cifrado. Desde el cable, la red solo ve una conexión TLS al port 853.
Dado que el port 853 está asignado oficialmente por la IANA exclusivamente a DoT, cualquier tráfico TCP en ese puerto es inequívocamente DoT. Los operadores de red pueden identificar DoT de forma trivial — no necesitan inspección profunda de paquetes, basta con mirar el puerto de destino. Si quieren bloquear DoT, descartan el port 853. Si quieren permitirlo pero registrar la IP del servidor DNS de destino, eso también es sencillo. DoT es transparente sobre ser DNS, lo cual es una virtud en algunos casos de uso y un inconveniente en otros.
Cómo funciona DoH — DNS oculto dentro del tráfico web
DoH (DNS-over-HTTPS, definido en RFC 8484) adopta un enfoque diferente. Tu dispositivo envía consultas DNS como peticiones HTTP POST (o GET con el parámetro de consulta) a una URL específica en el servidor HTTPS del proveedor DNS. El cuerpo del POST contiene un mensaje DNS binario; el cuerpo de la respuesta contiene una respuesta DNS binaria. Todo ocurre sobre una conexión HTTPS normal en port 443 — el mismo puerto que usa tu navegador para cargar páginas web.
Desde la perspectiva de la red, una petición DoH es indistinguible de una petición HTTPS normal al mismo servidor. La conexión parece tráfico web. Los tamaños de los paquetes parecen tráfico web (tras la consulta inicial, las consultas posteriores reutilizan la misma conexión HTTP/2 o HTTP/3). La IP de destino pertenece a un endpoint de apariencia genérica — el 1.1.1.1 de Cloudflare o el 8.8.8.8 de Google sirven tanto DoH como otro tráfico web en las mismas IPs. Para bloquear DoH específicamente, un operador de red tiene que identificar y bloquear los endpoints concretos, lo cual es mucho más difícil que bloquear un puerto.
Diferencias de visibilidad en la red
La diferencia de transporte genera una diferencia de visibilidad. Con DoT, tu operador de red (IT corporativo, ISP, colegio, hotel) puede ver que usas DNS cifrado, puede ver qué servidor DoT estás usando (por IP de destino) y puede elegir bloquear ese servidor. Con DoH, el operador de red puede ver tráfico HTTPS cifrado hacia la IP del proveedor DNS, pero a menos que mantenga listas de bloqueo específicas de endpoints DoH, no puede distinguir DoH del HTTPS normal hacia ese mismo proveedor.
Esto tiene consecuencias predecibles. Los departamentos de IT corporativo prefirieron mayoritariamente DoT durante años porque pueden bloquearlo fácilmente: descartan el port 853 y el DNS cae de vuelta al resolvedor de la organización, que monitorizan y filtran. Tienden a no querer DoH por la misma razón — elude su visibilidad. Los defensores de la privacidad del consumidor prefieren mayoritariamente DoH por ese mismo motivo. Distintos actores quieren resultados diferentes de la misma decisión arquitectónica.
Cuál pueden bloquear las redes
DoT es fácil de bloquear. El port 853 es lo único que usa ese puerto; una regla de firewall para descartarlo y listo. Muchas redes empresariales ya lo hacen. Muchos firewalls de filtrado en regiones restrictivas también. Si configuras un dispositivo para usar DoT y esa red bloquea el port 853, las consultas DNS del dispositivo fallan hasta que el SO o la aplicación caen de vuelta al DNS en texto plano — y la mayoría lo hacen en silencio.
DoH es mucho más difícil de bloquear porque la única forma de hacerlo es identificar y añadir a una lista negra todos los endpoints DoH. El 1.1.1.1 de Cloudflare es el más conocido y suele estar en esa lista; el 8.8.8.8 de Google también habitualmente. Pero los endpoints DoH operados de forma independiente proliferan — listas públicas como la wiki DoH de curl catalogan cientos. Un operador de red que quiera bloquear DoH globalmente tiene que mantener esa lista actualizada y aceptar que siempre irá un paso por detrás de los nuevos endpoints. Algunas redes restrictivas intentan detectar DoH mediante análisis de patrones de tráfico (DoH tiene características distintivas de tamaño de petición y temporización), pero esto es frágil y produce falsos positivos.
La documentación de Mozilla sobre DoH cita explícitamente esta propiedad — que DoH es difícil de bloquear para las redes — como un objetivo de diseño deliberado, no como un accidente. Esa misma propiedad hace que DoH sea controvertido en entornos empresariales, donde el operador de red considera que la visibilidad DNS es una parte legítima de su stack de seguridad y no una violación de la privacidad del usuario.
Implicaciones para empresas y controles parentales
El filtrado a nivel DNS (el que impulsa la mayoría del software de control parental, el filtrado corporativo de "navegación segura" y las formas más simples de bloqueo de dominios maliciosos) funciona interceptando las consultas DNS y descartando las de dominios bloqueados o devolviendo respuestas falsas. Cubrimos la mecánica en nuestro artículo sobre cómo funciona realmente el filtrado a nivel DNS.
El DNS cifrado elude esto por completo — tanto DoT como DoH enrutan las consultas hacia un resolvedor distinto al de la red local, por lo que cualquier filtrado aplicado en el resolvedor local queda anulado. Desde la perspectiva del proveedor de control parental, esto es un problema. Desde la perspectiva del usuario, depende completamente de si considera el filtrado legítimo o invasivo. La mayoría de las herramientas de gestión de endpoints empresariales ya deshabilitan el DoH del navegador mediante políticas y se apoyan en la configuración DNS a nivel de SO o en la inspección completa del tráfico para mantener la visibilidad. Los perfiles de iOS gestionados por MDM de Apple incluyen un mecanismo de configuración DoH/DoT diseñado exactamente para esto: la empresa puede especificar un resolvedor DNS cifrado de su elección e impedir que los usuarios lo modifiquen.
Para los hogares, la realidad práctica es que activar DoH en un navegador elude cualquier filtrado de contenido basado en el router que hayas configurado. Eso es una funcionalidad o un defecto según desde qué lado de la configuración estés.
Características de rendimiento
DoT tiene típicamente una sobrecarga por consulta ligeramente menor que DoH. Ambos protocolos usan TLS, pero DoT envía un envoltorio mucho más pequeño alrededor de cada mensaje DNS — no hay línea de petición HTTP, ni cabeceras, ni Content-Length, ni método HTTP. El mensaje DNS va directamente al flujo TLS. DoH, en cambio, envuelve cada consulta DNS dentro de un HTTP POST o GET, lo que añade decenas o cientos de bytes de sobrecarga por consulta.
Esa sobrecarga queda mayoritariamente amortizada por la reutilización de conexiones. Tanto DoT como DoH mantienen la conexión TLS abierta a través de muchas consultas, por lo que el coste del handshake se paga una sola vez. DoH sobre HTTP/2 multiplexa las consultas en la misma conexión, y HTTP/3 (sobre QUIC) reduce aún más la latencia. En la práctica, en una red moderna, los dos protocolos producen una latencia indistinguible para el usuario — como mucho, diferencias de un solo dígito en milisegundos. No elijas uno sobre el otro por razones de rendimiento; la elección trata sobre visibilidad, control y modelo de amenaza.
DoT vs DoH de un vistazo
| Propiedad | DNS-over-TLS (DoT) | DNS-over-HTTPS (DoH) |
|---|---|---|
| Puerto | 853 (dedicado) | 443 (compartido con HTTPS) |
| RFC | RFC 7858 (2016) | RFC 8484 (2018) |
| Transporte | TLS puro sobre TCP | HTTPS (HTTP/2 o HTTP/3) |
| Identificable en el cable | Sí — el port 853 es exclusivo de DoT | No — parece HTTPS normal |
| Facilidad de bloqueo por la red | Fácil (descartar port 853) | Difícil (requiere lista negra de endpoints) |
| Soporte en navegadores | No (los navegadores no implementan DoT) | Firefox, Chrome, Edge, Safari lo soportan todos |
| Soporte en SO | Android 9+, iOS 14+, macOS 11+, Linux (systemd-resolved) | Android 9+, iOS 14+, macOS 11+, Windows 11+ |
| Visibilidad empresarial | Visible por puerto; fácil de monitorizar o bloquear | Elude la monitorización por puerto; requiere inspección de endpoints |
| Sobrecarga de latencia por consulta | Menor (envoltorio mínimo) | Ligeramente mayor (cabeceras HTTP); despreciable con multiplexación HTTP/2 |
| Resistencia a la censura | Baja (bloqueable por puerto) | Mayor (el port 443 es esencial para la web moderna) |
¿Cuál deberías usar? — tres escenarios
"Qué protocolo es mejor" depende enteramente de lo que quieras conseguir. Aquí hay tres escenarios concretos con respuestas concretas:
Escenario 1: dispositivo personal en redes hostiles o no confiables
Cafeterías, hoteles, aeropuertos, el Wi-Fi de un amigo. El modelo de amenaza es el operador de la red local observando o modificando tu DNS. Cualquiera de los dos protocolos funciona para el propio cifrado; DoH es preferible porque es mucho más difícil de bloquear para una red hostil. Si usas DoT en una red que descarta el port 853, tus consultas caen silenciosamente de vuelta al texto plano en port 53 (la mayoría de los clientes del SO fallan de forma abierta) — y habrás filtrado todo lo que intentabas proteger. DoH casi siempre alcanza su endpoint.
Escenario 2: red doméstica con dispositivos infantiles gestionados
Quieres que los dispositivos de los niños usen un resolvedor DNS con filtrado (NextDNS, OpenDNS Family Shield, Cloudflare for Families) y que no puedan eludirlo. DoT es en realidad más sencillo aquí — configuras el dispositivo para usar un resolvedor DoT específico, y el niño no puede cambiar fácilmente un ajuste en el navegador para usar un DNS diferente. El DoH del navegador se puede deshabilitar mediante política empresarial/MDM o configurando el dominio canario. La elección entre DoT y DoH importa menos que configurar el DNS del dispositivo a nivel de SO en lugar de dejar que cada aplicación elija.
Escenario 3: ya usas una VPN
Si usas una VPN, la red local no puede ver tus consultas DNS de ninguna manera — el túnel VPN cifra todo, incluido el DNS. La pregunta relevante pasa a ser qué resolvedor DNS usa la VPN internamente y si admite DNS cifrado hacia su resolvedor upstream. La mayoría de las VPN modernas (incluida Casper's Cloak) usan DNS cifrado internamente y aplican filtrado de dominios amenazantes en el resolvedor antes de enviar la respuesta de vuelta a través del túnel. En esta configuración, DoT vs DoH es en su mayor parte un detalle de implementación; lo que importa es que el resolvedor no sea tu ISP y no esté registrando tus consultas.
La cuestión de la confianza que ambos protocolos eluden
Tanto DoT como DoH trasladan la confianza desde tu operador de red local hacia el proveedor de DNS cifrado que elijas. Cloudflare, Google, Quad9, NextDNS, ControlD — cada una de estas empresas ve todas las consultas DNS que les envías. El cifrado hacia ellas no significa privacidad frente a ellas. Si tu preocupación es que tu ISP no debería ver tu DNS, el DNS cifrado resuelve el problema. Si tu preocupación es que ningún tercero debería ver tu DNS, ninguno de los dos protocolos ayuda; necesitas ejecutar tu propio resolvedor recursivo (lo cual es un proyecto aparte).
Lo que puedes exigir al resolvedor en el que confías: una política de registro clara, auditorías de terceros, soporte para la minimización de consultas (de modo que los servidores autoritativos upstream solo vean las partes de la consulta que necesitan) y validación DNSSEC. Los principales proveedores públicos de DoH/DoT publican todos sus políticas; léelas. Nuestra guía más detallada sobre esto está en nuestro análisis DoH de 2026.
Conclusión
DoT y DoH resuelven el mismo problema fundamental — la filtración en texto plano de DNS que expone tus destinos de navegación a la red — con dos estrategias arquitectónicas diferentes. DoT es el diseño transparente: un puerto dedicado, fácil de identificar, fácil de gestionar, fácil de bloquear. DoH es el diseño camuflado: oculto en tráfico HTTPS, difícil de identificar sin listas negras de endpoints, difícil de bloquear a escala.
Para los usuarios en redes hostiles, DoH es la opción correcta porque es la que realmente alcanza su endpoint. Para las empresas que necesitan visibilidad DNS, DoT es la opción más cooperativa. Para quienes gestionan su propio DNS con filtrado en casa, DoT es más configurable y más difícil de eludir para los usuarios a nivel de aplicación. Para los usuarios de VPN, la elección es en su mayor parte invisible — el cliente VPN se encarga de ello.
La pregunta real rara vez es "¿DoT o DoH?" — es "¿a qué resolvedor estoy confiando y cuál es su política de registros?". Elige un resolvedor en el que confíes, configúralo a nivel de sistema (no por navegador) y verifica con una prueba de fugas DNS que realmente tienes la configuración correcta. El protocolo que uses para hablar con él importa menos que la política de la entidad al otro extremo.