DNS privado frente a VPN: qué cubre realmente cada capa

Tu teléfono tiene el DNS privado configurado con un nombre de host de proveedor y una aplicación VPN en marcha al mismo tiempo. Es razonable suponer que uno de los dos se encarga ahora de las consultas de nombres. Ninguno lo hace, en el sentido que sugiere esa frase, y la forma más rápida de ver por qué es seguir una sola solicitud desde el momento en que tocas un enlace.

Estas dos funciones se sitúan en puntos distintos del mismo recorrido. El DNS privado cifra la pregunta que haces a un resolutor. Una VPN cambia la ruta que toma la conexión de la respuesta.

Así que recórrelo en orden, en un dispositivo donde ambas estén activadas, y fíjate en qué puede ver todavía cada capa.

Paso uno: la consulta sale de la aplicación

Tocas un enlace. Antes de que algo se conecte, la aplicación necesita una dirección para ese nombre de host. En Android, la pantalla relevante es Ajustes, Red e Internet, DNS privado. Si eliges Nombre de host del proveedor de DNS privado, el dispositivo entra en modo estricto: realiza DNS sobre TLS hacia ese nombre de host en el puerto 853, y si el intercambio cifrado falla, la consulta falla en lugar de volver en silencio al texto plano en el puerto 53.

Eso es una diferencia importante respecto a Automático, que usa cifrado oportunista y no dudará en utilizar un resolutor sin cifrar cuando la red interfiere. Si tu objetivo es que las consultas nunca vayan en claro, el modo estricto con un nombre de host de proveedor es la configuración que encaja.

Aquí está lo primero que revela el recorrido: la consulta está protegida contra la red local, y el resolutor sigue conociendo el nombre. El cifrado cubre el salto. El operador de ese resolutor ve la consulta porque responderla es su trabajo.

Paso dos: la conexión toma otra ruta

El resolutor devuelve una dirección y la aplicación se conecta a ella. Este paso no se ve afectado por cómo se cifró la consulta. Sin túnel, la conexión sale de tu dirección pública habitual, y la IP de destino y el apretón de manos TLS suelen hacer visible el nombre de host para la red de todos modos, con DNS cifrado o sin él.

Activa la VPN y este es el paso que cambia. El tráfico que coincide con la política de enrutamiento del cliente pasa por el túnel, la red local ve una conexión al extremo de la VPN, y el sitio normalmente ve la dirección de salida. La resolución de nombres también puede viajar dentro del túnel, según lo que empuje el cliente.

Esa separación es toda la comparación en una frase. El cifrado de DNS responde quién puede leer la pregunta. Una VPN responde adónde va la conversación.

Paso tres: dentro del túnel, el DNS se convierte en una cuestión de política

Ahora las dos funciones interactúan, y el navegador es la fuente habitual de sorpresas. Un navegador con su propia configuración de DNS seguro puede enviar consultas a su resolutor elegido por HTTPS en lugar de preguntar al sistema operativo. La configuración de DNS privado de Android no llega a esa decisión.

En Firefox el interruptor está en Ajustes, Privacidad y seguridad, Activar DNS seguro. En Chrome está en Ajustes, Privacidad y seguridad, Usar DNS seguro. Ambos pueden fijarse a un proveedor concreto o dejarse desactivados, y cuando están activados, la configuración de DNS del túnel se omite para esas consultas aunque el tráfico de la página siga usando el túnel.

Si la VPN empuja su propio resolutor y el navegador insiste en el suyo, obtienes una división: los nombres se resuelven, las páginas cargan, y las consultas que debían pasar por el túnel salieron directamente. Una dirección de resolutor distinta del extremo de la VPN no es prueba de una fuga por sí sola, pero una ruta de consulta que contradice tu intención declarada merece corregirse.

Paso cuatro: los nombres internos son donde se rompe

Conéctate a una VPN de trabajo y abre un host de intranet. Si el DNS seguro del navegador está activado y apunta a un resolutor público, ese nombre no existe para el navegador. El túnel está levantado, todo lo demás funciona, y un nombre de host falla con un error que parece que el sitio está caído.

El mismo fallo aparece a la inversa en Android. El DNS privado estricto con un proveedor público no resolverá nombres que solo conoce el resolutor interno, y el modo estricto no tiene alternativa. Repartir el DNS de un teléfono entre un resolutor público cifrado y un resolutor corporativo no es una configuración; es una cuestión de política de enrutamiento que debe responder quien gestiona la VPN.

Comprueba esto antes de culpar al túnel: consulta el nombre interno, y luego el mismo nombre con el DNS seguro del navegador desactivado. Si se resuelve, la selección de resolutor era el problema, no la conexión.

Qué te dice el recorrido que cambies

Cuatro pantallas llevan casi todo. Míralas en este orden y anota lo que dice cada una, porque la respuesta suele estar visible en la combinación:

1. Ajustes de Android, Red e Internet, DNS privado: Automático o un nombre de host de proveedor, y qué nombre de host.
2. La configuración de DNS seguro del navegador: desactivada, o fijada a un resolutor concreto.
3. La política de DNS del cliente VPN: ¿empuja un resolutor, y el túnel dividido excluye algo que aún necesita nombres?
4. Una prueba de nombre de host interno con el túnel levantado, ejecutada dos veces, una con el DNS del navegador activado y otra desactivado.

Luego ajusta la corrección al requisito, no al revés. Si el requisito es que las consultas salgan cifradas y vayan a un resolutor que elegiste, configura el DNS privado estricto y haz que el navegador esté de acuerdo. Si el requisito es que el tráfico salga en otro sitio, configura el túnel y deja de esperar que una configuración de DNS mueva tu dirección.

Y ten presentes los límites. Ninguna de las dos funciones hace seguro un destino hostil, y ninguna elimina una identidad con la que hayas iniciado sesión. El cifrado cambia quién puede leer la pregunta; el túnel cambia adónde va la conexión; nada de lo uno ni de lo otro anonimiza la cuenta.