Filtro DNS de VPN: bloquear nombres no bloquea anuncios

Una sola línea de dnsmasq puede responder a un nombre con NXDOMAIN, y ese es todo el mecanismo. Nunca lee HTML, nunca inspecciona la ruta de una petición y nunca ve qué hace una aplicación con una conexión que ya abrió. Por eso compararlo con una extensión del navegador es comparar dos tareas distintas. Una decide si un nombre se resuelve; la otra decide qué ocurre después.

Qué controla realmente un filtro de nombres

La opción address=/metrics.example/, sin nada después de la última barra, hace que el resolutor devuelva NXDOMAIN para ese nombre y sus subdominios. Dejar la dirección vacía es la parte importante: evita enviar a los clientes a un servidor de reemplazo sin relación o hacer pasar una dirección de bucle local por el destino real. El manual de dnsmasq describe esa forma como una respuesta negativa y no como una redirección.

Todo lo que la regla puede hacer se deriva de esa única decisión. Un cliente que pregunta a este resolutor obtiene una respuesta negativa; un cliente que pregunta a otro resolutor obtiene lo que diga ese resolutor. El filtro no sabe nada de la ruta, la cadena de consulta ni la cuenta que habría usado la aplicación.

Ese detalle importa porque un nombre de host suele servir para varios fines. Los puntos de inicio de sesión, las imágenes y el seguimiento pueden compartir un dominio, y una regla que elimina todo el nombre puede eliminar también un flujo de trabajo. Una política a nivel de nombre tiene que aceptar ese intercambio o elegir nombres más estrechos.

En qué se diferencia un bloqueador del lado del cliente

Una extensión del navegador ve la petición antes de que salga, así que puede hacer coincidir una ruta de URL, cancelar una petición concreta y ocultar el elemento que habría mostrado el resultado. Puede permitir example.com/article mientras rechaza example.com/ads/, algo que ninguna respuesta DNS puede expresar. Esa vista a nivel de ruta es la capacidad que un resolutor sencillamente no tiene. También es la razón de que una lista de filtros creada para una herramienta rara vez se comporte igual en la otra.

El coste es el alcance. Esa protección vive dentro de un navegador, en un perfil, en un dispositivo, y desaparece cuando el usuario cambia a otra aplicación. Un filtro DNS configurado en la pasarela cubre todos los dispositivos que usan el resolutor de la pasarela, incluidos los dispositivos donde no se puede instalar ninguna extensión.

Ninguna de las dos disposiciones está completa por sí sola. Un filtro DNS no puede eliminar un identificador que una página ya envió, y una extensión del navegador no puede proteger una aplicación que nunca la carga.

La ruta del resolutor decide si algo de esto se aplica

Una VPN puede anunciar un servidor DNS y aun así no recibir todas las consultas. Un navegador con DNS cifrado configurado, una aplicación con su propio resolutor o un dispositivo en una ruta de red que excluye la pasarela mirarán todos a otro sitio. Las plataformas móviles ofrecen cada vez más un ajuste de DNS privado que sustituye en silencio lo que sugiere el túnel.

Así que pruebe la ruta y no la política. Consulte el resolutor previsto directamente desde la pasarela, luego consúltelo desde un cliente y compare, y después observe si un nombre que debería estar bloqueado falla de verdad en la aplicación que ejecuta el usuario.

Las respuestas en caché y los sockets abiertos lo vuelven ruidoso. Una página que ya cargó sus recursos seguirá funcionando después de cambiar la regla, así que una conexión nueva es mejor prueba que recargar una pestaña vieja.

Pruebe ambas direcciones antes de afirmar un resultado

Use un nombre de documentación bloqueado a propósito, un nombre público permitido y un nombre privado que el servicio necesita:

$ dig +short metrics.example @10.40.0.53
$ dig +short example.com @10.40.0.53
$ dig +short intranet.corp.internal @10.40.0.53

Una respuesta vacía para el nombre bloqueado, una dirección normal para el público y una dirección privada para el interno muestran en conjunto que el filtrado, la resolución aguas arriba y los registros locales funcionan. Si los tres fallan, está ante un problema aguas arriba o del receptor, no de un filtro.

Mantenga la afirmación estrecha en todo lo que publique internamente. Esto es filtrado de dominios en un resolutor, no inspección de contenido, no filtrado de rutas y no una promesa de que nadie es rastreado. Indique el propietario de la política, la ruta de excepción y el periodo de retención de consultas junto a las reglas, porque un filtro que registra cada búsqueda tiene su propio costo de privacidad.