DNS: el eslabón que nadie refuerza

Auditoría de red de una pyme industrial, una mañana. Conecto una sonda pasiva al puerto espejo del switch principal y observo pasar el tráfico. Todo está en HTTPS, el director de RR. HH. está orgulloso de su cortafuegos nuevo de 18.000 €. Salvo que en el puerto 53, en claro, desfila la navegación completa de la empresa: el dominio del bufete de abogados consultado la víspera, el sitio del adquirente potencial, el banco, la mutua laboral, el competidor. En veinte minutos, reconstituí un expediente de M&A confidencial sin descifrar una sola conexión. El DNS me lo dio todo.

La trampa habitual

Todo el mundo ha interiorizado que HTTPSVersión segura de HTTP, que cifra la comunicación entre navegador y servidor mediante TLS.Ver el glosario protege. El candado verde, la «s» en la barra de direcciones, la formación interna que repite «verifique que el sitio está en HTTPS»: el reflejo está adquirido. Y es correcto —el contenido de sus intercambios sí está cifrado entre su navegador y el servidor—. El problema es que ese reflejo se detiene exactamente donde debería empezar a hacerse preguntas. Nadie se pregunta qué pasa antes de la conexión HTTPS. Y antes está el DNSSistema que resuelve los nombres de dominio en direcciones IP. Vector de vigilancia y censura muy subestimado.Ver el glosario.

Antes de que su navegador abra una conexión cifrada hacia mensajeria-banco.es, debe traducir ese nombre en dirección IP. Esa traducción, en la configuración por defecto de prácticamente todos los dispositivos del planeta, sale en claro, por el puerto 53, hacia el resolutor de su proveedor de accesoSistema que resuelve los nombres de dominio en direcciones IP. Vector de vigilancia y censura muy subestimado.Ver el glosario o de su operador móvil. Sin cifrado, sin autenticación, sin confidencialidad. Es el protocolo de 1987, y sigue siendo el valor por defecto en 2026. El contenido de su intercambio con el banco está protegido. El hecho de que usted hable con ese banco, a qué hora, cuántas veces, desde qué dispositivo: visible para todo el mundo en el camino.

El discurso dominante sobre la «seguridad de red» mantiene este agujero. Se venden cortafuegos de nueva generación, pasarelas web, soluciones de inspección de tráfico de cinco cifras, mientras el canal de fuga más elemental sigue abierto de par en par. Peor: muchos de esos equipos fuerzan el DNS a pasar por ellos en claro, con el pretexto de la «visibilidad». El reflejo «tengo HTTPS, estoy tranquilo» se ha convertido en un punto ciego colectivo. El DNS es el eslabón que nadie refuerza porque nadie lo mira —y eso es precisamente lo que lo convierte en un vector de vigilancia tan rentable para quien sabe escuchar—.

Modelo de amenaza real: lo que el DNS revela, y a quién

Piense en el DNS como en la guía telefónica de internet. Cada vez que un dispositivo quiere alcanzar un servicio, interroga a un resolutor: «¿cuál es la dirección de este dominio?». Esta pregunta, repetida miles de veces al día y por dispositivo, dibuja un retrato de una precisión temible. No el contenido —la intención—. Y la intención basta de sobra.

En DNS sin cifrar, esto es lo que resulta legible para quien escucha: cada dominio que usted visita, la marca de tiempo exacta, la frecuencia. No son solo los sitios que abre a mano en el navegador. Sus aplicaciones móviles hacen peticiones DNS permanentemente —su cliente de correo interroga al servidor cada minuto, su mensajería cifrada resuelve su dominio de relé, sus objetos conectados llaman a su nube, sus actualizaciones automáticas contactan con sus servidores—. El DNS delata la lista de sus aplicaciones, sus hábitos de sueño (la hora de la primera petición por la mañana), sus ritmos de trabajo, los servicios bancarios y médicos que usa, a veces su localización implícita vía la elección de los resolutores regionales y de las CDNSistema que resuelve los nombres de dominio en direcciones IP. Vector de vigilancia y censura muy subestimado.Ver el glosario.

