Blocking ads and trackers at the DNS layer

A hostname is a label for humans. When an app wants metrics.example-ads.net it hands that string to the operating system's stub resolver and waits, because there is no packet it can send until something returns a numeric address. Only once an address comes back does a connection exist at all: a TCP handshake, then a TLS handshake, then the actual request and its response.

A filter sits at that first step, in the resolver rather than in the app. It checks the name against a blocklist, and on a match it answers straight away, either that no such host exists or with an address that leads nowhere, instead of passing the question on. The app then fails to connect to a host it never located. From its point of view the ad server is not blocked; it simply is not there.

Notice how little the filter is working with. It sees a hostname, and that is the entire input. It does not see the page you are reading, the path after the slash, the cookies attached to the request, or which rectangle on screen the resource was going to fill. Everything that follows, the strengths and the limits equally, falls out of that one fact.

Compare the two places a block can happen. A cosmetic rule in a browser hides an element after the fact: the request went out, the connection was negotiated, the payload arrived, and the tracker on the far end was contacted and had its chance to record the visit. The page looks clean, and every byte was still paid for. The better extensions do block the request itself rather than merely hide the result, which is genuinely different, but only for traffic the browser makes.

A refused lookup costs one small answer. There is no handshake, no certificate exchange, no transfer, and no beacon delivered. On a phone this matters more than the byte count suggests, because a cellular radio does not switch off the instant a request finishes; it stays in a high-power state for seconds afterwards in case more follows. A page that quietly contacts twenty measurement hosts keeps waking the radio twenty times. Not making those requests removes the tail as well as the payload.

The first is first-party advertising. If the ad arrives from the same hostname as the article around it, there is no separate name to decline, and refusing that name would take the site down with it. A feed is the clearest case: the same backend that returns the posts returns the promoted ones in the same response, from the same host, so there is nothing separable to refuse. That is why a name filter changes far less inside a social app than inside a game that fetches its advertising from an outside network. It is not a hole in the list that a better list would close; it is the shape of a tool that works on names.

The second is anything visual. A filter cannot hide an empty frame, reclaim the space a banner was given, or tidy up the layout afterwards. Blocked slots sometimes leave a blank rectangle or a broken-image icon, which is the honest signature of a request that failed rather than an element that was removed. On a page built mostly out of its advertising, the result is more visible gaps than a page-level blocker would have left, because nothing is tidying up after the refusal.

The third is precision below the hostname. A blocklist entry is a name, so the smallest unit it can express is a whole host, and a rule written against a parent domain applies to every subdomain beneath it. When one domain serves both the measurement you would rather refuse and a stylesheet the page needs, or when a sign-in redirect and a click tracker live under the same parent, the decision is all or nothing. There is no way to say "this host, but only the part that is not tracking" — that granularity belongs to tools that can read a URL, and a resolver only ever sees the name.

A browser extension runs inside the browser, which is both its advantage and its boundary. It can read page structure, cancel individual requests by URL and rewrite the document, none of which a name filter will ever manage. What it cannot do is see traffic that never goes through the browser, and on a phone a great deal of what leaves the device never does.

Consider what else is talking: a mail client fetching remote images, free apps whose embedded analytics and advertising kits report in on every launch, a game's ad network, a crash reporter, a shopping app checking in while it sits in the background. None of them ask a browser for permission, and no browser extension can see them. Name resolution, by contrast, is the one step every one of them performs identically, which is why intervening there reaches all of them at once.

So these are complements rather than competing options, and on a phone the division is sharper than on a desktop. Safari on iOS does accept content blockers, but through a deliberately restricted interface: the extension hands iOS a list of rules in advance and never sees the requests themselves, so it cannot make a decision in the moment. Chrome on Android accepts no extensions at all; Firefox for Android does. Page-level filtering on mobile is therefore present in some browsers, weaker in others and absent in the rest, and in none of them does it reach another app.

A filter can only act on a question that reaches it, and two ordinary things stop the question arriving. The first is caching. Every DNS answer carries a time-to-live, and your operating system, your browser and sometimes the app itself hold on to answers until it expires. A name resolved before you switched filtering on stays resolved afterwards, and a refusal issued while it was on can keep being returned for a while after you switch it off, because refusals are cached like any other answer. This is why a change in settings sometimes appears to do nothing for several minutes, and why a connection already open to an address carries on regardless: nothing re-resolves a name it has already resolved.

The second is a program that brings its own resolver. Nothing obliges software to ask the operating system for an address. A browser or an app can speak DNS over HTTPS directly to a resolver it chose itself, or carry a resolver address compiled into it, and in either case the lookup never passes the filtering resolver, so it is never filtered. Those lookups are still carried inside the tunnel, so the local network cannot read them, which is the one case where you have the encryption and none of the filtering. The fix is not in the tunnel, because the tunnel cannot answer a question it is not asked: where a browser exposes a secure-DNS setting of its own, turning that off is what hands its lookups back to the system resolver.

A blocklist is a curated list of hostnames, and curation never finishes. Advertising and measurement networks register new names continuously, abandoned domains get bought and put to ordinary use, and large content delivery networks host tracking scripts and essential assets as neighbours on the same name. A list is therefore a standing judgement that needs maintaining, and each update can change how some site behaves for you tomorrow.

Over-blocking has a recognisable fingerprint: everything works except one specific action. A checkout form that will not submit, an app that spins forever on sign-in, a bare network error with no other symptom, one broken thumbnail in a gallery, a link from an email that leads nowhere because it is routed through a click tracker the list refuses. The tell is how narrow it is. Genuine connection trouble is not that selective.

Which is why the ability to turn filtering off matters as much as the filtering. One switch separates the two explanations: disable it, repeat the exact action, and you know within seconds whether the list was responsible. A blocking feature with no off switch turns a thirty-second check into an afternoon.

While the tunnel is up, your lookups are answered at the far end, and that is where filtering is applied. A name on the list is refused there, so your device never contacts the host, and because the decision happens at the resolver rather than inside a browser it applies to every app on the device for as long as you stay connected. Encryption and filtering are separate concerns: your traffic is carried the same way whether blocking is on or off.

It is a setting, not a condition of use, so turn it off whenever a site misbehaves and back on afterwards. The mechanism also explains its own boundary honestly. Filtering lives on the resolver the tunnel points at, which means it stops when you disconnect, and it has no effect on a device that is not running the app.

Seeing whether a device-wide filter changes anything for you is mostly a matter of living with it for a few days on the apps you actually use. The free tier allows three hours a week, one hour per session, on two devices, which is enough to watch the mechanism work; the monthly plan also starts with a seven-day free trial. Paid access is $0.99 a day, $1.99 a week or $3.99 a month, with no annual subscription and no long-term commitment, so a short trial of the idea does not require signing up for a year of it.