DNS privado: qué protege y qué no cambia en tu conexión

Cifrado, proveedor y privacidad explicados sin confundirlos con una navegación anónima.

Por Rafael Garcia
Ilustración conceptual de DNS privado: una consulta entre dispositivo y resolutor pasa por un candado que simboliza el cifrado

En la Wi-Fi de un hotel escribes la dirección de una web y el navegador necesita averiguar a qué servidor conectarse. Esa consulta se llama DNS. Si viaja sin cifrar, alguien situado entre tu dispositivo y el servidor de nombres puede observarla o intentar alterarla. Activar «DNS privado» protege esa pregunta y su respuesta durante una parte concreta del trayecto. No oculta automáticamente el resto de la conexión ni convierte tu navegación en anónima.

La distinción importa porque «DNS privado» no designa una única casilla universal. Firefox y Chrome ofrecen DNS sobre HTTPS (DoH) dentro del navegador; Android llama DNS privado a su ajuste del sistema, basado en DNS sobre TLS (DoT). Un router puede limitarse a cambiar de servidor DNS sin cifrar la consulta. Conviene empezar por la necesidad real: impedir que una red local lea o modifique tus consultas, escoger quién las resuelve o mantener una política de filtrado familiar. Cada objetivo pide comprobar algo distinto.

Ilustración de cabecera: elaboración propia de Gaia Genius Hub a partir de las especificaciones RFC 8484 y RFC 7858. Simboliza la consulta cifrada entre dispositivo y resolutor; la conexión posterior con la web no está dibujada.

La pregunta que ocurre antes de abrir una página

Una dirección como www.example.org es legible para nosotros; para iniciar la conexión se necesita una dirección de red. El dispositivo puede tener la respuesta en caché o preguntar a un resolutor DNS. Este busca o recupera la respuesta y la devuelve. No toda apertura de una página genera una nueva consulta: la caché, las aplicaciones y las conexiones ya abiertas cambian el recorrido. El ejemplo sirve para entender el mecanismo, no para deducir el historial exacto de una persona a partir de una sola captura de tráfico.

La consulta tradicional suele circular en claro por el tramo que une el dispositivo con el resolutor. RFC 8484 define cómo llevar preguntas y respuestas DNS dentro de HTTPS; RFC 7858 describe cómo transportarlas mediante TLS. Ambos cifran ese intercambio y autentican el servidor bajo las condiciones de su configuración. Así se reduce la posibilidad de que un observador de la red lea el nombre consultado directamente en el paquete DNS o sustituya la respuesta en tránsito. No cambia por sí solo el nombre solicitado ni impide que el resolutor elegido lo conozca.

Después de recibir la dirección, el navegador conecta con la web. Ahí entra en juego otra protección: HTTPS cifra la comunicación con el sitio cuando la conexión se establece correctamente. El DNS cifrado y HTTPS se ocupan de etapas distintas. Tener uno activado no corrige la falta del otro. Por eso, si una página presenta una advertencia de certificado o usa HTTP sin cifrar, cambiar de DNS no arregla esa exposición.

Dos trayectos desde el dispositivo: la consulta DNS cifrada hacia el resolutor y la conexión HTTPS posterior hacia el sitio
El cifrado DNS protege la pregunta al resolutor; la conexión posterior con la web tiene sus propias garantías. Diagrama: Gaia Genius Hub, elaborado a partir de RFC 8484 y RFC 7858.

Qué mejora la privacidad y qué sigue siendo visible

En una red ajena, DoH o DoT dificultan que quien controla la Wi-Fi o un observador del trayecto lea el contenido de la consulta DNS dirigida al resolutor configurado. También dificultan modificar esa respuesta sin que el cliente detecte un problema con la conexión cifrada. Ese es un beneficio concreto y valioso; la ayuda oficial de Android lo resume con un límite tajante: DNS privado protege preguntas y respuestas DNS, nada más.

El resolutor sigue recibiendo el dominio que se pregunta. En el DoH normal, también puede ver la dirección IP de origen de la conexión, como explica el RFC 9230 al describir la variante experimental Oblivious DoH. Elegir un resolutor externo traslada confianza: tu proveedor de acceso deja de recibir directamente esas consultas en claro, pero la organización que resuelve las preguntas puede procesarlas según sus propias condiciones. No es sensato tratar «cifrado» y «sin registro» como sinónimos.

La red de acceso todavía transporta conexiones hacia direcciones IP; según cómo estén configurados otros protocolos, el destino puede inferirse por esas direcciones u otras señales de tráfico. El sitio que visitas también recibe una conexión y los datos que le envíes, y puede utilizar cookies o una cuenta iniciada para reconocerte. El DNS privado no oculta tu identidad a una web donde has iniciado sesión, no cifra un formulario HTTP y no borra el historial del navegador. Si necesitas evaluar un servicio que también cambia la ruta de la conexión, conviene revisar por separado qué promete y qué condiciones tiene una VPN; una VPN tampoco equivale por sí sola a anonimato.

