Explicación de DNS sobre HTTPS: Privacidad vs. Filtrado de WiFi público
DNS sobre HTTPS cifra las búsquedas dentro del tráfico del puerto 443. Descubra qué oculta, por qué puede omitir el filtrado de WiFi y cómo las redes mantienen el control.
Published 26 de octubre de 2026
DNS over HTTPS envía búsquedas DNS dentro del tráfico HTTPS habitual en el puerto 443, cifrado entre el dispositivo y el resolvedor, y se convirtió en un estándar de la IETF en 2018.
Ha habilitado el filtrado de contenido en su WiFi de invitados, pero el navegador de un invitado aún abre una categoría que pensaba que había bloqueado. El firewall está funcionando, la configuración de la red se ve correcta y otro dispositivo recibe la página de bloqueo esperada. La diferencia puede ser a qué resolvedor le consulta el navegador, no si su filtro está funcionando o no.
Para los operadores de instalaciones y líderes de TI, ese es el problema central con DoH. Protege una búsqueda mientras viaja, pero la elección del destino por parte del navegador también puede desplazar esa búsqueda fuera de la política de filtrado de su red.
Tabla de contenido
- Lo que significa DNS over HTTPS en términos sencillos
- Cómo viaja una consulta DoH desde el dispositivo hasta el resolutor
- Quién puede ver sus consultas cuando DoH está activado
- Por qué DoH debilita el filtrado DNS en redes WiFi compartidas
- Lo que cuesta DoH en velocidad y lo que aún hace el filtrado
- Consulte y cambie DoH en dispositivos comunes
- Elija y aplique en capas sus controles DoH
Qué significa DNS over HTTPS en términos sencillos
DNS over HTTPS, generalmente abreviado como DoH, transporta preguntas y respuestas de DNS a través de una conexión web cifrada. Un resolutor de DNS es el servicio al que un dispositivo le pide traducir un nombre de dominio en una dirección de red.
Piense en el DNS como una guía telefónica. Antes de abrir una conexión, una aplicación necesita una dirección, aunque es posible que ya tenga una respuesta útil en su caché. El DNS tradicional comúnmente envía esa pregunta en forma legible.
Una postal es una analogía útil: cualquiera que la maneje puede leer el mensaje. DoH coloca la pregunta en un sobre sellado y la lleva dentro del mismo tipo de camioneta de entrega que se utiliza para el tráfico web seguro habitual.
Compare el transporte, no solo el cifrado
DNS over TLS, o DoT, también sella el sobre, pero utiliza una entrada de entrega etiquetada por separado. Eso hace que su tráfico sea más fácil de identificar para un operador de red por su puerto de destino.
El RFC 8484 de la IETF, publicado en octubre de 2018, define el intercambio HTTPS de DoH, utilizando habitualmente el puerto 443, a diferencia del DNS tradicional en el puerto 53.
Comparativa entre DNS tradicional, DNS over TLS y DNS over HTTPS
| Función | DNS tradicional | DNS over TLS (DoT) | DNS over HTTPS (DoH) |
|---|---|---|---|
| Transporte | UDP o TCP | TLS | HTTPS |
| Puerto habitual | 53 | 853 | 443 |
| Legible por la red local | Sí | No | No |
| Fácil de detectar por puerto | Sí | Sí | No, comparte el puerto 443 con el tráfico web |
| Fácil de bloquear por puerto | Sí | Sí | No, no de forma selectiva solo por puerto |
| Definido en | Especificaciones originales de DNS | Especificación de DNS over TLS | RFC 8484 |
Bloquear un puerto DNS dedicado es sencillo. Bloquear el puerto utilizado por sitios web seguros también detendría el tráfico web legítimo, por lo que DoH requiere controles más selectivos.
El cifrado no decide qué se filtra. Un resolvedor puede descifrar una solicitud DoH entrante, aplicar una política de contenido o de amenazas y devolver su respuesta de forma segura. Las preguntas importantes son quién opera ese resolvedor y qué política sigue.
Tenga a la mano esta comparación al revisar los controles. Una regla que gestiona el DNS tradicional o DoT no gestiona automáticamente DoH.
Cómo viaja una búsqueda DoH desde el dispositivo hasta el resolvedor
Un mensajero necesita una dirección antes de entregar un paquete. De forma similar, un navegador necesita una dirección de destino antes de poder conectarse a una página de reserva de hotel, a menos que ya tenga esa respuesta en caché.
Este diagrama sigue la búsqueda desde el navegador hasta el resolvedor y de regreso.
Siga la solicitud y la respuesta
El navegador necesita una dirección. Verifica si ya tiene una respuesta útil para el sitio de reservaciones. Un acierto en la caché puede evitar completamente una nueva búsqueda, por lo que la red local no verá un intercambio de DNS para esa acción.
Construye una pregunta de DNS. Si necesita una respuesta nueva, el navegador prepara una consulta que contiene el nombre de dominio. En este punto, la pregunta todavía está dentro del dispositivo y no viaja a través de la WiFi.
Selecciona el resolvedor de DoH. El navegador prepara una solicitud HTTPS para su resolvedor configurado. La red local puede observar la dirección de destino y los metadatos de la conexión, pero no puede leer directamente el dominio dentro del mensaje DNS cifrado.
Establece o reutiliza una conexión segura. Si es necesario, el dispositivo completa un saludo TLS antes de enviar la solicitud protegida. Con una conexión HTTP persistente, las consultas posteriores pueden reutilizar esa conexión; la red ve el tráfico cifrado, incluyendo su hora y tamaño.
El resolvedor devuelve la respuesta. El resolvedor procesa la pregunta y coloca la respuesta DNS dentro de una respuesta HTTP cifrada. La red puede ver el tráfico que regresa del resolvedor, no el contenido legible de la respuesta.
El navegador se conecta al sitio web. Utiliza la dirección devuelta para iniciar la conexión al sitio web. La red local puede observar ese nuevo destino, lo cual es independiente de leer la pregunta DNS anterior.
Para obtener más detalles sobre el almacenamiento en caché y la resolución, la explicación de lo que hace una búsqueda de DNS separa el proceso de búsqueda de direcciones de la conexión al sitio web en sí.
Identifique el punto de filtrado
Para una nueva conexión que requiere resolución DNS, la búsqueda se realiza antes de que se cargue el contenido de la página. Esto le da al resolvedor aprobado la oportunidad de rechazar un destino bloqueado antes de que el navegador se conecte.
Un navegador configurado de forma independiente puede enviar esa decisión a otro lugar. El resolvedor de las instalaciones no recibe ninguna consulta que evaluar.
El video adjunto ofrece otra forma de seguir el proceso.
Quién puede ver sus búsquedas cuando DoH está activado
DoH no oculta la navegación a todo el mundo. Protege el intercambio de DNS contra observadores comunes entre el dispositivo y el resolvedor elegido, pero ese resolvedor debe leer la pregunta para responderla.
Esa distinción importa en redes WiFi compartidas. Un invitado puede desear razonablemente protección contra la intercepción local, mientras que un hospital o una escuela necesitan la seguridad de que sus controles de protección y amenazas sigan aplicándose.
DoH cambia en quién confía para la actividad de DNS; no elimina la necesidad de confiar en alguien.
Separe la visibilidad del DNS de la visibilidad de navegación
La tabla describe el uso ordinario de DoH sin un retransmisor de privacidad adicional, VPN o sistema de intercepción. Leer un mensaje DNS e inferir un destino a partir de otra actividad de la red son capacidades diferentes.
Quién puede ver las búsquedas de DNS cuando se utiliza DoH
| Observador | Ve nombres de dominio | Ve que se está usando DoH | Por qué es importante |
|---|---|---|---|
| Otros dispositivos en la misma red WiFi | No, no desde la búsqueda cifrada | Rara vez mediante el acceso ordinario de pares | La lectura pasiva del mensaje DNS está bloqueada |
| Red del establecimiento o del ISP | No, no dentro del intercambio DoH | A menudo, a través del tráfico a una dirección de resolvedor conocida | Los controles de DNS locales no pueden evaluar las consultas enviadas a otra parte |
| Sitios web que visita | Solo el sitio al que se conecta | No solo desde la conexión del sitio web | Un sitio no recibe sus consultas de DNS no relacionadas |
| Operador del resolvedor DoH | Sí, cada consulta que recibe | Sí | Una conexión directa expone esas consultas junto con su dirección de origen |
| Proveedor de navegador o SO | Solo si opera el resolvedor o recibe telemetría relevante | El software conoce su modo configurado; los informes del proveedor requieren telemetría | La configuración del software no es lo mismo que la visibilidad automática del proveedor |
El resolvedor no ve necesariamente cada búsqueda realizada por el dispositivo. Otra aplicación puede usar un resolvedor diferente y las respuestas almacenadas en caché pueden no requerir ninguna consulta. Solo ve las solicitudes que se le envían.
Del mismo modo, el proveedor del navegador no recibe automáticamente el historial de DNS solo por suministrar el navegador. La operación del resolvedor, la configuración del software y la recopilación de telemetría son funciones independientes.
Haga explícita la decisión de confianza
Para instalaciones administradas de Firefox, la documentación de políticas de DNS sobre HTTPS de Mozilla proporciona controles para la configuración del resolvedor y permite definir si los usuarios pueden cambiarla. Esa es una forma práctica de alinear el comportamiento del navegador con la gobernanza de DNS de una organización.
Es posible que un lugar o ISP aún observe las direcciones de destino, el tiempo de conexión y los volúmenes de tráfico. Otros metadatos del protocolo también pueden ayudar a identificar un sitio, por lo que una consulta de DNS cifrada no es una promesa de navegación anónima.
Utilice una breve evaluación de confianza antes de aprobar un resolvedor:
- Identifique al operador. Establezca qué organización recibe las consultas, en lugar de confiar en la etiqueta predeterminada de un navegador.
- Lea los términos de retención. Verifique qué información de consultas y conexiones se almacena, durante cuánto tiempo y con qué propósito.
- Compruebe la jurisdicción y el acceso. Entienda dónde procesa la información el operador y quién puede obtenerla.
- Alinee la visibilidad con la responsabilidad. Decida qué eventos de seguridad debe investigar su equipo de TI y qué detalles de navegación no se deben conservar.
La pregunta útil no es si la privacidad o la capacidad de gestión importan más en abstracto. Es si la ruta de DNS elegida otorga a los usuarios la confidencialidad adecuada mientras permite a la organización cumplir con sus responsabilidades establecidas.
Por qué DoH debilita el filtrado de DNS en redes WiFi compartidas
Un hotel da a sus huéspedes el número de recepción para ayudar a encontrar servicios locales. La mayoría llama a la recepción, pero otro huésped usa una aplicación de directorio. La recepción puede controlar sus propias recomendaciones, no las respuestas entregadas por esa aplicación.
El DNS de la red funciona de manera similar. Su red proporciona un resolvedor, pero un navegador con su propia configuración DoH puede realizar la consulta a un servicio externo en su lugar.
La ilustración muestra esa ruta alternativa alrededor de la mesa de DNS de la red.
La evasión está en la ruta
El problema no es que una consulta cifrada nunca se pueda filtrar. Es que su filtro no puede aplicar una directiva a una consulta que nunca recibe.
En la red de invitados de una atracción familiar, eso podría significar que el bloqueo de contenido para adultos no se aplique a un navegador en particular. En una red de empleados, una aplicación maliciosa podría resolver un dominio de comando y control a través de un resolutor no aprobado.
Las consecuencias dependen de qué controles se basen en DNS:
- Políticas específicas de la red. Las reglas asignadas a un SSID o VLAN no regirán las consultas enviadas fuera de la ruta del resolvedor aprobado.
- Restricciones de búsqueda. El cumplimiento de Safe Search basado en DNS se puede omitir, aunque aún se pueden aplicar restricciones a nivel de cuenta o de punto de enlace.
- Bloqueo de amenazas. Un filtro de DNS no puede rechazar una búsqueda no vista, incluso si su lista de amenazas contiene el dominio solicitado.
Un estudio de medición sobre el despliegue de DNS cifrado reporta telemetría de Firefox en la que aproximadamente el 13.91% de 9.54 billones de handshakes en computadoras de escritorio usaron DoH durante 2025. También describe un conjunto de datos de medición en el que DoH fue aproximadamente 6.4 veces más prevalente que DoT.
Esas observaciones no establecen la proporción de dispositivos que eluden el filtro de su establecimiento. Los valores predeterminados del navegador, la implementación regional, la compatibilidad del resolvedor y las políticas del administrador influyen en si DoH está activo.
Pruebe la cobertura en lugar de darla por sentada
Un bloqueo exitoso en la computadora portátil de un empleado no demuestra una cobertura equivalente en el teléfono personal de un invitado. Los dispositivos pueden usar diferentes navegadores, configuraciones de DNS o túneles.
Trate su filtro de contenido WiFi como un control con una ruta de tráfico definida. Pruebe esa ruta utilizando los dispositivos y aplicaciones que sus visitantes traen consigo.
El filtrado basado únicamente en el resolvedor proporcionado por la red ya no ofrece una cobertura completa por defecto. Requiere controles de soporte y una evaluación honesta de lo que queda fuera de la directiva.
Lo que cuesta DoH en velocidad y lo que el filtrado aún logra
El cifrado agrega trabajo, pero la pregunta práctica es si los usuarios notan una sesión más lenta. La configuración inicial de la conexión y las búsquedas repetidas tienen costos diferentes, por lo que probar una sola solicitud nueva puede dar una imagen engañosa.
Una comparación empírica de transportes DNS reportó respuestas de UDP y TLS por debajo de 1 milisegundo en su línea base local sin retraso, mientras que HTTP/2 se mantuvo consistentemente por debajo de los 10 milisegundos; los resultados a continuación conservan el contexto experimental del estudio en lugar de predecir el rendimiento en el establecimiento.
Latencia de búsqueda de DNS por protocolo en el estudio citado
| Protocolo | Resultado reportado | Contexto |
|---|---|---|
| UDP | Menos de 1 ms | Línea base local sin retraso |
| TLS | Menos de 1 ms | Línea base local sin retraso |
| HTTP/2 | Menos de 10 ms, de forma constante | La reutilización de conexiones y la multiplexación ayudan a reducir la sobrecarga |
| HTTP/1.1 | Fluctúa sustancialmente | Atribuido a los límites del pipelining |
| DoH público frente a DNS tradicional | Más lento por nombre | No se observó un aumento significativo en el tiempo total de carga de la página |
Mida la sesión completa, no solo la negociación
Las conexiones me persistentes permiten que un cliente distribuya los costos de configuración entre las consultas posteriores. La multiplexación le permite manejar múltiples intercambios sin establecer una conexión segura independiente para cada pregunta.
El filtrado de DNS aún puede rechazar un dominio antes de que comience una nueva conexión, siempre que la solicitud llegue al resolutor de filtrado. El bloqueo de anuncios y rastreadores puede reducir las solicitudes posteriores, pero el cifrado por sí solo no elimina los anuncios ni acelera una página.
Dé seguimiento a las señales operativas que revelan problemas reales:
- Fallos de negociación (handshake). Busque errores en la configuración de la conexión y reintentos.
- Tasa de aciertos en caché. Separe las respuestas en caché de la resolución nueva.
- Tiempo de respuesta del resolvedor. Mida el comportamiento durante sesiones concurrentes de invitados de alta demanda.
- Comportamiento de alternancia (fallback). Verifique si las fallas hacen que los dispositivos dejen de resolver o cambien a otra ruta sin previo aviso.
Regla práctica: Pruebe la navegación, la aplicación de políticas y la recuperación ante fallas en conjunto, no como verificaciones de aceptación independientes.
Un punto de enlace del resolvedor cercano y resiliente es un mejor punto de partida que elegir un protocolo basándose únicamente en suposiciones de latencia. Confirme el resultado en su red bajo una carga real.
Verifique y cambie DoH en dispositivos comunes
La configuración de un navegador puede explicar por qué los dispositivos en la misma red WiFi se comportan de manera diferente. Las etiquetas del menú cambian entre versiones, por lo que debe usar la búsqueda de Configuración si la ruta a continuación no está visible.
Inspeccione el navegador y el sistema operativo
- Chrome: Abra Configuración, Privacidad y seguridad, Seguridad y, a continuación, Usar DNS seguro. Verifique si sigue al proveedor actual o si especifica otro servicio.
- Firefox: Abra Ajustes, Privacidad & seguridad y, a continuación, DNS sobre HTTPS. Revise el modo de protección, incluyendo Desactivado, Protección predeterminada o Protección máxima, así como el resolvedor seleccionado.
- Edge: Abra Configuración, Privacidad, búsqueda y servicios, Seguridad y, a continuación, Usar DNS seguro. La directiva administrada puede bloquear esta configuración.
- Android: Abra Ajustes, Red e internet y, a continuación, DNS privado. Esta configuración utiliza DoT en lugar de DoH; el DNS seguro a nivel de navegador requiere una verificación independiente.
- iOS y macOS: Inspeccione los perfiles de configuración instalados, la configuración de gestión de dispositivos y las aplicaciones relacionadas con DNS. Un perfil de DNS cifrado puede funcionar de manera independiente del navegador.
Verifique la ruta efectiva
Una VPN del sistema puede transportar el DNS a través de su propio túnel, independientemente de la configuración del navegador. Compruebe también si una aplicación proporciona un servicio DNS cifrado independiente.
Confirme qué resolutor recibe una nueva búsqueda de prueba desde el navegador o la aplicación real. Utilice diagnósticos del navegador o una prueba de identificación del resolutor junto con los registros de resolutores aprobados, en lugar de confiar únicamente en la pantalla de configuración.
Elija y aplique sus controles DoH por capas
Aplique controles por capas según la propiedad del dispositivo y la necesidad de la política. Las laptops administradas del personal pueden seguir una configuración forzada; los teléfonos personales de los invitados generalmente no pueden. Aplicar las mismas restricciones a ambos grupos crea brechas evitables o fallas innecesarias.
Puede permitir DoH externo y aceptar una visibilidad reducida del DNS local, restringirlo y aceptar riesgos de compatibilidad, o combinar la política de dispositivos administrados con controles selectivos para la red de invitados. El enfoque por capas le brinda una visión más clara de lo que está protegido y lo que no.
Asigne cada control a su alcance real
Los controles de red son útiles, pero no hacen que todos los resolvedores cifrados sean identificables. Un resolvedor privado, un cambio de dirección o un túnel VPN pueden anular las suposiciones basadas en una lista de servicios conocidos.
Controles para DoH en redes compartidas y administradas
| Control | Lo que detiene | Dónde se aplica | Desventaja |
|---|---|---|---|
| Bloquear puerto saliente 853 | DNS over TLS en puerto estándar | Firewall o gateway | No hace nada contra DoH sobre HTTPS ordinario |
| Forzar puerto 53 al resolvedor de red | Bypass de DNS sin cifrar | Aplicación en gateway, respaldada por configuración DHCP | Ignora DoH por completo; DHCP por sí solo no fuerza el cumplimiento |
| Bloquear direcciones conocidas de resolvedores DoH públicos | Conexiones a resolvedores en la lista | Firewall o gateway compatible | Las listas se vuelven obsoletas, aparecen nuevos resolvedores, algunas aplicaciones fallan |
| Deshabilitar DoH del navegador mediante directiva administrada | Bypass a nivel de navegador en los navegadores cubiertos | Laptops administradas y dispositivos del personal | No puede alcanzar teléfonos personales en la WiFi de invitados |
| Forzar resolvedor de red a través de MDM | Cambios de DNS no autorizados cubiertos por la directiva del dispositivo | Dispositivos corporativos y del personal inscritos | Requiere inscripción y soporte de plataforma; los invitados quedan fuera |
| Aceptar DoH y filtrar en el endpoint | Nada en el lado de la red | Solo endpoints administrados | Los dispositivos de invitados permanecen fuera de la directiva de endpoint |
Bloquear la dirección de un resolvedor también puede bloquear servicios no relacionados alojados en esa misma dirección. Evite tratar la categoría de DNS cifrado de un firewall como un inventario permanente y exhaustivo.
Si necesita un control más allá de la resolución de dominios, evalúe un secure web gateway junto con las políticas de red y de endpoints. Revise cuidadosamente los requisitos de implementación, especialmente cuando los dispositivos no son propiedad de la organización.
Cree una política operativa verificable
Comience con el servicio que necesita ofrecer. Una red de administración de personal, la conexión de una biblioteca pública y un espacio de actividades infantiles pueden necesitar razonablemente diferentes restricciones y diferentes explicaciones para los usuarios.
Utilice esta lista de verificación de implementación:
- Enumere las políticas requeridas. Identifique los SSIDs, VLANs y grupos de dispositivos que necesitan controles de contenido o filtrado de amenazas, y asigne un responsable a cada uno.
- Separe los dispositivos administrados del BYOD de invitados. Registre dónde se puede aplicar la política del navegador o MDM y dónde solo están disponibles los controles de red.
- Cierre las rutas habituales de omisión de DNS. Cuando su política lo requiera, bloquee el DoT saliente y restrinja el DNS tradicional al resolvedor aprobado. Cubra ambas familias de direcciones de red compatibles.
- Aplique la política de navegador administrado. Configure la ruta de DNS aprobada y evite modificaciones no autorizadas por parte del usuario en el equipo del personal.
- Mantenga las restricciones del resolvedor de la red de invitados. Revise periódicamente las direcciones del resolvedor bloqueadas, pruebe las excepciones y elimine las reglas que causen un bloqueo colateral inaceptable.
- Publique un aviso en lenguaje sencillo para los invitados. Explique qué categorías se filtran, qué información de la red se registra y las restricciones sobre el uso de VPN o DNS cifrado.
- Pruebe un dispositivo real en cada red. Verifique los sitios permitidos, las categorías bloqueadas, los destinos de prueba de seguridad aprobados, las fallas del resolvedor y el comportamiento de la VPN.
Antes del lanzamiento: Una página de bloqueo demuestra que una solicitud específica fue filtrada, no que todas las aplicaciones del dispositivo sigan la misma ruta.
Incorpore el DNS cifrado a las pruebas de aceptación
Para usar Shield, debe apuntar el DNS de la red hacia Shield. Respondemos a cada búsqueda de DNS en la red que protegemos, en cada dispositivo, sin nada que se pueda desactivar en el dispositivo; por lo tanto, las rutas de resolvedores externos y túneles deben incluirse en el diseño de protección de la red.
Antes de probar Purple Shield, nuestro experto le mostrará cómo maneja su red las VPN y el DNS cifrado. Utilice esa conversación para establecer qué solicitudes llegan a la ruta de DNS protegida, qué controles la aplican y qué sucede cuando un dispositivo intenta utilizar otra ruta.
Establezca criterios de aceptación antes de cambiar el acceso de invitados. Un resolvedor aprobado, un proceso de excepción documentado y pruebas de dispositivos repetibles proporcionan una base más sólida que asumir que un filtro habilitado lo ve todo.
Purple Shield ofrece DNS de protección, filtrado de contenido, defensa contra amenazas y bloqueo de anuncios sin instalar agentes en los dispositivos de los invitados. Visite Purple Shield para organizar una charla previa a la prueba sobre sus SSID, políticas de filtrado y cómo su red maneja el DNS cifrado y las VPN.