La pregunta y cuándo aplica
Esta pregunta aparece en entrevistas de redes, seguridad, backend, SRE e ingeniería de preventa. Una respuesta sólida trata a DNS over HTTPS (DoH) como un límite de protocolo y no como "DNS con un certificado". DoH transporta una consulta y una respuesta DNS dentro de un intercambio HTTPS. El transporte oculta la consulta a un observador normal en la ruta entre el cliente y el resolver DoH, pero el resolver aún la recibe y puede registrarla o filtrarla. La elección depende de quién debe ver el DNS, qué controles de políticas se requieren y si el cliente puede comunicarse con el resolver de manera confiable.
Qué evalúa el entrevistador
- Si puede separar la semántica de los mensajes DNS del estado HTTP y el comportamiento del transporte.
- Si establece con claridad el límite de privacidad: el cifrado hacia el resolver elegido no equivale a anonimato.
- Si comprende GET frente a POST, el tipo de contenido, el comportamiento de la caché y el bootstrap.
- Si compara DoH, DoT y el DNS común según el responsable del despliegue, la observabilidad, la latencia y las políticas.
- Si define mecanismos de contingencia (fallback) y pruebas en lugar de afirmar que el cifrado mejora automáticamente todos los resultados.
Preguntas para aclarar primero
Pregunte quién controla los clientes y los resolvers, si debe mantenerse aplicable una política corporativa de filtrado o auditoría, si la red bloquea HTTPS saliente o DNS sobre UDP/TCP, y si el objetivo es la confidencialidad frente a la red local, el acceso a la API a nivel de aplicación o la resistencia a la manipulación. Aclare si las consultas serán emitidas por navegadores, resolvers del sistema operativo o un agente administrado. Pregunte también sobre el presupuesto de latencia, portales cautivos, nombres split-horizon, validación DNSSEC, retención de registros y el fallback aceptable cuando el resolver seleccionado no esté disponible. Estas respuestas pueden favorecer un resolver administrado por la empresa, un cliente DoH a nivel de aplicación, DoT o DNS convencional.
Estructura para una respuesta de 30 segundos
DoH asigna cada par de consulta-respuesta DNS a una solicitud y respuesta HTTPS, normalmente utilizando el formato wire de DNS con el tipo de medio application/dns-message. Cifra el salto del cliente al resolver y puede atravesar redes que permiten HTTPS, pero el resolver sigue viendo la consulta y la política puede requerir un endpoint aprobado. GET puede ser favorable para la caché; POST evita colocar la consulta codificada en la URL y es preferible para solicitudes sensibles. Yo elegiría DoH ante un requisito explícito de privacidad o de API, lo compararía con DoT cuando importen un resolver administrado y una clara separación de transporte, y definiría el bootstrap, el almacenamiento en caché, el comportamiento de split-DNS, el fallback, la minimización de telemetría y las pruebas antes del despliegue.
Análisis detallado paso a paso
1. Mapear las capas del protocolo
La pregunta DNS sigue siendo un mensaje DNS. La RFC 8484 asigna un par de consulta-respuesta a un intercambio HTTP y define application/dns-message para la representación binaria. HTTPS proporciona confidencialidad e integridad TLS para la conexión, mientras que HTTP proporciona métodos, códigos de estado, reutilización de conexiones y controles de caché. Un NXDOMAIN o SERVFAIL de DNS sigue siendo un código de respuesta DNS; puede llegar dentro de una respuesta HTTP 2xx. Un HTTP 4xx o 5xx significa que el intercambio HTTP falló y no contiene la respuesta DNS original, por lo que el cliente debe aplicar el manejo de fallas de HTTP por separado.
2. Elegir deliberadamente entre GET, POST y el almacenamiento en caché
La RFC 8484 exige que un servidor DoH admita tanto GET como POST para el tipo de medio de la RFC. GET coloca un mensaje DNS codificado en Base64URL en el parámetro de consulta dns, lo que puede mejorar la reutilización de la caché HTTP común, pero también hace que la consulta sea visible en los registros de URL, intermediarios y el historial del navegador, a menos que esas superficies estén controladas. POST transporta el mensaje binario en el cuerpo con el tipo de contenido. Para nombres sensibles, prefiera POST o una ruta GET cuidadosamente controlada, minimice los encabezados y asegúrese de que las cachés no puedan inventar una frescura que entre en conflicto con la política de TTL de DNS. Google expone un endpoint RFC 8484 y un endpoint JSON independiente; son contratos de API diferentes.
3. Definir los límites de privacidad y políticas
DoH evita que un observador local lea paquetes DNS en texto plano en el salto protegido, pero el resolver aún puede ver la consulta, los metadatos del cliente, los tiempos y el contexto de política elegido. HTTPS no valida la respuesta DNS por sí mismo; el comportamiento DNSSEC del resolver y el modelo de confianza del cliente siguen siendo relevantes. Una empresa administrada puede necesitar un resolver aprobado, filtrado por categorías, zonas split-horizon, controles de retención y evidencia de auditoría. Permitir que cada aplicación seleccione un resolver público arbitrario puede eludir esos controles, incluso si el tráfico está cifrado.
4. Manejar el bootstrap, las fallas y el fallback
El cliente debe descubrir la dirección del servidor DoH antes de poder resolver ese servidor a través del mismo servicio. El bootstrap puede utilizar IPs configuradas, un resolver de confianza u otro canal de aprovisionamiento; cada ruta necesita validación y rotación de certificados. Trate los errores HTTP, los errores de respuesta DNS, los tiempos de espera, la intercepción por portal cautivo y la denegación por políticas como resultados distintos. La caída de un resolver puede recurrir a un transporte aprobado, pero un fallback silencioso a un resolver no confiable puede violar la privacidad o las políticas empresariales. Registre qué resolver y transporte respondieron sin retener el contenido completo de la consulta por defecto.
5. Comparar las opciones de despliegue y verificarlas
El DNS tradicional es simple y visible para el operador de red, pero el transporte en texto plano expone las consultas en la ruta. DoT cifra DNS en un servicio TLS dedicado y a menudo resulta sencillo para un resolver a nivel de sistema operativo. DoH integra DNS en HTTPS y puede aprovechar la infraestructura HTTP existente, las APIs del navegador y la accesibilidad del puerto 443, a costa de una mayor complejidad en las políticas y observabilidad de la capa HTTP. Verifique la elección mediante capturas de paquetes en una prueba controlada, registros de estado HTTP y DNS del lado del resolver, comportamiento de aciertos de caché y TTL, casos de split-DNS, fallas de DNSSEC, portales cautivos, caídas del resolver, rotación de certificados y políticas de fallback. Mida p50/p95/p99 de resolución, clases de fallas y fugas de consultas en lugar de limitarse solo a la latencia promedio.
Ejemplo de una respuesta sólida
DoH es un protocolo que coloca una consulta y respuesta DNS dentro de un intercambio HTTPS. El mensaje DNS conserva su significado normal; HTTPS protege el salto entre el cliente y el resolver seleccionado, y HTTP proporciona métodos, códigos de estado, reutilización de conexiones y comportamiento de caché. Por lo tanto, un NXDOMAIN de DNS puede transportarse en una respuesta HTTP 2xx, mientras que un HTTP 5xx es una falla de transporte o de servicio sin una respuesta DNS. Yo usaría DoH cuando necesite acceso a nivel de aplicación o confidencialidad frente a una red local y pueda designar un resolver aprobado. Preferiría POST para nombres sensibles, minimizaría encabezados y mantendría explícitas las políticas del resolver, el manejo de DNSSEC, las zonas split-horizon y la retención. El bootstrap debe realizarse mediante una resolución configurada o de confianza, y el fallback debe permanecer dentro de la política aprobada. Antes del despliegue, probaría la semántica de caché y TTL, la exposición de registros de URL para GET, portales cautivos, rotación de certificados, caída del resolver, errores de DNSSEC y si los paquetes o registros revelan consultas fuera del resolver previsto.
Errores comunes
- Decir "HTTPS hace que el DNS sea anónimo" → el resolver seleccionado sigue viendo la consulta y los metadatos → especifique el salto protegido exacto y el límite de confianza del resolver.
- Tratar un
NXDOMAINde DNS como un error HTTP → los códigos de respuesta DNS pueden ir dentro de HTTP 2xx → analice las capas de estado HTTP y DNS por separado. - Elegir GET para datos secretos sin considerar los registros de URL → la consulta codificada puede quedar en el historial o en registros de intermediarios → use POST o una política controlada de caché y registro.
- Afirmar que DoH siempre supera a DoT → el responsable del despliegue, las políticas, la accesibilidad y la observabilidad difieren → compare primero el entorno concreto.
- Hacer bootstrap del hostname de DoH a través del mismo resolver sin resolver → el cliente cae en una dependencia circular → aprovisione una dirección o una ruta de bootstrap de confianza.
- Recurrir a cualquier resolver público tras un tiempo de espera → se pueden eludir la confidencialidad y el filtrado corporativo → restrinja el fallback a transportes y endpoints aprobados.
- Medir únicamente la latencia promedio → las caídas, los fallos de caché y las fugas quedan ocultos → segmente p95/p99, clases de fallas, comportamiento de TTL e identidad del resolver.
Preguntas de seguimiento y respuestas
¿Valida DoH que la respuesta DNS sea auténtica?
No. TLS autentica el servidor HTTPS seleccionado por el cliente. La autenticidad de la respuesta DNS depende del comportamiento de validación del resolver y de la confianza del cliente en dicho resolver; DNSSEC y HTTPS son cuestiones independientes. El diseño debe registrar si se requiere validación y cómo se expone una falla de validación.
¿Por qué un HTTP 200 puede contener una búsqueda DNS fallida?
El intercambio HTTP fue exitoso y transportó un mensaje DNS válido. El mensaje DNS puede incluir NXDOMAIN, SERVFAIL u otro código de respuesta DNS. El cliente debe analizar ambas capas y evitar reintentar una respuesta negativa válida de DNS como si la solicitud HTTP hubiera fallado.
¿Cuándo es DoT una mejor opción?
DoT es una excelente opción cuando un sistema operativo o un resolver empresarial controla el transporte, desea un puerto DNS dedicado y una política de red sencilla, y no necesita APIs HTTP orientadas al navegador. DoH es preferible cuando el requisito es la accesibilidad HTTPS existente o APIs a nivel de aplicación. La decisión se basa en la propiedad y las políticas, no en una regla general de que "lo cifrado siempre es mejor".
¿Qué debería suceder cuando el resolver DoH es inaccesible en un portal cautivo?
Detectar el portal o fallas repetidas de TLS/HTTP, detener la amplificación de reintentos y seguir la política configurada: usar un fallback aprobado, pausar la resolución con una vía de recuperación visible para el usuario o usar temporalmente el DNS proporcionado por la red solo cuando la política lo permita. Pruebe esto antes del despliegue, ya que un fallback a ciegas puede filtrar todas las consultas.