DNS over HTTPS, abreviado DoH, envía consultas del sistema de nombres de dominio a través de una conexión HTTPS. La búsqueda «DNS over HTTPS» aparece a menudo cuando alguien quiere saber si su proveedor de internet, la red wifi o una aplicación puede ver qué dominios consulta. DoH cifra el trayecto entre el cliente y el servidor DoH, pero no hace anónimo todo el tráfico ni oculta las direcciones IP a los sitios visitados.
En una red de empresa, activar DoH sin planificarlo puede romper el filtrado, el acceso a dominios internos o la supervisión de incidentes. Antes de habilitarlo, decide quién resolverá las consultas, qué políticas rigen en los dispositivos y cómo se mantendrán los nombres internos. El objetivo es elegir un sistema de DNS que proteja el transporte y siga siendo administrable.
DNS over HTTPS y la consulta DNS tradicional
Cuando una aplicación necesita conectarse a un nombre de dominio, solicita al sistema una dirección IP. El cliente DNS consulta un servidor que puede devolver un registro A para IPv4, un AAAA para IPv6 u otros tipos de registro. Con DNS tradicional por UDP o TCP, la consulta no se cifra por defecto en el tramo entre el dispositivo y el resolver; alguien con capacidad para observar esa red podría verla o manipularla.
DoH encapsula cada pregunta y respuesta DNS en una solicitud HTTP enviada por una conexión HTTPS. El uso de TLS protege el intercambio frente a la lectura o modificación durante el transporte entre cliente y servidor. El servidor DoH sigue viendo las consultas que recibe y puede aplicar sus propias políticas. La privacidad depende, por tanto, de la confianza en el resolver y de cuánto tiempo conserva los datos.
DoH no equivale a una VPN. Una VPN crea un túnel para más tráfico de red, mientras que DoH protege las consultas DNS que usan ese resolver. Tampoco oculta a la web de destino la dirección IP desde la que te conectas ni cifra los datos de una aplicación que no use HTTPS.
Qué protege y qué no protege DoH
DoH dificulta que un observador local de la red lea directamente las consultas DNS. También ayuda a reducir ciertos ataques que modifican una respuesta DNS en tránsito, siempre que el cliente autentique el servidor correcto. Es una protección de transporte entre dos extremos, no una garantía de que las páginas a las que te conectas sean seguras.
El servidor de DoH puede conocer los dominios consultados y asociar las consultas con una dirección IP u otros datos de conexión. Un sistema de control parental o una empresa podría necesitar una política que permita bloquear dominios maliciosos, proteger a usuarios o cumplir sus reglas internas. Cambiar a un resolver público sin revisar la política puede enviar esos datos a otra organización y eludir controles de red.
DoH tampoco sustituye DNSSEC. DNSSEC aporta mecanismos para validar la autenticidad de datos DNS; DoH cifra la consulta en tránsito. Los dos protocolos resuelven problemas distintos y pueden coexistir. Un canal HTTPS no demuestra por sí solo que la respuesta DNS sea correcta si no se valida su origen.
| Tecnología | Qué aporta | Qué no garantiza |
| DNS tradicional | Resuelve nombres usando consultas DNS conocidas | La consulta suele viajar sin cifrar en redes no confiables |
| DNS over HTTPS | Transporta la consulta DNS dentro de HTTPS | No oculta la consulta al resolver ni anonimiza la navegación completa |
| DNS over TLS | Cifra el tráfico DNS en una conexión TLS dedicada | No cifra el resto de aplicaciones ni evita que el resolver registre consultas |
| DNSSEC | Permite validar autenticidad e integridad de datos DNS firmados | No cifra por sí mismo la consulta DNS |
| VPN | Crea un túnel cifrado para el tráfico definido por el cliente | No impide que el servicio final conozca los datos que recibe |
DoH en una red de empresa
Las empresas suelen usar DNS para localizar servidores internos, aplicar filtros web, registrar consultas y detectar dominios asociados a malware. Si un navegador activa su propio DoH y consulta un servidor externo, puede dejar de usar el resolver de la red. El usuario podría perder acceso a intranets o sortear una política de bloqueo sin que el equipo de seguridad lo vea en sus registros habituales.
Antes de desplegar DoH, inventaría qué sistemas pueden resolver nombres: Windows, navegadores, aplicaciones, agentes de seguridad, VPN y dispositivos móviles. Comprueba si las políticas de administración central permiten fijar un resolver, desactivar cambios del usuario o redirigir consultas a un servicio aprobado. No asumas que todos los navegadores obedecen la misma configuración del sistema operativo.
Prueba nombres internos, dominios divididos por VPN, aplicaciones antiguas y redes de invitados. Algunas empresas usan “split DNS”: una consulta obtiene respuestas diferentes según si el usuario está dentro o fuera de la red. Un resolver externo puede no conocer la zona interna y devolver NXDOMAIN o una dirección incorrecta.
Configura la supervisión antes de activar el cambio. Registra qué dispositivos usan DoH, a qué resolver se conectan y qué ocurre si el servicio no está disponible. Define cómo bloquear una configuración no autorizada y cómo permitir excepciones justificadas. Las políticas deben ser compatibles con las leyes de protección de datos y los acuerdos de privacidad aplicables.
DoH en navegadores y dispositivos personales
Algunos navegadores ofrecen una opción de DNS seguro. Según el sistema, el navegador puede usar el resolver del sistema, un proveedor predeterminado o una dirección elegida por el usuario. La disponibilidad y el comportamiento cambian por versión, región y configuración. Lee la documentación de cada navegador antes de asumir qué consulta está cifrada.
En un portátil de empresa, la política corporativa puede administrar el navegador y bloquear cambios. En un móvil personal conectado a la wifi de la oficina, el usuario puede usar una aplicación o una configuración privada que ignore el DNS de la red. Las normas internas deben explicar qué se administra y respetar la privacidad del dispositivo del trabajador.
Si activas DoH en casa, elige un proveedor con política de privacidad transparente y comprueba sus opciones de filtrado, registro y soporte DNSSEC. Una conexión cifrada no significa que el proveedor no guarde datos. Evita confundir la palabra “privado” en una aplicación con la ausencia de registros.
Cómo evaluar un proveedor DoH
Comprueba quién opera el servicio, en qué país procesa las consultas y qué política publica sobre conservación y uso de datos. Revisa si admite DNSSEC, si ofrece protección contra dominios maliciosos y si permite configurar filtros. Lee las condiciones directamente del proveedor, porque una aplicación puede cambiar su proveedor sin avisarte.
Considera disponibilidad, latencia, continuidad, privacidad y facilidad para cambiar de resolver. No elijas solo por velocidad. Un servicio que responde rápido pero registra o reutiliza las consultas de una manera que no encaja con tu política puede no ser adecuado para una organización.
En empresas, define quién puede aprobar un nuevo resolver y qué criterio se usa para bloquearlo. Conserva la posibilidad de investigar fallos sin guardar más datos personales de los necesarios. El diseño de registros debe equilibrar seguridad, privacidad y cumplimiento.
Errores habituales al desplegar DNS cifrado
Un error frecuente es habilitar DoH solo en el navegador, sin entender que el sistema operativo y otras aplicaciones pueden seguir usando DNS tradicional. Otra confusión consiste en creer que todas las consultas del dispositivo pasan por el resolver DoH cuando algunas redes, aplicaciones o VPN establecen rutas distintas.
También puede fallar la resolución de dominios internos, el descubrimiento de impresoras o las herramientas de gestión remota. Si el usuario comunica que “internet funciona, pero no abre la intranet”, revisa primero qué resolver atendió el nombre y si la VPN estaba conectada.
Evita desplegar una política de bloqueo sin un grupo piloto y un plan de reversión. Cambia una variable cada vez, recoge errores y valida las aplicaciones críticas. Una solución de DNS cifrado debe mantener acceso y seguridad, no provocar interrupciones que lleven a desactivar todos los controles.
Qué revisar cuando una conexión falla
Si una página deja de abrir después de activar DoH, compara la resolución con el resolver corporativo y con el configurado en el navegador. Comprueba si el dominio es interno, si depende de una VPN o si la aplicación utiliza su propio cliente DNS. No concluyas que el servidor web está caído hasta saber qué dirección resolvió el equipo.
En una red híbrida, los nombres privados pueden existir solo en el DNS local. Un resolver público no conoce esas zonas y puede responder que el nombre no existe. La solución puede consistir en configurar reglas de resolución específicas, mantener el DNS gestionado por la organización o permitir que solo ciertos dominios se resuelvan por una ruta interna.
DoH también puede interferir con filtros que inspeccionan consultas DNS sin cifrar. Antes de bloquearlo por completo, define qué necesidad cubre, qué usuarios y dispositivos se administran y qué política de privacidad se comunica. Una excepción de red mal documentada puede ser más difícil de mantener que una configuración DoH gobernada.
Cuando el resolver no responde, algunos clientes recurren a DNS tradicional y otros muestran un error. Valida el comportamiento de cada navegador y sistema operativo. Registra cómo se desactiva la configuración de emergencia y quién autoriza ese cambio.
Preguntas frecuentes sobre DNS over HTTPS
DNS over HTTPS hace anónima la navegación
No. Cifra la consulta DNS entre el cliente y el resolver, pero el resolver sigue viendo el dominio solicitado. Los sitios visitados y otros intermediarios pueden conocer información de la conexión.
DoH sustituye a una VPN
No. DoH protege las consultas DNS que se envían al resolver. Una VPN cubre el tráfico que se incluya en su túnel, aunque tampoco vuelve anónimo todo el uso de internet.
DoH y DNSSEC hacen lo mismo
No. DoH cifra el transporte DNS; DNSSEC valida la autenticidad de datos DNS firmados. Se pueden usar a la vez porque resuelven necesidades distintas.
Por qué una empresa puede bloquear DoH
Puede necesitar que los equipos usen un resolver gestionado para acceder a nombres internos, aplicar controles y registrar incidentes. La decisión debe documentarse y respetar las políticas de privacidad.
DoH mejora siempre la velocidad
No. El rendimiento depende del resolver, la red, el caché y la ruta. En algunos casos mejora la respuesta; en otros añade latencia o genera incompatibilidades.
El proveedor DoH puede ver mis consultas
Sí. El proveedor recibe las solicitudes que procesa. Revisa su política de privacidad, el periodo de conservación, el uso de datos y las opciones de protección antes de confiarle las consultas.
DNS over HTTPS mejora la privacidad del transporte DNS, pero requiere decidir en quién confías para resolver nombres y cómo convive con los controles de red. En una empresa, prueba primero los dominios internos, las VPN y las aplicaciones antes de cambiar la política para todos los equipos.
Haz la prueba con equipos que representen los casos de uso reales: una estación dentro de la oficina, un portátil conectado por VPN y un dispositivo móvil. Guarda el resolver elegido, los dominios de prueba y el resultado. Así puedes distinguir un problema de DNS de una caída del servicio o de una ruta de red.