What AdGuard Home can and cannot fix

The dashboard says thousands blocked, and the ads still play

There is a very common home-server disappointment. You stand up a network-wide DNS filter, point every device at it, and within a day the dashboard reports tens of thousands of blocked queries. Then someone in the house opens YouTube, watches an advert all the way through, and asks what exactly you spent the weekend doing.

Nothing has gone wrong. The expectation was wrong, in a specific and fixable way: DNS filtering was assumed to be an ad blocker, when it is actually a name-resolution policy. Get that distinction right and a DNS filter becomes a useful, low-maintenance layer. Get it wrong and you will keep adding blocklists to solve a problem blocklists cannot reach.

What DNS filtering actually decides

AdGuard Home describes itself as network-wide software for blocking ads and tracking, designed to run on your own machine so you keep control of your DNS traffic. The important word is network-wide, because it explains both the strength and the ceiling.

A DNS filter sits in front of one decision: when a device asks for the address behind a name, should that name resolve? If the name is on a blocklist, the filter returns a blackhole answer instead of forwarding the query. That is the entire mechanism.

It is a good mechanism, for reasons AdGuard's own documentation sets out. It acts at the earliest possible stage of a request, before a connection is opened, saving traffic and battery rather than hiding something after it arrives. It is system-wide, so it covers devices where a browser content blocker is unavailable — a television, a games console, a smart speaker. And it addresses at least one tracking method AdGuard says only DNS filtering can deal with: CNAME-cloaked tracking, where a third-party tracker is disguised behind a first-party name.

So the honest summary is that DNS filtering is broad and cheap. It is not deep.

The ceiling the vendor documents itself

The clearest statement of the limit comes from AdGuard, not from its critics. Its FAQ says plainly that AdGuard Home cannot block YouTube and Twitch adverts, or sponsored posts on Facebook, X and Instagram, and gives the reason: any advert that shares a domain with content cannot be blocked by a DNS-level blocker unless you are prepared to block the content as well.

That single sentence resolves most of the confusion. DNS decides at the level of a name. If the advert and the video arrive from the same name, there is no decision available that keeps one and drops the other. Blocking the domain does not remove the advert; it removes YouTube.

Two related limits follow from the same design. DNS filtering is coarse — it applies no cosmetic filtering, so it will not tidy the empty rectangle left where something was blocked. And it cannot tell which application asked, because a DNS query does not carry that information, so per-app rules are impossible and per-app statistics are unreliable.

AdGuard's own answer for first-party advertising is a content blocking proxy, of the kind used in its standalone applications. It says support for that is planned for AdGuard Home, with the caveat that limits will remain and configuration may be complex. Treat that as a stated intention, not a delivery date.

Encrypted DNS is a smaller threat to your filter than the forums suggest

The standard objection is that encrypted DNS makes all of this pointless, because applications will simply resolve names somewhere else. The reality is narrower than the fear.

RFC 8484, which defines DNS-over-HTTPS, is explicit that filtering or inspection systems relying on unsecured DNS transport will not function once queries are wrapped in TLS. That is real, and it is by design. But the default behaviour of a mainstream browser is not the worst case. The Chromium project documents that Chrome's auto-upgrade does not change your DNS provider; it upgrades to that same provider's encrypted endpoint where one exists, specifically to preserve existing behaviour, and notes that split-horizon setups should continue to work. Managed deployments should be automatically opted out, and administrators can control the feature by policy.

The realistic risk is not silent bypass by an update. It is a person or an application deliberately selecting a different resolver — which Chromium documents as something users can do. That is a consent problem in your household, not a protocol ambush.

The constructive response is to remove the reason to leave. AdGuard Home can serve encrypted DNS itself: DNS-over-HTTPS, DNS-over-TLS, DNS-over-QUIC and DNSCrypt. It needs a certificate from a certificate authority or from Let's Encrypt, supplied as a full chain and a private key with a matching server name, and it reloads certificates automatically when those files change or on a SIGHUP. If your filter is the encrypted resolver, encryption stops being an argument against it.

The network's other window into traffic is closing too

Meanwhile the network's view of traffic is narrowing for reasons unrelated to DNS filtering. Encrypted Client Hello encrypts the Server Name Indication in the TLS handshake, so an intermediary sees an ordinary handshake carrying a generic shared name rather than the site being visited.

A DNS filter was never content inspection, and the ability to watch what people do on your network is fading by design. What remains is policy: deciding which names resolve, for which clients, and being open about it with the people who share the network.

A checklist that matches the tool to the job

None of this argues against running a DNS filter. It argues for pointing it at the work it is good at, and being explicit about where a second layer takes over.

