DoH3, DoQ y DoT: todo lo que cambia a finales de 2025

Por CaptainDNS
Publicado el 1 de diciembre de 2025

#DNS
#DoH
#DoT
#DoQ
#Seguridad

Esquema que compara DoH3, DoQ y DoT en una arquitectura DNS moderna

TL;DR

DoT se ha convertido en la base ampliamente desplegada del DNS cifrado, mientras que DoH3 y DoQ generalizan QUIC para transportar las consultas.
A finales de 2025, cada vez más sistemas operativos, navegadores y resolvedores activan DNS cifrado por defecto, reduciendo la visibilidad en el puerto 53 clásico.
Estos cambios impactan directamente la arquitectura DNS de la empresa: resolvedores, cortafuegos, proxies, observabilidad y cumplimiento deben adaptarse.
La estrategia adecuada no es “elegir un ganador”, sino diseñar un enfoque multitransporte: DoT como base, DoH3 y DoQ para los casos en los que la latencia, la resiliencia y la movilidad son críticos.

Contexto: del DNS en claro al DNS cifrado

Durante décadas, la resolución DNS se hizo mayoritariamente en claro sobre UDP/TCP 53. Era sencillo de depurar y filtrar en red, pero dejaba la puerta abierta a la escucha, la inyección de respuestas y el perfilado masivo del tráfico.

Con el auge de la privacidad y la generalización de TLS en la web, el DNS siguió el mismo camino: cifrar el “último tramo” entre el cliente (stub resolver) y el resolvedor recursivo y, más recientemente, adoptar transportes modernos como QUIC.

A finales de 2025, tres piezas estructuran el panorama del DNS cifrado para el flujo cliente → resolvedor: DoT, DoH (incluido DoH3) y DoQ. Entender sus diferencias es clave para anticipar los efectos en tus arquitecturas.

Recordatorio rápido: DoT, DoH, DoH3 y DoQ

DNS clásico (UDP/TCP 53)

El DNS histórico se apoya en UDP 53 para la mayoría de las consultas, con un fallback TCP 53 para transferencias de zona (XFR) y respuestas voluminosas. Es simple y rápido, pero totalmente en claro: un observador de red puede ver los dominios resueltos, inyectar respuestas falsas o bloquear ciertas consultas.

DNS over TLS (DoT)

DoT encapsula el DNS en un flujo TLS (generalmente en TCP 853) entre el cliente y el resolvedor. Estandarizado en el RFC 7858, busca impedir la escucha y la manipulación de las consultas en el trayecto de red.

En la práctica, DoT:

usa un canal TCP/TLS dedicado (puerto 853);
ofrece propiedades de confidencialidad similares a las de un HTTPS “clásico”;
está ampliamente soportado por los grandes resolvedores públicos y muchos resolvedores recursivos de código abierto.

Hoy DoT es la base más madura para el DNS cifrado en infra, sobre todo porque sigue siendo conceptualmente cercano al dúo DNS + TLS que ya dominamos.

DNS over HTTPS (DoH) y DoH3

DoH transporta las consultas DNS encima de HTTPS (RFC 8484), por tanto en el puerto 443, en un canal HTTP/2 o HTTP/3. El mensaje DNS se encapsula en el cuerpo de la petición HTTP, lo que permite aprovechar toda la pila web: proxies HTTP, autenticación, CDN, etc.

Cuando DoH se usa sobre HTTP/3 (basado en QUIC), se suele hablar de “DoH3”:

misma semántica DNS que DoH;
mismo puerto 443 que el tráfico web, lo que complica el filtrado;
mismos beneficios de QUIC: 0-RTT posible, mejor gestión de pérdidas, multiplexación eficiente.

DoH3 interesa especialmente a los navegadores y a algunas aplicaciones, porque les permite ocultar el DNS dentro del flujo HTTPS existente y aprovechar QUIC.

DNS over QUIC (DoQ)

DoQ utiliza QUIC directamente como transporte para DNS, sin pasar por HTTP. Definido en el RFC 9250, busca combinar:

propiedades de confidencialidad similares a un canal TLS (como DoT);
el rendimiento y la resiliencia de QUIC: sin head-of-line blocking a nivel de transporte, mejor recuperación ante pérdidas, soporte nativo de 0-RTT y movilidad de conexión.

En la práctica:

DoQ utiliza normalmente el puerto UDP 853, ya asociado históricamente a DNS-over-TLS/DTLS;
cada conexión QUIC puede transportar varias consultas DNS multiplexadas;
el protocolo es especialmente adecuado para entornos con latencia variable (wifi denso, móvil, etc.).

Lo que realmente cambia a finales de 2025

La novedad no es la existencia de DoT, DoH o DoQ—todos están estandarizados desde hace años—sino su nivel de despliegue y activación por defecto.

En resumen:

DoT es la pieza “de base” del DNS cifrado para los resolvedores recursivos y los servicios gestionados.
DoH está ampliamente soportado por navegadores, SO y librerías de aplicaciones, con un aumento del modo HTTP/3 (DoH3).
DoQ va saliendo del terreno experimental para convertirse en opción seria en varios servidores recursivos modernos, sobre todo en entornos sensibles a la latencia y a la resiliencia.

Estas tendencias tienen varias consecuencias concretas para los equipos de red/DNS.

1. QUIC se convierte en transporte DNS de primer nivel (DoH3 y DoQ)

La adopción de QUIC ya no se limita al tráfico web: una parte creciente de las resoluciones DNS entre clientes y resolvedores pasa por HTTP/3 (DoH3) o por DoQ.

Impactos clave:

Latencia: la combinación 0-RTT + ausencia de head-of-line blocking en el transporte mejora el tiempo de resolución percibido, sobre todo en redes con pérdida o latencia variable.
Estabilidad: QUIC gestiona mejor el cambio de dirección IP (roaming wifi ↔ 4G/5G) manteniendo la conexión lógica.
Superficie de filtrado: bloquear “el DNS” ya no es inspeccionar solo UDP/TCP 53; hay que contemplar QUIC en 443 (DoH3) y UDP 853 (DoQ).

Para una arquitectura empresarial, las decisiones de filtrado DNS deben considerar los transportes, no solo los puertos históricos.

2. Generalización del DNS cifrado en SO y navegadores

Los sistemas modernos (desktop, móvil, servidor) ya ofrecen opciones nativas para activar DoT o DoH, a veces a nivel de sistema, a veces por aplicación (navegador, cliente VPN, agente de seguridad).

Consecuencias:

Algunos puestos pueden empezar a pasar por encima del resolvedor de empresa para consultar directamente un resolvedor público en DoH3/DoT.
Según la política, esto puede entrar en conflicto con las exigencias de registro, cumplimiento o filtrado (proxy de seguridad, DLP, etc.).
Los equipos de IT deben decidir con claridad: ¿qué flujos están permitidos hacia resolvedores externos, en qué transportes y en qué casos?

3. Observabilidad y depuración más complejas

Con el DNS cifrado, ya no es posible inspeccionar el contenido de las consultas en la red entre cliente y resolvedor sin una terminación TLS/QUIC controlada.

Esto impacta:

las herramientas de captura y análisis de tráfico (tcpdump, Wireshark, sondas NDR);
los procesos de depuración “de urgencia” (filtrado inesperado, TTL incoherentes, desfases de caché entre resolvedores internos y externos);
la correlación entre logs DNS y logs de aplicaciones.

La recomendación: desplazar parte de la observabilidad al nivel del resolvedor (logs estructurados, métricas, trazas) en lugar de limitarse a los paquetes de red.

4. Mayor madurez de las implementaciones del lado servidor

Los grandes resolvedores recursivos open source (y comerciales) ya incluyen implementaciones estables de DoT, a menudo de DoH y cada vez más de DoQ. Esto permite:

desplegar un resolvedor interno o “split-horizon” que acepte varios transportes (UDP/TCP 53, DoT, eventualmente DoH/DoQ);
separar la forma en que los clientes se conectan del modo usado para consultar a los servidores autoritativos;
evolucionar progresivamente los puestos clientes sin romper la arquitectura DNS global.

Comparativa rápida DoT / DoH3 / DoQ

A continuación, un cuadro sintético para situar estos tres transportes en tu diseño.

Protocolo	Transporte subyacente	Puerto típico	Multiplexación	Camuflado en el tráfico web	Casos de uso típicos
DoT	TLS sobre TCP	853/TCP	Limitada al flujo TCP único	No	Base de DNS cifrado entre clientes/forwarders y resolvedores de empresa o públicos
DoH3	HTTP/3 (QUIC) sobre UDP	443/UDP	Sí, vía HTTP/3	Sí (difícil de distinguir del HTTPS)	Navegadores, aplicaciones que quieren integrarse en la pila HTTP existente
DoQ	QUIC nativo sobre UDP	853/UDP	Sí, multiplexación QUIC	No (pero se parece a QUIC genérico)	Resolvedores recursivos modernos; entornos sensibles a la latencia y la resiliencia