¿Quién ve estos datos? Tres actores, como mínimo. Su proveedor de acceso u operador móvil primero, que opera el resolutor por defecto —en España y en toda la Unión, los metadatos de conexión se conservan legalmente durante un año, y varios proveedores explotan comercialmente esos datos o redirigen los dominios inexistentes hacia sus propias páginas de publicidad—. Luego, cualquiera que escuche en la red local: el Wi-Fi del hotel, la cafetería, el aeropuerto, la sala de conferencias, allí donde usted no controla nada y donde el puerto 53 pasa en claro ante las narices de todos los demás clientes. Por último, su resolutor mismo, sea cual sea —elegir un resolutor es elegir a quién confía la totalidad de su historial de navegación—.

Hay una sutileza que la gente olvida. Incluso cuando cifra el DNS, el apretón de manos TLSProtocolo de cifrado de transporte, base de HTTPS y de la seguridad web moderna.Ver el glosario contiene todavía el Server Name Indication (SNI) en claro —el nombre del dominio, visible para todo observador de red—. El mecanismo Encrypted Client Hello (ECH), estandarizado vía la RFC 9460, cifra ese SNI, pero su despliegue sigue siendo parcial en 2026 y depende de que el sitio objetivo lo soporte del lado del servidor. Dicho de otro modo: reforzar el DNS es necesario, pero solo es una parte del cuadro. El DNS sigue siendo, no obstante, el vector de fuga más amplio, el más sistemático y el más sencillo de taponar.

Otro punto que debo martillear en auditoría, porque vuelve sin cesar: el DNS en claro no es solo un problema de confidencialidad, es también un problema de integridad. En el puerto 53 no autenticado, cualquier actor en el camino de red puede responder en su lugar —es el DNS spoofing—. Usted pide la dirección de su banco, un atacante en el Wi-Fi del hotel responde con la IP de su servidor de phishing, y su navegador irá dócilmente a su casa. HTTPS y la validación de certificado recuperan parte del golpe (el sitio falso no tendrá el certificado correcto), pero no siempre, y no para los numerosos flujos que no validan estrictamente el certificado. Cifrar y autenticar el DNS cierra esa puerta al mismo tiempo que cierra la escucha. Dos problemas, una sola medida.

Y hay que salir de la idea de que «no me concierne, no tengo nada que ocultar». El modelo de amenaza real no es «alguien lee mis búsquedas de Google». Es un agregado: su operador revende un perfil de comportamiento, un corredor de datos lo cruza con otras fuentes, un asegurador o un empleador potencial lo compra, un Estado lo requisa, o un atacante dirigido reconstituye sus hábitos para preparar un spear phishingPhishing dirigido a una persona concreta, construido a partir de su perfil OSINT.Ver el glosario creíble. La petición DNS aislada es anodina. El flujo DNS completo sobre seis meses es un expediente.

El enfoque correcto: Do53, DoT, DoH, y el resolutor adecuado

El giro es uno de los más rentables de toda la seguridad operativa: poco esfuerzo, efecto inmediato, gratuito en la mayoría de los casos. Pero hay que comprender los tres modos para no equivocarse de combate.

Do53 — el DNS clásico, puerto 53, en claro. Es el valor por defecto en todos sus dispositivos. Ningún cifrado, ninguna autenticación de la respuesta. Su resolutor ve sus peticiones en claro, y cualquier equipo en el camino de red también. Es lo que usted quiere abandonar.

DoTVariante de DoH que utiliza TLS directo en lugar de HTTPS.Ver el glosario — DNS over TLS, puerto 853. Las peticiones están cifradas en un túnel TLS dedicado, definido por la RFC 7858. Nadie puede ya leerlas en tránsito. El inconveniente: el puerto 853 es identificable como «tráfico DNS cifrado». Un equipo de red hostil puede bloquearlo, lo que fuerza a ciertos sistemas a volver a caer en claro al puerto 53. Es el modo nativo y el más limpio en móvil (el «DNS privado» de Android), porque se aplica al sistema entero.