• Write the goal down in one line before touching a blocklist. Malware and known-tracker domains, or in-page adverts? DNS handles the first well and the second badly.
• Serve encrypted DNS from your own resolver, with a real certificate, so encryption is a feature of your setup rather than a hole in it.
• Do not leave the resolver open. AdGuard's guidance warns that a publicly reachable instance may be exposed to DDoS, recommends allowlist mode where the clients are known, notes that the default plain-DNS rate limit should generally be sufficient, and suggests disabling plain DNS once every client can speak an encrypted protocol.
• Pair it with a second filtering layer where devices support one, such as a browser content blocker. AdGuard's own recommendation is to run DNS filtering in addition to network filtering, not instead of it. Network filtering is AdGuard's term for the regular way its standalone applications process network traffic.
• Measure the outcome, not the counter. Blocked-query totals prove activity; the useful test is whether the specific thing you wanted stopped actually stopped.

Limits, recovery and what we would do next

Two limits deserve stating out loud. First, you have put name resolution — the thing every device needs before it can do anything — behind a service you now maintain. Have a documented second resolver, know how to point the network back at it, and test that fallback before you need it. Second, an over-broad blocklist breaks things quietly, and usually for someone else, so keep an allowlist and a low-friction way for the household to report a broken site.

What we would do next is unglamorous: stop tuning lists, and spend an hour writing down what you actually want blocked and how you would know it worked. Most filtering frustration is a mismatch between a domain-level tool and a page-level goal, and no amount of extra lists closes that gap. If a content blocking proxy does arrive in AdGuard Home, judge it then on evidence rather than on the roadmap.

Sources and limits

This article synthesises the sources below into a practical explanation. It is not a security standard, legal advice, or a guarantee that guidance current at review time still applies — check the review date above against your own situation.

1. AdGuard Home overview — AdGuard. Describes AdGuard Home as network-wide software for blocking ads and tracking, designed to run on the user's own machine for more control over DNS traffic.
2. DNS filtering — AdGuard. Explains that DNS filtering acts at the earliest stage of a request, blocks whole domains via a blackhole response, can address CNAME-cloaked tracking, is coarse and applies no cosmetic filtering, cannot distinguish between apps, and should be used in addition to network filtering rather than instead of it.
3. AdGuard Home FAQ — AdGuard. States that AdGuard Home cannot block YouTube and Twitch ads or sponsored posts on Facebook, X and Instagram, because any ad sharing a domain with content cannot be blocked by a DNS-level blocker unless the content is blocked too, and that a content blocking proxy is the alternative.
4. DNS encryption in AdGuard Home — AdGuard. Documents that AdGuard Home can serve DNS-over-HTTPS, DNS-over-TLS, DNS-over-QUIC and DNSCrypt, requires a certificate from a CA or Let's Encrypt with a fullchain and private key file plus a matching server name, and reloads certificates automatically on change or on SIGHUP.
5. Setting up AdGuard Home securely — AdGuard. Warns that a publicly accessible instance may be exposed to DDoS attacks, recommends allowlist mode where the set of clients is known, describes the default plain-DNS rate limit of 20, and advises disabling plain DNS when every client can use an encrypted protocol.
6. RFC 8484 - DNS Queries over HTTPS (DoH) — IETF. Defines DNS-over-HTTPS and states that filtering or inspection systems relying on unsecured transport of DNS will not function in a DNS-over-HTTPS environment because of the confidentiality and integrity protection provided by TLS.
7. DNS over HTTPS (aka DoH) — The Chromium Projects. States that Chrome's auto-upgrade approach does not change the DNS provider and is designed to preserve the existing user experience, that split-horizon setups should continue to work, that managed deployments are automatically opted out and administrators can control the feature by policy, and that users can configure DoH providers of their choosing.
8. Encrypted Client Hello (ECH) — Cloudflare. Describes Encrypted Client Hello as a TLS extension that encrypts the Server Name Indication so intermediaries observing the traffic see ordinary TLS handshakes carrying a generic shared name rather than the site actually being visited.

More from Server Attic

• 2026-07-18

  A backup is not a restore plan

  A practical home-server guide to turning backup jobs into evidence you can actually recover from, using restore drills, integrity checks and clear limits.

• 2026-07-17

  Before you paste that into an AI chat

  A practical data-confidentiality guide for anyone about to paste a document, email or dataset into a general AI chat tool — what actually counts as sensitive, what happens to it next, and where the UK's data protection guidance sits.

• 2026-07-24

  Keep your AI agent on a short leash

  Why the real risk of an AI agent is the authority you hand it, not the model going rogue — and a practical way to turn down its functionality, permissions and autonomy separately.