Dato útil: en todos los casos, estos protocolos no sustituyen a DNSSEC (que protege la integridad de los datos DNS entre resolvedores y autoridades), sino que lo complementan protegiendo la confidencialidad e integridad del transporte entre el cliente y su resolvedor.

Impactos arquitectónicos en tus infraestructuras DNS

Flujos DNS cifrados entre cliente, resolvedor de empresa y resolvedores públicos

Este esquema ilustra una arquitectura típica a finales de 2025:

A la izquierda, el cliente (puesto, móvil, servidor) dispone de un stub resolver capaz de hablar DNS clásico (UDP/TCP 53), DoT, DoH3 o DoQ.
En el centro, uno o varios resolvedores de empresa terminan estos transportes, aplican caché, split-horizon y filtrado.
A la derecha, los resolvedores públicos y los servidores autoritativos se consultan en DNS clásico o DNS cifrado según la política adoptada.

La pregunta clave pasa a ser: ¿qué flujos cliente → resolvedor de empresa → resolvedores públicos están permitidos, cifrados y son observables?

Resolvedores públicos vs. resolvedores de empresa

A finales de 2025 es habitual que un mismo puesto pueda:

usar el resolvedor interno de empresa en UDP/TCP 53 o DoT;
en paralelo, consultar uno o varios resolvedores públicos en DoH3 o DoQ mediante aplicaciones específicas (navegador, agente de seguridad, cliente VPN).

Decisiones a tomar en arquitectura:

¿Los puestos deben obligatoriamente usar los resolvedores de empresa para toda resolución?
¿Los resolvedores de empresa expondrán DoT y/o DoQ a los clientes internos?
¿Los flujos DoH/DoH3 hacia resolvedores públicos están permitidos, bloqueados o redirigidos (proxy, interceptación TLS controlada)?

Anycast, CDN y geolocalización

Con el DNS cifrado, los grandes resolvedores públicos usan masivamente Anycast y reparten las conexiones QUIC/TLS según la ubicación del cliente. Esto puede provocar:

variaciones de resolución (distintos puntos de entrada en un CDN según la IP de origen vista por el resolvedor);
diferencias entre lo que ve un cliente en DoH3/DoQ y otro en UDP 53 hacia un resolvedor distinto;
efectos secundarios cuando un proxy o un VPN modifica la IP de origen.

Para aplicaciones sensibles a la latencia o a la geolocalización (vídeo, juegos, APIs críticas), puede ser útil documentar claramente qué resolvedor se espera y qué transporte se recomienda.

Observabilidad, logs y cumplimiento

En un mundo donde el DNS es cifrado por defecto, la buena práctica consiste en:

centralizar los logs a nivel de los resolvedores (consultas, respuestas, códigos de error, tiempos de resolución);
exponer métricas (Prometheus, OpenTelemetry, etc.) para seguir latencia, fallos y volúmenes por transporte (UDP, DoT, DoH3, DoQ);
definir qué se registra para respetar el RGPD y las políticas internas de privacidad.

En otras palabras: en lugar de “olfatear el puerto 53”, hay que dotar de herramientas a los resolvedores.

Seguridad y control de acceso

Los controles de seguridad deben replantearse:

filtrado de salida: ¿qué puertos/hosts están permitidos para DoT (853), DoQ (853/UDP), DoH3 (443/QUIC)?
segmentación: ¿qué segmentos de red pueden salir hacia resolvedores públicos y cuáles deben pasar obligatoriamente por un resolvedor interno?
detección: ¿cómo detectar un puesto que envía DNS cifrado no autorizado directamente a Internet?

Un diseño robusto suele combinar:

uno o varios resolvedores internos que expongan al menos DoT;
políticas claras (y aplicadas) sobre los flujos DNS cifrados salientes;
un monitoreo regular de los intentos de resolución “fuera de perímetro”.

Checklist técnica a finales de 2025

Esta checklist te ayuda a evaluar rápidamente tu nivel de preparación.

