DNS over HTTPS explicado: privacidad frente a filtrado de WiFi pública
DNS over HTTPS cifra las consultas dentro del tráfico del puerto 443. Descubra qué oculta, por qué puede eludir 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 resolutor, y se convirtió en un estándar de la IETF en 2018.
Ha habilitado el filtrado de contenidos en su WiFi de invitados, pero el navegador de un usuario sigue abriendo una categoría que pensaba que estaba bloqueada. El firewall está funcionando, la configuración de red parece correcta y otro dispositivo muestra la página de bloqueo esperada. La diferencia puede residir en a qué resolutor consulta el navegador, no en si su filtro funciona o no.
Para los operadores de recintos y responsables de TI, este es el problema central de DoH. Protege una búsqueda mientras viaja, pero la elección de destino del navegador también puede desplazar esa búsqueda fuera de la directiva de filtrado de su red.
Índice de contenidos
- Qué significa DNS over HTTPS en términos sencillos
- Cómo viaja una consulta DoH desde el dispositivo al resolutor
- Quién puede ver sus consultas cuando DoH está activado
- Por qué DoH debilita el filtrado DNS en redes WiFi compartidas
- Qué cuesta DoH en términos de velocidad y qué sigue haciendo el filtrado
- Compruebe y cambie DoH en dispositivos habituales
- Elija y organice en capas sus controles de DoH
Qué significa DNS over HTTPS en términos sencillos
DNS over HTTPS, que habitualmente se abrevia como DoH, transmite preguntas y respuestas DNS a través de una conexión web encriptada. Un resolver DNS es el servicio al que un dispositivo consulta para traducir un nombre de dominio en una dirección de red.
Piense en el DNS como en 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 suele enviar esa pregunta en un formato legible.
Una postal es una analogía útil: cualquiera que la tenga en la mano puede leer el mensaje. DoH pone la pregunta en un sobre sellado y la transporta dentro del mismo tipo de furgoneta de reparto 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. Esto 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.
Comparación 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 los 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 resolutor puede descifrar una solicitud DoH entrante, aplicar una directiva de contenido o amenazas y devolver su respuesta de forma segura. Las preguntas importantes son quién opera ese resolutor y qué directiva sigue.
Tenga a mano esta comparación cuando revise 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 la página de reservas de un hotel, a menos que ya tenga esa respuesta guardada en la caché.
Este diagrama sigue la búsqueda desde el navegador hasta el resolvedor y de vuelta.
Siga la solicitud y la respuesta
El navegador necesita una dirección. Comprueba si ya tiene una respuesta útil para el sitio de reservas. Un acierto en la caché puede evitar por completo una nueva búsqueda, por lo que la red local no verá un intercambio de DNS para esa acción.
Crea una pregunta DNS. Si necesita una respuesta nueva, el navegador prepara una consulta que contiene el nombre de dominio. En este punto, la pregunta sigue dentro del dispositivo, no viaja a través de la WiFi.
Selecciona el resolutor DoH. El navegador prepara una solicitud HTTPS para su resolutor 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 temporización y tamaño.
El resolutor devuelve la respuesta. El resolutor procesa la pregunta y coloca la respuesta DNS dentro de una respuesta HTTP cifrada. La red puede ver cómo el tráfico regresa desde el resolutor, pero no el contenido legible de la respuesta.
El navegador se conecta al sitio web. Utiliza la dirección devuelta para iniciar la conexión con el sitio web. La red local puede observar ese nuevo destino, algo que 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 sobre qué hace una búsqueda DNS separa el proceso de localización de direcciones de la propia conexión al sitio web.
Identifique el punto de filtrado
Para una conexión nueva que requiere resolución DNS, la búsqueda se produce antes de que se cargue el contenido de la página. Esto da a un resolutor autorizado 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 otra parte. El resolvedor del recinto no recibe entonces ninguna consulta que evaluar.
El vídeo 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 DNS frente a observadores ordinarios entre el dispositivo y el resolver elegido, pero dicho resolver debe leer la pregunta para responderla.
Esa distinción es importante 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 se siguen aplicando.
DoH cambia en quién confía para la actividad DNS; no elimina la necesidad de confiar en alguien.
Separe la visibilidad de 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 DNS cuando se utiliza DoH
| Observador | Ve los nombres de dominio | Ve que se está usando DoH | Por qué es importante |
|---|---|---|---|
| Otros dispositivos en la misma WiFi | No, no desde la búsqueda cifrada | Rara vez mediante el acceso ordinario entre pares | La lectura pasiva del mensaje DNS está bloqueada |
| Red del establecimiento o ISP | No, no dentro del intercambio DoH | A menudo, a través del tráfico a una dirección de solucionador conocida | Los controles DNS locales no pueden evaluar las consultas enviadas a otra parte |
| Sitios web que visita | Solo el sitio al que se conecta | No solo por la conexión al sitio web | Un sitio no recibe sus consultas DNS no relacionadas |
| Operador del solucionador DoH | Sí, cada consulta que recibe | Sí | Una conexión directa expone esas consultas junto con su dirección de origen |
| Proveedor del navegador o sistema operativo | Solo si opera el solucionador 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 resolver no ve necesariamente cada búsqueda realizada por el dispositivo. Otra aplicación puede utilizar un resolver 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. El funcionamiento del resolver, la configuración del software y la recogida de telemetría son funciones independientes.
Haga explícita la decisión de confianza
Para instalaciones gestionadas de Firefox, la documentación sobre la directiva de DNS over HTTPS de Mozilla proporciona controles para la configuración del resolutor y si los usuarios pueden modificarla. Es una forma práctica de alinear el comportamiento del navegador con la gobernanza de DNS de la organización.
Un recinto o un ISP aún pueden observar las direcciones de destino, los tiempos 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 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 del navegador.
- Lea los términos de retención. Compruebe qué información de consultas y conexiones se almacena, durante cuánto tiempo y con qué finalidad.
- Verifique la jurisdicción y el acceso. Comprenda dónde procesa la información el operador y quién puede obtenerla.
- Adapte la visibilidad a 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 DNS elegida ofrece a los usuarios la confidencialidad adecuada mientras permite que la organización cumpla con sus responsabilidades declaradas.
Por qué DoH debilita el filtrado DNS en WiFi compartido
Un hotel ofrece a sus huéspedes el número de recepción para ayudarles a encontrar servicios locales. La mayoría de los huéspedes llaman a recepción, pero otro huésped utiliza una app de directorio en su lugar. Recepción puede controlar sus propias recomendaciones, pero no las respuestas que proporciona esa app.
El DNS de la red funciona de forma 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 elusión está en la ruta
El problema no es que una consulta cifrada nunca se pueda filtrar. Es que su filtro no puede aplicar la directiva a una consulta que nunca recibe.
En la red WiFi de invitados de un centro de ocio familiar, esto podría significar que el bloqueo de contenido para adultos no se aplique a un navegador determinado. En la red del personal, una aplicación maliciosa podría resolver un dominio de comando y control a través de un resolver no autorizado.
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 solucionador aprobada.
- Restricciones de búsqueda. La aplicación de Búsqueda segura basada en DNS se puede omitir, aunque aún se pueden aplicar restricciones a nivel de cuenta o punto de acceso.
- Bloqueo de amenazas. Un filtro 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 informa de la telemetría de Firefox en la que aproximadamente el 13,91 % de los 9,54 billones de intercambios en escritorio utilizaron DoH durante 2025. También describe un conjunto de datos de medición en el que DoH fue aproximadamente 6,4 veces más frecuente que DoT.
Esas observaciones no establecen la proporción de dispositivos que eluden el filtro de su recinto. Los valores predeterminados del navegador, el despliegue regional, la compatibilidad del resolver y las directivas del administrador influyen en si DoH está activo.
Compruebe la cobertura en lugar de darla por sentada
Un bloqueo correcto en el portátil de un empleado no demuestra una cobertura equivalente en el teléfono personal de un invitado. Los dispositivos pueden utilizar diferentes navegadores, ajustes 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 traen sus visitantes.
El filtrado basado únicamente en el resolutor proporcionado por la red ya no ofrece una cobertura completa por defecto. Necesita controles complementarios y un recuento honesto de lo que queda fuera de la directiva.
Lo que cuesta DoH en velocidad y lo que el filtrado sigue haciendo
El cifrado añade trabajo, pero la cuestión 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 costes diferentes, por lo que probar una sola solicitud nueva puede ofrecer una imagen engañosa.
Una comparación empírica de transportes DNS registró respuestas de UDP y TLS por debajo de 1 milisegundo en su línea base local sin retardo, mientras que HTTP/2 se mantuvo de forma constante por debajo de los 10 milisegundos; los resultados a continuación conservan el contexto experimental del estudio en lugar de predecir el rendimiento en las instalaciones.
Latencia de búsqueda DNS por protocolo en el estudio citado
| Protocolo | Resultado notificado | Contexto |
|---|---|---|
| UDP | Inferior a 1 ms | Línea base local sin retardo |
| TLS | Inferior a 1 ms | Línea base local sin retardo |
| HTTP/2 | Inferior a 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 de segmentación (pipelining) |
| DoH público frente a DNS tradicional | Más lento por nombre | No se ha observado un aumento significativo en el tiempo total de carga de la página |
Mida la sesión, no solo el handshaking
Las conexiones persistentes permiten a un cliente distribuir los costes de configuración entre consultas posteriores. La multiplexación le permite gestionar múltiples intercambios sin establecer una conexión segura independiente para cada pregunta.
El filtrado DNS aún puede rechazar un dominio antes de que comience una nueva conexión, siempre que la solicitud llegue al resolver de filtrado. El bloqueo de anuncios y rastreadores puede reducir las solicitudes posteriores, pero la encriptación por sí sola no elimina los anuncios ni acelera una página.
Rastree las señales operativas que revelan problemas reales:
- Fallos en la negociación (handshake). Busque errores en la configuración de la conexión y reintentos.
- Tasas de acierto en caché. Separe las respuestas almacenadas en caché de la resolución nueva.
- Tiempo de respuesta del resolvedor. Mida el comportamiento durante sesiones concurrentes con gran afluencia de invitados.
- Comportamiento de alternancia (fallback). Compruebe si los fallos hacen que los dispositivos dejen de resolver nombres 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 de fallos de forma conjunta, no como comprobaciones de aceptación independientes.
Un punto de extremo del resolutor cercano y resistente 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 realista.
Compruebe y cambie DoH en dispositivos habituales
La configuración de un navegador puede explicar por qué los dispositivos en la misma red WiFi se comportan de forma diferente. Las etiquetas de los menús cambian entre versiones, por lo que debe utilizar el buscador de la Configuración si la ruta indicada 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. Compruebe 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, incluidos 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 gestionada 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 comprobación independiente.
- iOS y macOS: Inspeccione los perfiles de configuración instalados, los ajustes de gestión de dispositivos y las aplicaciones relacionadas con DNS. Un perfil de DNS cifrado puede funcionar de forma independiente del navegador.
Verifique la ruta efectiva
Una VPN de sistema puede transportar 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é resolver recibe una búsqueda de prueba reciente desde el navegador o la app real. Utilice diagnósticos del navegador o una prueba de identificación de resolver junto con registros de resolveres aprobados, en lugar de confiar únicamente en la pantalla de configuración.
Seleccione y aplique por capas sus controles de DoH
Aplique controles por capas según la propiedad del dispositivo y la necesidad de directiva. Los portátiles gestionados del personal pueden seguir una configuración obligatoria; los teléfonos personales de los invitados, por lo general, no. Aplicar las mismas restricciones a ambos grupos genera brechas evitables o interrupciones innecesarias.
Puede permitir DoH externo y aceptar una visibilidad reducida del DNS local, restringirlo y asumir riesgos de compatibilidad, o combinar la directiva de dispositivos gestionados con controles selectivos para la red de invitados. El enfoque por capas le proporciona una visión más clara de lo que está protegido y lo que no.
Asigne cada control a su ámbito real
Los controles de red son útiles, pero no hacen que todos los resolvers cifrados sean identificables. Un resolver privado, una dirección cambiante o un túnel VPN pueden anular las suposiciones basadas en una lista de servicios habituales.
Controles para DoH en redes compartidas y gestionadas
| Control | Qué detiene | Dónde se aplica | Compromiso / Desventaja |
|---|---|---|---|
| Bloquear el puerto de salida 853 | DNS over TLS en puerto estándar | Firewall o puerta de enlace | No hace nada contra DoH sobre HTTPS ordinario |
| Forzar el puerto 53 al resolutor de red | Bypass de DNS sin cifrar | Aplicación en puerta de enlace, admitida mediante configuración DHCP | Ignora DoH por completo; DHCP por sí solo no fuerza el cumplimiento |
| Bloquear direcciones de resolutores DoH públicos conocidos | Conexiones a resolutores en listas | Firewall o puerta de enlace compatible | Las listas quedan obsoletas, aparecen nuevos resolutores y algunas aplicaciones dejan de funcionar |
| Desactivar DoH en el navegador mediante directiva administrada | Bypass a nivel de navegador en los navegadores cubiertos | Portátiles administrados y dispositivos del personal | No puede alcanzar a los teléfonos personales en la WiFi de invitados |
| Forzar el resolutor de red a través de MDM | Cambios de DNS no autorizados cubiertos por la directiva de dispositivos | Dispositivos corporativos y del personal registrados | Requiere registro y compatibilidad de plataforma; los invitados quedan fuera |
| Aceptar DoH y filtrar en el punto de conexión | Nada en el lado de la red | Solo puntos de conexión administrados | Los dispositivos de invitados quedan fuera de la directiva de puntos de conexión |
Bloquear la dirección de un resolutor 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 exhaustivo y permanente.
Si necesita un control que vaya más allá de la resolución de dominios, evalúe una secure web gateway junto con políticas de red y de puntos finales. Revise detenidamente los requisitos de despliegue, especialmente cuando los dispositivos no sean propiedad de la organización.
Elabore una política operativa comprobable
Empiece por el servicio que necesita prestar. Una red de administración para el personal, una conexión de biblioteca pública y un espacio para actividades infantiles pueden requerir de forma razonable restricciones y explicaciones distintas para los usuarios.
Utilice esta lista de comprobación de despliegue:
- Enumere las políticas requeridas. Identifique los SSID, las VLAN y los grupos de dispositivos que necesitan controles de contenido o filtrado de amenazas, y asigne un responsable a cada uno.
- Separe los dispositivos gestionados del BYOD de invitados. Registre dónde se pueden aplicar las políticas 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 solucionador aprobado. Cubra ambas familias de direcciones de red admitidas.
- Aplique la política de navegador gestionado. Configure la ruta DNS aprobada y evite modificaciones no autorizadas por parte de los usuarios en los equipos del personal.
- Mantenga las restricciones del solucionador en la red de invitados. Revise periódicamente las direcciones del solucionador bloqueadas, pruebe las excepciones y elimine las reglas que causen bloqueos colaterales inaceptables.
- Publique un aviso para invitados en un lenguaje claro. Explique qué categorías se filtran, qué información de red se registra y las restricciones sobre el uso de DNS cifrado o VPN.
- Pruebe un dispositivo real en cada red. Verifique los sitios permitidos, las categorías bloqueadas, los destinos de prueba de seguridad aprobados, los fallos del solucionador y el comportamiento de la VPN.
Antes del lanzamiento: Una página de bloqueo demuestra que una solicitud concreta fue filtrada, no que todas las aplicaciones del dispositivo sigan la misma ruta.
Haga que el DNS cifrado forme parte de las pruebas de aceptación
Para utilizar Shield, debe apuntar el DNS de la red hacia Shield. Respondemos a cada búsqueda DNS en la red que protegemos, en cada dispositivo, sin nada en el dispositivo que se pueda desactivar; por lo tanto, las rutas de túnel y resolutores externos deben incluirse en el diseño de protección de la red.
Antes de probar Purple Shield, nuestro experto le mostrará cómo gestiona su red las VPN y el DNS encriptado. Utilice esa conversación para establecer qué solicitudes llegan a la ruta DNS protegida, qué controles la aplican y qué ocurre cuando un dispositivo intenta utilizar otra ruta.
Establezca criterios de aceptación antes de cambiar el acceso de invitados. Un resolver aprobado, un proceso de excepciones documentado y pruebas de dispositivos repetibles ofrecen una base más sólida que asumir que un filtro habilitado lo ve todo.
Purple Shield ofrece DNS de protección, filtrado de contenidos, defensa contra amenazas y bloqueo de publicidad sin necesidad de instalar agentes en los dispositivos de los invitados. Visite Purple Shield para organizar una reunión previa a la prueba sobre sus SSID, políticas de filtrado y cómo gestiona su red los DNS cifrados y las VPN.