DoHProtocolo que cifra las consultas DNS en HTTPS, ocultándolas al ISP.Ver el glosario — DNS over HTTPS, puerto 443. Las peticiones se encapsulan en tráfico HTTPS estándar, según la RFC 8484. Doble ventaja: el cifrado, y sobre todo la indistinguibilidad —sus peticiones DNS se parecen a cualquier conexión web—. Bloquear DoH sin romper todo el tráfico HTTPS es extremadamente difícil, lo que lo convierte en el arma de elección contra la vigilancia de red activa. Es el modo privilegiado en el navegador y en los contextos donde la red local es hostil.

No confunda todo esto con DNSSEC, que vuelve a menudo en la discusión. DNSSEC firma criptográficamente las respuestas DNS —garantiza la integridad (la respuesta no ha sido falsificada en ruta), pero no cifra nada—. DNSSEC y DoH/DoT son complementarios, no competidores: uno protege contra la falsificación, los otros contra la escucha.

Una vez elegido el modo, queda la verdadera decisión: el resolutor. Es la entidad que hace las peticiones reales por usted, por tanto la que ve todo. Cambiarlo es la acción más impactante por el menor esfuerzo.

• Quad9Sistema que resuelve los nombres de dominio en direcciones IP. Vector de vigilancia y censura muy subestimado.Ver el glosario (9.9.9.9) — operado por una fundación suiza sin ánimo de lucro, política no-logs documentada, filtrado de los dominios maliciosos activo por defecto (base de amenazas agregada), soporte DoH y DoT. Mi opción por defecto para quien quiere seguridad sin configuración. Si tuviera que recomendar un solo resolutor a alguien que no quiere ajustar nada, es ese.
• Mullvad DNS — orientado a confidencialidad pura. Si ya usa Mullvad VPN, el DNS pasa por el túnel. Mullvad propone también resolutores públicos utilizables solos, con variantes que filtran publicidad y rastreo. Sin filtrado de seguridad por defecto: elección de privacidad, no de seguridad.
• NextDNSSistema que resuelve los nombres de dominio en direcciones IP. Vector de vigilancia y censura muy subestimado.Ver el glosario — el configurable. Usted crea un perfil: bloqueo de publicidad, rastreo, malware, categorías. Logs opcionales —activables para auditar su tráfico, desactivables del todo—. Freemium: 300.000 peticiones/mes gratis, luego unos 2 €/mes. Excelente para las familias y las pymes que quieren visibilidad controlada.
• CloudflareSistema que resuelve los nombres de dominio en direcciones IP. Vector de vigilancia y censura muy subestimado.Ver el glosario (1.1.1.1) — el más rápido en latencia, claim no-logs parcialmente auditado. Reserva: Cloudflare es una megacorp estadounidense que ya aloja una fracción masiva de la web. Su visibilidad sobre los flujos es colosal. Aceptable para el gran público, menos para quien quiere evitar la concentración de riesgo en un solo actor sometido al derecho estadounidense.
• Proveedor de acceso por defecto — a evitar. Perfilado comercial, redirecciones publicitarias, conservación legal. Es exactamente el resolutor que usted quiere abandonar.
• Self-hosted (Unbound + Pi-hole) — control total. Unbound resuelve en recursivo directamente ante los servidores raíz, sin terceros. Pi-hole filtra localmente publicidad y rastreo para toda la red. Usted carga con el mantenimiento, y no le sigue en movilidad (salvo VPN de vuelta). La opción correcta para el hogar endurecido, no para el viaje.

Una palabra sobre el self-hosted, porque es ahí donde la gente se hace más ilusiones. Pi-hole es un resolutor local que consulta listas de bloqueo: cuando un dispositivo pide la IP de doubleclick.net o de un dominio de telemetría, Pi-hole responde «NXDOMAIN» y la conexión no se hace nunca. Es potente —bloquea publicidad y rastreo a nivel de red para todos los dispositivos, incluida la SmartTV, la consola y los objetos conectados que no se pueden configurar individualmente, y le da una visibilidad completa sobre lo que cada dispositivo llama—. Pero Pi-hole, solo, no cifra nada. Todo lo que no bloquea sale en claro hacia su proveedor de acceso. La combinación que se sostiene es Pi-hole para el filtrado, Unbound detrás para la resolución recursiva directa, y un upstream cifrado (DoT) para las peticiones que salen de todos modos. Más complejo de montar, pero es el único montaje que le da a la vez filtrado, confidencialidad y control. Y tenga en cuenta que ciertas apps con DoH codificado en duro (Firefox, ciertos servicios de Google) esquivan pura y simplemente Pi-hole —el filtrado de red tiene sus límites frente a las aplicaciones que deciden su propio resolutor—.