Capa	Punto de control	Pregunta a hacerse
Resolvedor interno	Soporte DoT (y eventualmente DoQ)	¿Mis resolvedores internos ofrecen al menos DoT a los clientes?
Firewall / proxy	Política sobre 53/853/443	¿Tengo reglas explícitas para DNS cifrado (DoT, DoH3, DoQ) y no solo para UDP/TCP 53?
Puestos cliente	Configuración DNS	¿Quién controla la configuración DNS de SO y navegadores (GPO, MDM, scripts, etc.)?
Observabilidad	Logs y métricas DNS	¿Puedo correlacionar una caída de aplicación con métricas de DNS cifrado (latencia, timeouts, errores)?
Cumplimiento	Trazabilidad	¿Tengo una respuesta clara a “quién resolvió qué, cuándo y a través de qué resolvedor” respetando la confidencialidad?

También puedes descargar la comparativa en CSV (ver bloque de descarga del artículo) para usarla en tus propios dashboards o documentos internos.

Plan de acción recomendado para los equipos de infra

Cartografiar lo existente
- ¿Qué resolvedores se usan (internos, externos)?
- ¿Qué transportes ya están en producción (UDP/TCP 53, DoT, DoH, túneles VPN, etc.)?
Definir un objetivo claro
- DoT como base obligatoria entre puestos y resolvedores internos.
- DoH3 y/o DoQ activados de forma controlada según el caso de uso (movilidad, rendimiento, restricciones de aplicación).
Actualizar los resolvedores
- Activar DoT en prioridad, con certificados gestionados correctamente.
- Evaluar DoQ en un entorno piloto (latencia, estabilidad, observabilidad).
Ajustar el filtrado de red
- Formalizar una política sobre los flujos DNS cifrados salientes.
- Documentar las excepciones (relay DNS de un socio, sitio remoto, agente de seguridad).
Implementar observabilidad
- Centralizar los logs DNS a nivel de los resolvedores.
- Seguir volúmenes y latencia por transporte (UDP, DoT, DoH3, DoQ).
Comunicar con los equipos de aplicación
- Explicar los cambios (nuevos puertos, nuevos resolvedores, posibles comportamientos de los navegadores).
- Documentar las buenas prácticas para elegir resolvedores en las aplicaciones.
Probar regularmente
- Scripts o jobs de monitoreo que prueben la resolución vía cada transporte (UDP, DoT, DoH3, DoQ) hacia tus resolvedores clave.
- Análisis de las diferencias de latencia y de comportamiento (timeouts, fallos esporádicos).

FAQ

¿Tengo que migrar todo a DoQ y abandonar DoT?

No. DoQ no es un reemplazo brusco de DoT, sino una opción adicional. En la práctica, la mayoría de las arquitecturas seguirán siendo multitransporte: UDP/TCP 53 para compatibilidad, DoT como base cifrada, DoH3 y/o DoQ para perímetros concretos (movilidad, rendimiento, restricciones aplicativas).

¿DoH3 y DoQ son más seguros que DoT?

En lo criptográfico, las tres opciones se apoyan en primitivas similares (TLS o QUIC sobre TLS) y ofrecen un nivel de confidencialidad comparable. Las diferencias están más en el transporte: multiplexación, gestión de pérdidas, camuflaje en el tráfico web, capacidad de atravesar ciertos middleboxes.

¿Qué puertos debo abrir en mis cortafuegos para estos protocolos?

En general: DoT usa 853/TCP, DoQ 853/UDP, DoH/DoH3 el puerto 443 (TCP y/o UDP según HTTP/2 u HTTP/3). La política de apertura debe pensarse: autorizar sistemáticamente estos puertos hacia Internet permite que los puestos eviten los resolvedores internos.

¿El DNS cifrado rompe mi filtrado DNS actual?

Puede saltárselo si los puestos consultan directamente resolvedores públicos en DoH3/DoT/DoQ. Por eso es crucial definir una política clara: qué flujos DNS cifrados están permitidos, cuáles deben pasar obligatoriamente por un resolvedor de empresa y cómo detectar desviaciones.

¿Cómo pruebo si mi resolvedor soporta DoT, DoH3 o DoQ?

En general, cada implementación documenta comandos de ejemplo (con kdig, drill, curl para DoH o clientes específicos DoQ). Puedes integrar estas pruebas en tus procedimientos de validación y scripts de supervisión para asegurarte de que cada transporte funciona como se espera.