DNS sobre HTTPS: privacidad y controles del navegador
Comprende cómo DNS sobre HTTPS cambia el transporte DNS y qué pueden ver los proxies y resolutores.
Quieres la documentación estructurada de Red?
Este artículo forma parte de la biblioteca editorial. Para pasos de configuración, material de referencia y actualizaciones continuas, entra en la sección de docs.
DNS sobre HTTPS (DoH) envía las consultas DNS mediante HTTPS a un resolutor elegido, en lugar de usar siempre la ruta DNS sin cifrar. Esto puede reducir la exposición ante la red local que observa o modifica DNS, pero no vuelve anónima la navegación. El navegador, el sistema operativo, el proxy, el resolutor, el sitio de destino y la cuenta observan partes distintas de la solicitud.
Qué cambia con DoH
DNS tradicional suele usar UDP o TCP hacia el resolutor configurado por el sistema o la red. DoH transporta el intercambio dentro de HTTPS y puede usar un punto final elegido por el navegador, el sistema, un administrador o la persona usuaria. La guía DNS de MDN describe la resolución de nombres; DoH cambia el transporte y la relación con el resolutor, no la política del sitio.
La especificación RFC 8484 define la asignación HTTP para mensajes DNS. No exige que todos los navegadores expongan el mismo control ni que cada consulta use DoH. Puede existir una ruta del sistema, del proxy o de recuperación según la política y la disponibilidad.
Controles del navegador y elección
DoH es una decisión del navegador o del sistema, no un permiso de la página. Puede haber opciones automática, desactivada o de proveedor personalizado; una política empresarial puede controlar la selección; una red puede bloquear el punto final. La página no puede detectar ni cambiar esa decisión de forma fiable.
La documentación de Firefox y Chrome muestra controles específicos de cada proveedor. Sus valores predeterminados pueden cambiar. No presentes el nombre de un proveedor como prueba de que todas las conexiones y telemetría siguen la misma ruta. No pidas al usuario que infrinja una política administrada para completar una tarea distinta.
Límites entre proxy, resolutor y destino
Un proxy transporta solicitudes de aplicación; un resolutor responde consultas de nombres. Según la configuración, el navegador puede resolver mediante DoH antes de conectar al proxy, pedir al proxy que resuelva o usar el sistema como recuperación. El orden depende de la implementación y de la política.
El resolutor suele recibir el nombre consultado y metadatos necesarios para responder. El proxy ve la conexión que transporta y sus registros. El destino ve la solicitud que recibe, incluidas cabeceras y contexto de cuenta. HTTPS protege el tramo entre navegador y punto final DoH, pero no oculta el destino al propio destino ni elimina los registros del servicio. Una respuesta DNS no prueba identidad, ubicación ni intención.
Límites de privacidad y fallos
DoH puede reducir la exposición ante un observador DNS local, pero no impide que el resolutor conozca consultas, que el proxy conozca conexiones o que el sitio conozca su solicitud. Tampoco elimina cookies, almacenamiento, cuentas ni telemetría. No combines eventos DNS con señales ajenas para crear perfiles.
La resolución puede fallar por disponibilidad del punto final, política, certificados, portales cautivos o una red incompatible. Mantén la tarea utilizable, muestra un reintento claro y no cambies silenciosamente a un resolutor no aprobado. Un evento limitado como resolver-unavailable suele ser preferible a guardar el nombre consultado.
Revisión práctica
Documenta el resolutor, su responsable, la retención declarada y los navegadores probados. Verifica el proxy y el resolutor con dominios controlados por el equipo. Prueba estados administrados, personalizados, no disponibles y de recuperación sin recopilar historiales reales.
Los controles deben indicar si afectan al navegador, al perfil o al dispositivo administrado. Si la elección pertenece al administrador, muéstrala como solo lectura. Consulta la configuración de proxy de BotBrowser cuando el flujo use proxy. La promesa correcta es limitada: explicar la ruta, minimizar registros y mantener la tarea cuando cambie la política.
Para el contexto relacionado, consulta prevención de fugas DNS y coherencia entre proxy, DNS y WebRTC.
Elegir un resolutor con responsabilidad
La elección del resolutor también es una decisión de gobernanza. Compara la política operativa publicada, la retención declarada y el proceso de incidentes. El transporte cifrado no impide que el proveedor vea el nombre consultado.
Rutas de recuperación y pruebas
Define la recuperación antes del despliegue: un reintento, un mensaje claro y una alternativa documentada. Prueba puntos finales normales, no disponibles y administrados con dominios controlados por el equipo, sin guardar historiales reales.
Usa un resolutor que corresponda al propósito del perfil. Un perfil personal puede seguir la preferencia documentada; uno administrado puede exigir un punto final aprobado; y uno de prueba debe usar dominios controlados.
No elijas un proveedor solo porque dice «privado». Comprueba quién lo opera, qué conserva, su jurisdicción y cómo responde a incidentes; el cifrado de transporte no impide que vea la consulta.
Mantén separada la elección del proveedor de la identidad de la aplicación. Una página no debería exigir un resolutor concreto para iniciar sesión o revelar contenido salvo que exista un requisito revisado.
La configuración segura puede tener varias rutas: DoH, resolutor del sistema o una desactivación impuesta por el administrador. Las redes cautivas y los sistemas operativos pueden interceptar o centralizar DNS.
Define la recuperación aceptable antes de publicar. Una página pública puede reintentar y mostrar un estado sin conexión; un flujo sensible puede detenerse hasta recuperar el resolutor aprobado.
Nunca cambies silenciosamente a un punto final que la persona o el administrador no aprobaron. Documenta la decisión en lenguaje visible para el usuario.
Un cambio de navegador, certificado o política puede modificar la ruta sin cambiar el código. No guardes una suposición antigua en el perfil; recalcula al reiniciar o cuando cambie la política.
La plataforma web no ofrece una API portable que identifique qué resolutor respondió ni si DoH protegió una consulta. El éxito de una solicitud y sus tiempos no prueban el transporte.
Para soporte, solicita navegador y versión, estado del perfil o política, hora aproximada, error visible y un nombre controlado. No pidas el historial completo de nombres consultados.
Registra etapas separadas cuando hay proxy: una conexión puede fallar después de resolver, o el proxy puede resolver por cuenta del navegador. «Falló la conexión segura» no equivale a «el resolutor no respondió».
DoH es solo un control entre muchos. Cookies, almacenamiento, permisos, referentes, cuentas, registros y recursos de terceros también revelan contexto.
El contenido incrustado puede usar otra conexión y otras reglas de almacenamiento. No describas toda la página como «DNS privado» cuando solo está activo un ajuste del navegador.
Un informe de errores, captura o enlace de soporte puede revelar el nombre aun sin guardar el evento DNS. Permite solo campos necesarios, redacta nombres y elimina los datos al cerrar el incidente.
Prueba resultados, no promesas del proveedor: punto final normal, no disponible, política administrada, proxy con resolución propia y destino que falla.
Cada caso debe comprobar mensaje exacto, conservación de datos introducidos y siguiente acción clara, en las versiones de navegador y sistema realmente soportadas.
Usa dominios y puntos finales del equipo. Retrasa o cierra conexiones de prueba para observar la recuperación, excluye sus nombres de analíticas y elimina los registros después.
Revisa afirmaciones positivas y negativas. Una prueba no puede demostrar que una página identifique todos los resolutores ni que un tiempo de espera pruebe a un actor de red.
Preguntas frecuentes.
Escribe la decisión DoH donde usuarios y soporte puedan encontrarla: modo, equipo responsable, punto final aprobado y condiciones de recuperación.
Revisa esa política cuando cambien navegador, sistema, proxy o proveedor de red. Registra fecha y versiones probadas sin prometer comportamiento futuro idéntico.
Cuando exista un ajuste, usa una etiqueta clara: «Usar DNS seguro cuando esté disponible» no significa lo mismo que «Usar solo este proveedor».
Si la política es administrada, muestra el control como gestionado y dirige al canal de soporte. Un interruptor que aparenta funcionar pero se ignora es engañoso.
Mantén la recuperación proporcional: conserva los datos del formulario, limita los reintentos y ofrece una vía manual u offline cuando sea posible.
La documentación debe usar nombres propios de prueba y etapas redactadas. DoH protege un tramo de transporte, no todas las señales del navegador ni todas las conexiones.
¿DoH oculta mi IP? No. Cifra el intercambio DNS con el resolutor, pero el destino y el proxy pueden ver la IP de la conexión posterior.
¿Una página sabe si DoH está activo? No de forma fiable mediante una API web portable; el éxito de su propia solicitud no identifica el resolutor.
¿Un proxy es un resolutor DoH? No. El resolutor responde nombres y el proxy transporta conexiones, aunque puede resolver por el cliente.
¿Debe una aplicación exigir un resolutor? Solo si un requisito documentado y revisado lo hace necesario; en general debe explicar el fallo y respetar la política administrada.
Cuando falle DNS, soporte debe recoger etapa visible, versiones, estado autorizado de la política y hora de reproducción controlada, nunca un historial completo.
La configuración pertenece al navegador o al sistema, no a la página; una página no puede imponerla.
El resolutor, proxy y destino son observadores distintos y deben documentarse por separado.
La promesa de privacidad debe limitarse a la ruta protegida y no a anonimato total.
Una respuesta DNS no demuestra identidad, ubicación ni intención de la persona.
Los eventos de diagnóstico deben guardar una etapa y resultado, no el nombre consultado.
Fuentes
Artículos Relacionados
Lleva BotBrowser de la investigación a producción
Usa estas guías para entender el modelo y después avanzar hacia validación multiplataforma, contextos aislados y despliegue de navegador preparado para escalar.