Lo que implica en concreto

Errores que se ven todo el tiempo

• Configurar DoH solo en el navegador. Parcial por construcción. El cliente de correo, las apps móviles, los servicios de sistema y los objetos conectados continúan con el resolutor en claro por defecto. Se marca una casilla y uno se cree cubierto para el 100 % del tráfico cuando cubre una fracción.
• Creer que Pi-hole cifra las peticiones. Pi-hole filtra, no cifra. Sin upstream DoHProtocolo que cifra las consultas DNS en HTTPS, ocultándolas al ISP.Ver el glosario o DoTVariante de DoH que utiliza TLS directo en lugar de HTTPS.Ver el glosario configurado, todo lo que Pi-hole no bloquea —es decir, la gran mayoría— sale en claro hacia su proveedor de acceso. Pi-hole sin upstream cifrado es filtrado publicitario, no confidencialidad.
• Olvidar el DNS en viaje. Una configuración DoH puesta en casa no se aplica en la 4G ni en el Wi-Fi de hotel si solo vive en el navegador. En el extranjero, es el resolutor del operador local el que retoma el mando. Solo el DNS a nivel de sistema (perfil iOS, DNS privado Android) viaja con usted.
• Dejar el SMS o el proveedor de acceso como resolutor «porque funciona». Funciona, sí, y es exactamente el problema: funciona a la vez que expone su navegación completa a un actor que la conserva un año y la explota comercialmente.
• No probar jamás. Muchos creen estar en DoH y en realidad se fugan hacia el resolutor del proveedor. dnsleaktest.com(opens in a new tab) e ipleak.net(opens in a new tab) zanjan la cuestión en diez segundos. Una configuración DNS no verificada es una hipótesis, no una protección.

Checklist accionable

• N1 Activar DoH o DoT a nivel de sistema en todos sus dispositivos, no solo en el navegador
• N1 Elegir Quad9 (9.9.9.9) para la seguridad, o Mullvad/NextDNS según la necesidad de confidencialidad o de visibilidad
• N1 Verificar la ausencia de DNS leak con dnsleaktest.com tras cada cambio
• N2 En iOS 14+: instalar el perfil DNS NextDNS o Cloudflare (Ajustes > Perfil DNS)
• N2 En Android 9+: activar el DNS privado (DoT) en Ajustes > Red e internet
• N2 Verificar que el DNS del viaje aguanta a nivel de sistema, no solo en el navegador
• N2 En el hogar: Pi-hole para el filtrado + Unbound en resolución recursiva + upstream cifrado
• N3 En la empresa: resolutor DNS interno con registro (Umbrella, NextDNS Business, Infoblox) conectado al SIEM
• N3 En la empresa: desactivar el DoH de aplicación salvaje por GPO/MDM, imponer el resolutor controlado como punto de cifrado único
• N3 Seguir la tasa de peticiones que pasan por el resolutor controlado (> 98 %) y el plazo de detección de los dominios maliciosos

Para profundizar

Las referencias normativas están en el frontmatter: la RFC 8484 especifica DoH, la RFC 7858 especifica DoT, y la RFC 9460 describe el cifrado del SNI vía ECH que completa el cuadro. Del lado de los resolutores, las políticas de confidencialidad de Quad9 y NextDNS detallan exactamente lo que se registra —léalas antes de confiar su historial a quien sea—.

El DNS solo es una pieza del reforzamiento de red. Para comprender lo que una VPN protege de verdad y lo que no toca —incluida la trampa del DNS leak fuera del túnel—, vea VPN: el 95 % del marketing es falso. Para las redes no controladas donde el DNS en claro está más expuesto, lea Wi-Fi público: el verdadero riesgo. Y para aplicar este reforzamiento a nivel del sistema operativo en lugar de aplicación por aplicación, vea Endurecer el SO.