DNS ad and tracker blocking

Guides: Choosing a tier · DNS blocking · Whitelisting

DNS ad and tracker blocking

Filtering is what the security tier adds, and it is added at the one place every request passes through: the name lookup. Ads, trackers and known-malware domains are refused before your device ever opens a connection to them, on every app on the device — no browser extension, no per-app settings.

How it answers

• AdGuard Home at 172.16.41.1, reachable only from inside your tunnel. It is a resolver instance of its own, so its filter lists and its cache never touch the privacy tier.
• Filter lists, refreshed on the gateway from their published sources. The lists decide the answer; the tier decides which lists answer you.
• Per device, not per account. Each device’s tier is its DNS posture, so one subscription can run a phone filtered and a laptop unfiltered at the same time.

What it does not see

DNS filtering is name-level, and the limits follow from that:

• It cannot read inside an encrypted connection. Blocking works because the name is asked for in the clear inside the tunnel; what happens after the connection is established is not filtered.
• It cannot tell two requests to the same name apart. A domain is blocked or it is not — there is no “block the ads on this page but not the page”.
• It does not cover a service reached by address rather than by name, and it is not a firewall: it refuses lookups, not traffic.
• The lists are shared. An entry added for one client changes answers for everyone on the tier, which is why exceptions are reviewed rather than applied per device. See Requesting a whitelist entry.

Nothing about your queries is kept

Query logging and statistics are disabled on the resolvers, on every tier, and that is tested rather than asserted: the infrastructure audit re-applies the setting, sends a real query, and requires that nothing was written. The full list of what is and is not stored is on what we log.

If a site you need is blocked

Two things are worth ruling out before you report it:

1. The cache. A name may be answering from a cached entry that predates a list change, and a resolver loading new rules can return an empty answer that looks like a block. Re-run the lookup after a moment and see whether it settles.
2. The device you are asking from. Ask from the device that has the problem, on its own resolver — a test from a different machine observes a different policy.

If it still fails, the exception request is the next step: Requesting a whitelist entry.

Previous: Choosing a tier.