Cada vez que abres un sitio web o una aplicación, tu dispositivo pregunta primero a un servidor dónde vive ese servicio. Esa pregunta es una búsqueda de DNS, y la mayoría de la gente nunca la ve. Importa porque la búsqueda nombra el sitio que estás a punto de visitar y, en muchas redes, viaja sin cifrar, por lo que cualquiera que la retransmita o la responda puede leerla.
Una página puede estar totalmente protegida por HTTPS y, aun así, la lista de sitios que visitas se filtra a través del DNS. El análisis del IETF sobre la privacidad en el DNS, RFC 9076, lo resume con un ejemplo: el sitio web de Alcohólicos Anónimos es público, pero el hecho de que lo hayas visitado no debería serlo.
Después de leer esto, sabrás quién puede ver tus búsquedas, qué soluciona el DNS cifrado y qué deja expuesto, dónde encaja DNSSEC y qué configuraciones valen diez minutos de tu tiempo. No cubrimos la elección de un proveedor de DNS específico, el bloqueo de publicidad basado en DNS, ni la ejecución de tu propio resolvedor. Cada uno de esos temas requiere su propia página.
Qué es el DNS, en términos sencillos
Las computadoras se encuentran entre sí mediante números llamados direcciones IP. Las personas usan nombres como ej.org. El DNS es el servicio de búsqueda que convierte uno en el otro. El software de tu dispositivo, llamado resolvedor secundario o stub resolver, entrega cada pregunta a un resolvedor recursivo, un servidor que realiza el trabajo pesado de encontrar la respuesta (RFC 9076).
He aquí un caso concreto. Te conectas al Wi-Fi de un aeropuerto y abres el portal para pacientes de tu clínica. Tu teléfono no eligió un resolvedor. La red le dijo cuál usar cuando te conectaste, que es la configuración habitual, y el RFC 9076 señala que la gran mayoría de la gente nunca la cambia. Por lo tanto, el resolvedor del aeropuerto, o el de su proveedor de internet, guarda ahora un registro de que tu teléfono pidió la dirección de la clínica a las 9:14 de la mañana.
Cómo funciona una búsqueda
Toma como ejemplo una búsqueda de www.example.com cuando no hay nada guardado en ningún punto del camino:
- Tu resolvedor secundario (stub resolver) le pregunta al resolvedor recursivo.
- El resolvedor recursivo le pregunta a un servidor de nombres raíz. El raíz no sabe la respuesta, pero apunta a los servidores responsables de
.com. - El resolvedor le pregunta a un servidor de
.com, que apunta a los servidores que manejanexample.com. - El resolvedor le pregunta a esos servidores. Se llaman servidores de nombres autoritativos porque conservan los registros reales, y devuelven la dirección IP.
- El resolvedor recursivo entrega la respuesta a tu dispositivo y guarda una copia durante un tiempo limitado.
Esa copia es la razón por la que la mayoría de las búsquedas se saltan los pasos 2 al 4. También es la razón por la que los diferentes servidores ven distintas cantidades de información. Un resolvedor secundario normalmente no guarda caché, por lo que el resolvedor recursivo ve casi todas tus búsquedas, mientras que los servidores autoritativos solo ven aquellas que el resolvedor no pudo responder de memoria (RFC 9076). A menos que el resolvedor use una técnica llamada minimización de QNAME, cada servidor en la cadena recibe tu pregunta original completa, no solo la parte que necesita.
Una sola página web también significa muchas búsquedas. Una sola página puede desencadenar búsquedas para docenas de nombres de dominio debido a imágenes, scripts y anuncios integrados, y los navegadores a veces buscan nombres con anticipación por si haces clic (RFC 9076). La lista que construye tu resolvedor es más larga y reveladora que la lista de sitios que tenías intención de visitar.
Quién puede ver tus búsquedas
Depende de dónde se ubique tu resolvedor y de si el tráfico está cifrado.
| Quién | Qué pueden ver | Cuándo |
|---|---|---|
| Cualquiera entre tú y tu resolvedor, como el operador de un Wi-Fi o tu proveedor de internet | Cada dominio que buscas, y pueden alterar las respuestas | Las búsquedas están sin cifrar |
| El operador de tu resolvedor (tu proveedor, tu empleador o un servicio de DNS público) | Cada búsqueda que le envían tus dispositivos, vinculada a tu dirección IP | Siempre, esté cifrado o no |
| Servidores de nombres autoritativos | Solo las búsquedas que el resolvedor no pudo responder desde la caché, normalmente con la dirección del resolvedor en lugar de la tuya | Tu dirección puede filtrarse si el resolvedor reenvía parte de ella usando una función llamada subred de cliente EDNS (EDNS client subnet) |
Las filas de la tabla provienen del RFC 9076, que también cubre la parte de “alterar las respuestas”: un atacante que controle la red puede sustituir sus propias respuestas a cualquier búsqueda no cifrada.
Lo que el operador de tu resolvedor haga con los datos es una cuestión de política, y las políticas varían. El RFC 9076 señala que las políticas de privacidad para resolvedores proporcionados por la red pueden o no estar disponibles, mientras que los grandes servicios públicos como Google Public DNS, Cloudflare y Quad9 publican las suyas. Algunos resolvedores también bloquean ciertos dominios a propósito, normalmente sitios con malware conocido. Eso es útil cuando es lo que quieres y confuso cuando no lo es.
Qué soluciona el DNS cifrado y qué deja expuesto
Tres estándares envuelven una búsqueda en cifrado entre tu dispositivo y tu resolvedor.
| Nombre | Puerto | Estándar | Notas |
|---|---|---|---|
| DNS sobre TLS (DoT) | 853 | RFC 7858, 2016 | Fácil de reconocer para una red por su puerto. La función de DNS privado de Android lo usó cuando se introdujo en 2018. |
| DNS sobre HTTPS (DoH) | 443 | RFC 8484, 2018 | Viaja en el mismo puerto que el tráfico web ordinario, por lo que es más difícil de aislar o bloquear. Firefox lo utiliza. |
| DNS sobre QUIC (DoQ) | 853 (UDP) | RFC 9250, 2022 | Su especificación señala que las propiedades de privacidad se asemejan a las de DoT. |
Los tres hacen el mismo trabajo básico. Las personas entre tú y el resolvedor ya no pueden leer tus búsquedas ni manipularlas. En el aeropuerto, el operador del Wi-Fi puede ver que tu teléfono habla con un resolvedor, pero no que pidió la dirección de la clínica.
Los límites importan tanto como el beneficio:
- El resolvedor sigue viéndolo todo. El RFC 9076 es tajante al indicar que los transportes cifrados no reducen lo que aprende el resolvedor, e incluso pueden darle más datos para correlacionar. No has eliminado a un observador; has elegido en cuál confiar.
- El análisis de tráfico sigue funcionando hasta cierto punto. Los tamaños y la temporización de las consultas cifradas se pueden cotejar con lo que un resolvedor envía aguas arriba. El relleno (padding) reduce esto, pero el RFC 7858 señala que el relleno simple por sí solo podría no ser suficiente.
- Las configuraciones débiles pueden degradarse. Si tu dispositivo descubre un resolvedor cifrado a través de la red y no lo verifica, un atacante en esa red puede interferir (RFC 7858). El modo de “Nombre de host del proveedor de DNS privado” de Android es del tipo más estricto: envía consultas al servidor que nombraste a través de un canal seguro, o marca la red como sin acceso a internet si no puede alcanzar ese servidor (Google Security Blog, 2018).
- Un resolvedor pequeño puede hacerte más fácil de rastrear. El RFC 9076 observa que un resolvedor con pocos usuarios, incluso con cifrado, puede ayudar a alguien a seguirte de una red a otra.
- Puede desactivar filtros. La documentación de Mozilla indica que DoH se salta los resolvedores locales y, con ellos, cualquier bloqueo de malware o control parental, razón por la cual Firefox verifica la existencia de estos y se retira cuando los encuentra.
- Las redes pueden bloquearlo y los dispositivos pueden usar alternativas. El RFC 7858 advierte que el puerto 853 puede ser bloqueado por algunos cortafuegos. El despliegue por defecto de Firefox usa un modo de respaldo, de modo que si las búsquedas de DoH fallan, utiliza silenciosamente el DNS ordinario del sistema.
El nombre del sitio se filtra por segunda vez
Cifrar la búsqueda no termina el trabajo. Cuando tu navegador abre una conexión HTTPS, su primer mensaje incluye el nombre del sitio que desea, en texto plano. Ese campo se llama Indicación del Nombre del Servidor o SNI (Server Name Indication), y cualquiera que observe la conexión puede leerlo (Cloudflare, 2023).
Encrypted Client Hello, o ECH, cierra esa brecha. El nombre del sitio va dentro de una parte cifrada del mensaje, y la parte visible lleva un nombre compartido en su lugar. En Cloudflare, cada sitio con ECH activado muestra el mismo nombre externo, cloudflare-ech.com. Las preguntas frecuentes de Mozilla indican que Firefox tiene ECH activado por defecto desde la versión 119, y describen que la ganancia de privacidad es mayor cuando muchos sitios comparten un solo servidor. ECH solo funciona cuando el sitio lo admite, y Mozilla señala que muchos aún no lo hacen.
ECH está vinculado al DNS de una manera y deja una brecha. En Firefox, ECH obtiene sus claves de cifrado de un registro de DNS, y Mozilla señala que obtiene su mayor beneficio de privacidad junto con DoH. La brecha es la dirección IP del servidor, que tu proveedor aún ve. Si un sitio tiene un servidor para él solo, esa dirección por sí sola puede revelarlo.
Qué añade DNSSEC
DNSSEC, corto para Extensiones de Seguridad DNS (DNS Security Extensions), permite al propietario de un dominio firmar sus registros de DNS. Un resolvedor que verifica las firmas puede saber si una respuesta fue falsificada o alterada en su camino hacia ti. El RFC 7858 describe esto como integridad de la respuesta. La cadena de firmas comienza desde una clave raíz que los resolvedores validadores conservan como su ancla de confianza (trust anchor).
No cifra nada. El RFC 9076 señala que DNSSEC excluye explícitamente la confidencialidad de sus objetivos. Solo protege dominios cuyos propietarios los hayan firmado y resolvedores que realicen la verificación, y no dice nada sobre si el sitio al final es honesto. Un sitio de estafa en un dominio similar puede estar perfectamente firmado. Con DoH, tu dispositivo valida DNSSEC por sí mismo o confía en el informe del servidor DoH (RFC 8484).
A partir de octubre de 2026 hay un ejemplo en vivo. ICANN indica que una nueva clave raíz, KSK-2024, comenzó a firmar la zona raíz del DNS el 11 de octubre de 2026 a las 14:00 UTC, y que no se habían visto señales de interrupción generalizada. Sus instrucciones están dirigidas a personas que ejecutan resolvedores validadores, quienes necesitan confirmar que la nueva clave esté en su configuración. A menos que ejecutes tu propio resolvedor, no hay nada que tengas que hacer.
Mitos comunes
“El DNS cifrado oculta mi navegación.” Oculta tus búsquedas de la red entre tú y el resolvedor. El resolvedor aún las ve, la conexión aún revela una dirección IP y, sin ECH, todavía revela el nombre del sitio.
“DNSSEC y el DNS cifrado son lo mismo.” Resuelven problemas diferentes. Tanto el RFC 7858 como el RFC 8484 indican que los dos son independientes y compatibles, y que usar uno no reemplaza al otro.
“DoH es el privado y DoT es el débil.” Las especificaciones no respaldan a un ganador. El RFC 9076 señala que DoH lleva más funciones de HTTP que pueden actuar como identificadores, y dice que los usuarios enfocados en la privacidad pueden preferir implementaciones que sean claras sobre lo que envían. El RFC 8484 indica que no se sabe que DoH añada preocupaciones más allá de las del propio HTTPS. En la práctica, la diferencia es pequeña frente a la elección del resolvedor.
Qué hacer
Que algo de esto valga tu tiempo depende de quién te preocupe: el operador de un Wi-Fi hostil, tu proveedor de internet o una red que bloquee sitios. Si aún no lo has determinado, comienza con el modelado de amenazas. Los pasos a continuación están ordenados por cuánto ayudan con el menor esfuerzo. Esta página es información general, no asesoramiento profesional de seguridad para una situación específica.
- Activa el DNS cifrado para todo el dispositivo, no solo para una aplicación. Los teléfonos que se unen a redes Wi-Fi públicas son los que más ganan. En Android, busca “DNS privado”, normalmente en Ajustes, luego Redes e internet, aunque los fabricantes lo mueven. Elige “Nombre de host del proveedor de DNS privado” e ingresa el nombre de host de tu proveedor. iOS y macOS de Apple admiten DoT o DoH en todo el sistema, pero a partir de octubre de 2026 solo confirmamos que una aplicación puede configurarlo y que debes aprobarlo (Apple Developer). El costo: algunas páginas de inicio de sesión de hoteles y aeropuertos dependen del propio DNS de la red, y Android mostrará “sin acceso a internet” si no puede alcanzar el servidor que nombraste. Desactívalo para ese inicio de sesión y vuelve a activarlo después.
- Elige el resolvedor a propósito. Lee su política de privacidad para ver qué registra, durante cuánto tiempo y quién lo recibe. Una política es una promesa, no una garantía técnica, aunque algunos servicios respaldan las suyas con contratos, como hace Mozilla con sus socios de DoH. Esta página no clasifica a los proveedores.
- Mantén tu navegador actualizado para que ECH pueda funcionar. No hay nada que configurar en Firefox. Las preguntas frecuentes de Mozilla apuntan a la comprobación de navegador de Cloudflare para ver si está funcionando para ti.
- Si usas controles parentales o un resolvedor con filtrado, haz que ese resolvedor sea el cifrado. DoH en el navegador puede esquivar el filtrado local, y Mozilla señala que los bloqueadores de publicidad basados en DNS deben usar una conexión cifrada aguas arriba, o los sitios visitados se filtran indirectamente.
- En un dispositivo de trabajo o estudio, no toques la configuración de DNS. Las redes gestionadas pueden desactivar DoH por razones de directivas, y Firefox se retira en dispositivos gestionados. El resolvedor de tu empleador ve tus búsquedas de todos modos.
A partir de octubre de 2026, Mozilla indica que los usuarios de Firefox de escritorio en los Estados Unidos y Canadá tienen DoH por defecto, un despliegue hacia Rusia y Ucrania comenzó en 2022 y se planean más países. El resolvedor por defecto es un socio de confianza de Mozilla. Sus ajustes te permiten optar por no participar o elegir un proveedor diferente, en la sección de DNS sobre HTTPS de la configuración de Firefox.
Fuentes
- DNS Privacy Considerations (RFC 9076), IETF, julio de 2021
- Specification for DNS over Transport Layer Security (RFC 7858), IETF, mayo de 2016
- DNS Queries over HTTPS (RFC 8484), IETF, octubre de 2018
- DNS over Dedicated QUIC Connections (RFC 9250), IETF, mayo de 2022
- Root Zone KSK Rollover, ICANN, estado a octubre de 2026
- Firefox DNS over HTTPS, Soporte de Mozilla, 2026
- Encrypted Client Hello (ECH) frequently asked questions, Soporte de Mozilla, actualizado en agosto de 2024
- Encrypted Client Hello: the last puzzle piece to privacy, Cloudflare, 2023
- DNS over TLS support in Android P Developer Preview, Google Security Blog, 2018
- DNS settings, Documentación de Apple Developer, 2026