Hay otro límite menos visible: DoH protege el tramo cliente–resolutor, no garantiza que todas las comunicaciones del resolutor con el resto de la infraestructura DNS estén cifradas. El manual técnico de Microsoft lo explicita para un servidor DoH con reenvíos o zonas tradicionales. Al evaluar la protección, hay que describir el tramo concreto y no dibujar un túnel cifrado desde el teléfono hasta cada servidor de Internet.

DoH, DoT, DNSSEC y VPN resuelven preguntas diferentes

DoH usa HTTPS y DoT usa TLS como transporte para las consultas DNS. La diferencia práctica para un lector no es decidir cuál «gana» en abstracto, sino saber qué opción ofrece su dispositivo o aplicación, a qué resolutor la envía y si admite volver a una conexión sin cifrar cuando algo falla. RFC 8484 considera que ambos transportes aportan protección semejante frente a la lectura de consultas en el trayecto.

Cuatro mecanismos que suelen confundirse
Mecanismo Qué protege principalmente Qué no promete
DoH / DoT El transporte de la consulta y respuesta DNS entre cliente y resolutor. Anonimato ante el resolutor ni cifrado del resto del tráfico.
DNSSEC La autenticidad de respuestas DNS de zonas firmadas, si se valida correctamente. Ocultar el dominio consultado durante el transporte.
HTTPS del sitio La comunicación del navegador con esa web, tras validar su conexión. Cifrar automáticamente una consulta DNS tradicional previa.
VPN El tráfico entre el dispositivo y el servidor VPN, según su configuración. Eliminar la necesidad de confiar en otro proveedor o impedir seguimiento en sitios web.

El RFC 8484 separa expresamente DoH de DNSSEC: el primero da seguridad al transporte, mientras DNSSEC permite validar datos firmados. Pueden coexistir. Una VPN, por su parte, altera la ruta y quién ve determinados tramos; hay que leer su política y comprobar por dónde resuelve DNS. No hay una «combinación mágica» que arregle errores de privacidad de todas las aplicaciones.

Elegir resolutor también es elegir una política de datos

Antes de escribir un nombre de proveedor en la configuración, comprueba quién lo opera, qué datos dice recoger, durante cuánto tiempo, si aplica filtrado y qué sucede con los nombres locales de tu red. No copies una dirección de una lista anónima solo porque prometa rapidez. Cloudflare declara para su resolutor público 1.1.1.1 que no utiliza los datos personales de ese servicio para publicidad, que trunca determinadas direcciones y que elimina registros limitados dentro de 25 horas. Es una política publicada por el proveedor, no una medición hecha por Gaia ni una garantía para cualquier otro producto de Cloudflare. Su índice de políticas separa incluso el resolutor público del servicio prestado a Firefox y de su aplicación de consumo.

Un resolutor puede ofrecer bloqueo de malware o filtros familiares; otro puede priorizar no alterar respuestas. Si en casa se usa una política de control parental o en una empresa hay nombres internos, activar un resolutor externo desde un navegador puede saltarse esa política o dejar sin resolver servicios privados. Mozilla explica por qué su modo predeterminado detecta algunas VPN, controles parentales, políticas empresariales y señales de red. El RFC 8484 también advierte de que resolutores distintos pueden responder de forma diferente en redes con DNS dividido. No transformes un fallo de la intranet en una razón automática para desactivar toda la protección: identifica primero qué componente resuelve cada nombre.

La velocidad merece una prueba de tu conexión y tus aplicaciones; no se deduce de la publicidad ni de un único cronómetro. Las respuestas pueden proceder de cachés y la distancia a los servidores varía. En esta guía no hemos medido proveedores ni afirmamos que uno sea el más rápido. Al cambiar, conserva la configuración anterior para poder revertirla y observa si funcionan los nombres locales, la conexión de invitados y los servicios que usa tu familia.

Mapa de alcance: el ajuste del navegador afecta a ese navegador; el del sistema cubre consultas que usan su resolutor; el router no obliga a todas las aplicaciones a seguirlo
La capa donde configuras DNS determina el alcance; aplicaciones y redes pueden utilizar rutas distintas. Diagrama: Gaia Genius Hub, elaborado con documentación de Mozilla, Android y Cloudflare.

Cómo configurarlo sin confundir navegador, sistema y router

Firefox: mira el nivel de protección y su estado real

En Firefox de escritorio, Mozilla sitúa DNS sobre HTTPS en Ajustes → Privacidad y seguridad → DNS sobre HTTPS. La interfaz permite elegir niveles de protección y muestra si la función está activa. El modo predeterminado puede volver al resolutor de la red si hay problemas o señales que desaconsejan saltar una política local; por tanto, «activado» no equivale siempre a «cifrado en todas las consultas». El nivel máximo avisa si no puede utilizar DNS seguro, aunque admite excepciones que deben entenderse caso por caso. Si necesitas una exigencia estricta, revisa esas diferencias antes de cambiar el selector.

