Glosario de DNS

¿Qué es DoH (DNS sobre HTTPS)?

Abstract isometric UI showing network ranges, usage bars, region names (EMEA/APAC), and a purple "Deploy" button
Puntos claveLos puntos clave se generan con la ayuda de la inteligencia artificial. Dado que los resúmenes automáticos pueden contener en ocasiones errores u omitir contexto importante, consulta siempre la entrada completa del blog para obtener toda la información.

DNS over HTTPS (DoH), defined in RFC 8484, is a network protocol that encrypts DNS queries and responses by encapsulating them within HTTPS connections on port 443, protecting resolver traffic from on-path observation and tampering. For enterprises, the primary operational challenge is loss of visibility and control, as applications or browsers using their own DoH servers bypass internal resolvers, breaking DNS filtering, split-horizon answers, query logging, and threat detection. Managing DoH effectively requires organizations to deploy approved internal DoH-capable resolvers, enforce client and browser policies to use them, and monitor or block connections to unsanctioned DoH servers to maintain network security and troubleshooting capabilities.

  • DoH encapsulates DNS messages within HTTPS on port 443 (RFC 8484), making it indistinguishable from ordinary web traffic and preventing port-based network controls that work against the identifiable DNS over TLS (DoT) protocol on dedicated port 853.
  • Enterprise security teams lose critical telemetry and filtering capabilities when applications bypass internal resolvers via DoH, causing internal zones to fail with NXDOMAIN errors and blocking lists, sinkholes, and response policy zones from taking effect on affected clients.
  • DoH clients may silently fall back to unencrypted DNS when the DoH server is unreachable, potentially masking policy failures and creating gaps in query history that complicate incident response and auditing for network administrators.

DoH de un vistazo

AttributeValue
Full nameDNS over HTTPS
CategoryEncrypted DNS transport protocol
Defined inRFC 8484
Protocol and portHTTPS over TCP, port 443 by default
OSI layerApplication layer (layer 7)
Primary useEncrypting DNS traffic between a client and a recursive resolver
Related termsDNS over TLS, DNS, Recursive resolver, TLS, DNS filtering

Cómo funciona DoH

Un cliente DoH envuelve un mensaje DNS normal en una solicitud HTTPS y lo envía a un servidor DoH. El servidor devuelve la respuesta DNS en la respuesta HTTPS.

  1. Localizar el servidor DoH: el cliente se configura con una plantilla URI para el servidor DoH. Resuelve el nombre de host del servidor si es necesario y abre una conexión TCP al puerto 443, a menos que la URI indique otro puerto.
  2. Establecer TLS: el cliente y el servidor negocian una sesión TLS, y el cliente valida el certificado del servidor. Esto autentica al servidor y cifra todo lo que viene a continuación.
  3. Enviar la consulta: El cliente codifica la consulta DNS en formato estándar de transmisión y la envía en una solicitud HTTP utilizando el método GET o POST. El mensaje utiliza el tipo de medio «application/dns-message».
  4. Devolución de la respuesta: el servidor resuelve el nombre y devuelve la respuesta DNS en el cuerpo de la respuesta HTTP. El cliente la utiliza como cualquier otra respuesta DNS. El RFC 8484 establece HTTP/2 como la versión mínima recomendada de HTTP, lo que permite que muchas consultas compartan una misma conexión.

Dado que la sesión está cifrada, los dispositivos en la ruta solo ven una conexión TLS con el servidor DoH y no pueden leer ni alterar los nombres de las consultas. DoH protege únicamente el salto entre el cliente y el resolutor. No cifra el tráfico desde el resolutor hasta los servidores autoritativos, y el operador del resolutor sigue viendo todas las consultas.

Por qué es importante el DoH en las redes empresariales

El DNS tradicional sobre UDP y el puerto 53 de TCP no está cifrado, por lo que cualquier persona en la ruta de la red puede leer o modificar las consultas. La RFC 8484 estandarizó DoH para subsanar esa deficiencia, transportando el DNS dentro de HTTPS. Otro estándar, el DNS sobre TLS de la RFC 7858, cifra el DNS en su propio puerto dedicado, el 853. Esa distinción marca la diferencia entre DoH y el DNS sobre TLS: ambos cifran el mismo tráfico, pero DoH comparte el puerto 443 con el tráfico web habitual, mientras que el DNS sobre TLS puede identificarse —y, por lo tanto, gestionarse o bloquearse— por puerto.

Para las empresas, el principal efecto operativo es la pérdida de visibilidad. Una aplicación o un navegador que utilice su propio servidor DoH elude el resolutor interno, por lo que el filtrado de DNS, las respuestas de horizonte dividido para zonas privadas, el registro de consultas y la detección de amenazas vinculadas a ese resolutor ya no se aplican a ese tráfico. Es posible que los nombres internos no se resuelvan y que los equipos de seguridad pierdan una rica fuente de telemetría.

Gestionar bien el DoH implica decidir qué resolutores pueden utilizar los clientes. Los enfoques habituales consisten en ejecutar un resolutor interno autorizado compatible con DoH, configurar la política de clientes y navegadores para que lo utilicen, y bloquear o supervisar las conexiones a servidores DoH no autorizados. Dejar esto sin gestionar divide el DNS entre distintos resolutores, lo que dificulta la resolución de problemas, la auditoría y la respuesta ante incidentes.

