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.
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.
- 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.
- 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.
- 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».
- 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.
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.