VPN DNS Filter: Blocking Names Will Not Block Ads

One dnsmasq line can answer a name with NXDOMAIN, and that is the entire mechanism. It never reads HTML, never inspects a request path, and never sees what an application does with a connection it already opened. Comparing it with a browser extension is therefore a comparison of two different jobs. One decides whether a name resolves; the other decides what happens after it does.

What a name filter actually controls

The option address=/metrics.example/, with nothing after the final slash, makes the resolver return NXDOMAIN for that name and its subdomains. Leaving the address empty is the important part: it avoids sending clients to an unrelated replacement server or pretending a loopback address is the real destination. The dnsmasq manual documents that form as a negative answer rather than a redirect.

Everything the rule can do follows from that single decision. A client that asks this resolver gets a negative answer; a client that asks a different resolver gets whatever that resolver says. The filter has no knowledge of which path, query string or account the application would have used.

That granularity matters because one hostname often serves several purposes. Sign-in endpoints, images and tracking can share a domain, and a rule that removes the whole name may remove a workflow with it. A name-level policy has to accept that trade-off or choose narrower names.

Where a client-side blocker differs

A browser extension sees the request before it leaves, so it can match a URL path, cancel a specific request and hide the element that would have displayed the result. It can allow example.com/article while refusing example.com/ads/, which no DNS answer can express. That path-level view is the capability a resolver simply does not have. It is also why a filter list built for one tool rarely behaves the same way in the other.

The cost is scope. That protection lives inside one browser, in one profile, on one device, and it disappears when the user switches to another application. A DNS filter configured on the gateway covers every device that uses the gateway's resolver, including devices where no extension can be installed.

Neither arrangement is complete on its own. A DNS filter cannot remove an identifier that a page already sent, and a browser extension cannot protect an application that never loads it.

The resolver path decides whether any of it applies

A VPN can advertise a DNS server and still not receive every query. A browser with encrypted DNS configured, an application with its own resolver, or a device on a network path that excludes the gateway will all look somewhere else. Mobile platforms increasingly offer a private-DNS setting that quietly overrides what the tunnel suggests.

So test the path rather than the policy. Query the intended resolver directly from the gateway, then query it from a client and compare, and then observe whether a name that should be blocked actually fails in the application the user runs.

Cached answers and open sockets make this noisy. A page that already loaded its resources will keep working after the rule changes, so a fresh connection is a better test than reloading an old tab.

Test both directions before claiming a result

Use a deliberately blocked documentation name, an allowed public name, and a private name the service needs:

$ 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

An empty answer for the blocked name, a normal address for the public one and a private address for the internal one together show that filtering, upstream resolution and local records all work. If all three fail, you are looking at an upstream or listener problem rather than a filter.

Keep the claim narrow in whatever you publish internally. This is domain filtering on a resolver, not content inspection, not path filtering and not a promise that nobody is tracked. State the policy owner, the exception route and the query-retention period alongside the rules, because a filter that logs every lookup has its own privacy cost.