Chrome: automático y proveedor personalizado no fallan igual

La ayuda de Chrome para ordenador ubica «Usar DNS seguro» en Configuración → Privacidad y seguridad → Seguridad. En modo automático, Chrome puede volver a una consulta sin cifrar si el servicio tiene un problema; con un proveedor personalizado, según esa documentación, no hace ese cambio silencioso y puede mostrar un error de resolución. La función puede no estar disponible en dispositivos administrados o con control parental. Esta diferencia es más importante que el nombre comercial del proveedor: decide si prefieres continuidad de conexión o que el fallo sea visible.

Android: «DNS privado» es un ajuste del sistema

En Android, Google indica que el camino habitual es Ajustes → Red e Internet → DNS privado, con opciones desactivado, automático o nombre de proveedor. Si el fabricante mueve el menú, busca «DNS privado» en los ajustes. La documentación de Android identifica esta función con DNS sobre TLS. El nombre de proveedor debe ser el hostname que ese servicio documente para DoT, no una URL DoH con https:// ni una dirección IP elegida al azar. El ajuste del sistema puede convivir con aplicaciones que gestionan sus propias consultas; por eso no afirmamos que controle todo lo que sale del teléfono.

Router: cambiar de servidor DNS no significa cifrar

Muchos routers permiten repartir a los equipos de casa una dirección DNS distinta. Eso decide a quién preguntar, pero no demuestra que la pregunta salga cifrada. En su guía de routers, Cloudflare separa la introducción de direcciones IP del apartado específico para DoT en routers compatibles. Consulta el manual del modelo y busca una opción expresa de DoH o DoT; si solo ves «DNS primario/secundario», no llames privado a ese cambio. Y recuerda que un navegador con DoH propio puede elegir un resolutor diferente al del router. Si te interesa renovar el equipo por otros motivos, nuestra guía sobre WiFi 7 y cambio de router aborda una decisión distinta: la norma inalámbrica tampoco acredita cifrado DNS.

Comprobarlo y actuar cuando algo deja de funcionar

La primera verificación es mirar la interfaz del componente que configuraste. Firefox muestra un estado de DoH activo, no activo o apagado; Mozilla explica qué significa cada uno. Comprueba después una web habitual y un nombre interno que realmente necesites, si existe. Una página que carga no prueba por sí sola que DNS esté cifrado, porque el modo automático puede haber recurrido al resolutor tradicional o a una respuesta en caché.

Si configuraste específicamente 1.1.1.1, Cloudflare propone su página de comprobación, que informa de si ese dispositivo llega a su resolutor y por qué protocolo. Es una comprobación de ese servicio y ese dispositivo, no una auditoría universal de todas las aplicaciones. Si escogiste otro proveedor, usa su diagnóstico documentado. No hemos realizado una prueba de red en tu móvil, navegador o router.

Cuando una web o un recurso local dejan de resolver, anota qué aplicación falla y si ocurre en una sola red. Revisa si el hostname del resolutor está bien escrito, si el modo estricto muestra error, si hay una VPN o una política empresarial y si el problema desaparece al restaurar temporalmente la configuración anterior. Una red de hotel puede exigir un portal de acceso; un nombre de intranet puede existir solo en el DNS de la organización. El artículo de Mozilla para administradores documenta precisamente filtros y nombres privados como situaciones que necesitan atención. La solución puede ser una excepción o política concreta, no mantener toda la navegación permanentemente sin protección.

Una decisión proporcionada para cada caso

Si tu preocupación principal es que una red pública observe o manipule consultas DNS, configura un modo cifrado y confirma que está activo. Si te importa además quién conserva datos, lee la política del resolutor y elige conscientemente; el cifrado no sustituye esa evaluación. Si hay controles familiares, nombres internos o un equipo administrado, averigua cómo se integran antes de imponer un proveedor externo. Y si buscas ocultar tu actividad al propio sitio donde inicias sesión, el DNS privado no responde a esa necesidad.

La pregunta útil no es «¿he activado una opción llamada privado?», sino «¿qué aplicación envía qué consulta, a quién y con qué política de error?». Cuando puedes responderla, el ajuste deja de ser una promesa abstracta y se convierte en una mejora comprobable del tramo DNS, con límites claros.

Fuentes y agradecimientos

Este texto se elaboró con las especificaciones RFC 8484, DNS sobre HTTPS, RFC 7858, DNS sobre TLS y RFC 9230, Oblivious DoH experimental; las guías de Mozilla sobre los niveles DoH de Firefox, Google sobre DNS seguro en Chrome y Android sobre DNS privado; y la política de Cloudflare para su resolutor público, su guía de routers y su método de comprobación. Agradecemos a las personas que redactaron los RFC y a los equipos que mantienen accesibles esos manuales y políticas. Sus autores y organizaciones no han participado en la redacción de Gaia ni avalan esta guía.