Comparación de DoH con términos relacionados

DoH frente a DNS sobre TLS (DoT)

DoH transporta los mensajes DNS dentro de HTTPS en el puerto 443, mientras que DoT los transporta directamente dentro de una sesión TLS en un puerto dedicado, por lo que DoT resulta más fácil de identificar y controlar para una red. ¿Qué es el DNS sobre TLS?

AttributeDoHDNS over TLS (DoT)
StandardRFC 8484RFC 7858
TransportHTTP over TLSTLS directly over TCP
Default port443853
Visibility to network operatorsBlends with other HTTPS traffic, so port-based control is not possibleIdentifiable by its dedicated port, so it can be allowed, monitored or blocked
Message overheadAdds HTTP framing to each DNS messageAdds no HTTP framing
Typical clientOften built into browsers and applicationsOften configured at the operating system or resolver level

Problemas habituales con DoH

Un navegador o una aplicación con su propia configuración de resolutor DoH envía las consultas directamente a un servidor público y omite el resolutor interno. Las zonas internas fallan entonces con NXDOMAIN o tiempos de espera agotados, y los registros de horizonte dividido, la política de filtrado y el registro de consultas dejan de aplicarse a ese cliente.

Las herramientas de seguridad que inspeccionan o registran el tráfico en el puerto 53 no detectan nada procedente de los clientes DoH. Las listas de bloqueo, los «sinkholes» y las zonas de políticas de respuesta no surten efecto, y los investigadores encuentran lagunas en el historial de consultas de esos hosts.

DoH depende de TLS, por lo que un reloj del sistema incorrecto, una cadena de certificados no fiable o un proxy que inspeccione el tráfico TLS pueden hacer que el cliente no consiga conectarse al servidor DoH. Dependiendo de la configuración, el cliente recurre al DNS sin cifrar o la resolución se detiene.

Dado que DoH comparte el puerto 443 con el tráfico web, no es posible bloquear el puerto sin interrumpir el funcionamiento de HTTPS. Los equipos que bloquean direcciones conocidas de servidores DoH se encuentran con que los servidores nuevos o autohospedados siguen pasando, por lo que la lista requiere un mantenimiento continuo.

Algunos clientes vuelven a intentar la conexión a través de un DNS sin cifrar cuando no se puede acceder al servidor DoH. Los ingenieros que prueban una política pueden ver consultas en el puerto 53 y suponer que DoH está desactivado, cuando en realidad el cliente simplemente está utilizando su ruta alternativa.

Descubre cómo el DDI unificado simplifica las operaciones de red

Gestiona el DNS, el DHCP y las direcciones IP desde una única plataforma con automatización, visibilidad y control integrados.

Preguntas frecuentes sobre DoH

Términos relacionados

Network visualization showing IP addresses and interconnected nodes representing IPAM infrastructure and data flow

Establecimiento de modelos de flujo de trabajo y aprobación de IPAM regulados y preparados para auditorías para las redes de la organización

Descubre soluciones de gestión de direcciones IP para flujos de trabajo de IPAM regulados y preparados para auditorías. Habilita aprobaciones por ámbitos…

Read more
Content Hub

Comprender el modelo OSI: dónde encajan el DNS y el direccionamiento IP dentro de las 7 capas

Comprende las siete capas del modelo OSI y cómo encajan en ellas el DNS y el direccionamiento IP. Aprende los fundamentos de la arquitectura de redes con…

Read more
Fiber optic cables with glowing blue and cyan light points representing high-speed network data transmission and connectivity

Escalabilidad del DNS y la gestión de direcciones IP (IPAM) para redes empresariales IPv6 y de doble pila

Amplíe el DNS y el IPAM para redes empresariales de doble pila. Descubra cómo Micetro ayuda a los equipos a gestionar las migraciones a IPv6 con sistemas…

Read more
Hand holding digital pen interacting with holographic network diagrams and data visualization on laptop screen, representing

Integración de DNS, DHCP e IPAM en flujos de trabajo de infraestructura como código basados en Ansible y Git

La integración de DNS, DHCP e IPAM en los flujos de trabajo de IaC basados en Ansible y Git con Micetro convierte los cambios de direcciones y registros en…

Read more
Podcast

Podcast: Cómo la IA está cambiando el desarrollo de software empresarial

La IA transforma la automatización de redes, pero una implementación segura requiere sólidas prácticas de software, pruebas y experiencia en el ámbito…

Read more
Podcast

Podcast: Por qué las plataformas abiertas son importantes en las operaciones de red

Las plataformas abiertas y la arquitectura «API-first» permiten operaciones de red inteligentes, automatización y flujos de trabajo impulsados por IA en…

Read more
Network engineer reviewing LiveNX flow and telemetry data visualized across server racks in a hybrid multicloud environment

Obtenga respuestas a partir de los datos de LiveNX que ya tiene con LiveAssist

Descubre cómo LiveAssist, el complemento basado en IA para LiveNX, convierte tus datos de red en respuestas rápidas y guiadas, con un valor que podrás…

Read more
LiveWire GEN3 device offerings overview with descriptions of deep packet visibility and deployment options

Oferta de dispositivos LiveWire GEN3

BlueCat LiveWire es una plataforma de captura de paquetes y análisis forense de redes que ofrece una visibilidad profunda a nivel de paquetes en entornos…

Read more

Artículos relacionados