Adblock and DNS: choosing a filter to run myself

Created 2026-10-12

What I use today

My starting point is a filtering DNS service. I wanted to find out whether a filter I run myself would add blocking, or whether control over lists, exceptions and query logs would be the more useful gain.

The test server could not reach that service, so I used an unfiltered public resolver as the upstream for both candidate runs and the controlled baseline. I measured the current filtering service separately over a different network path. Its blocking results provide a reference; its timing is not comparable with the candidate runs.

If I forward a local filter’s queries to a filtering provider, I keep both layers. A local filter can block additional domains, but its allow rules cannot undo a block returned by the upstream. Replacing that upstream’s filtering and adding a filter in front of it are different choices. The AdGuard Home configuration documentation explains upstream forwarding and routing selected domains to a different resolver.

The tools

I used the Community Scripts Adblock and DNS category as the candidate list on 2026-10-10. It contained ten entries, including two synchronization add-ons and two scripts marked as testing. Category membership identifies what I review; it does not mean every entry solves the same problem.

The table summarizes the desk review dated 2026-10-10. Resource figures are the scripts’ default Debian allocations, not measured consumption. Network-wide filtering assumes devices use the chosen DNS service. Versions describe the upstream projects; a testing label describes the Community Scripts installer.

I shortlisted AdGuard Home and Pi-hole because both directly address filtering with a UI, while using different implementations. Technitium remains a plausible choice for a wider DNS role; Blocky remains a plausible choice for file-based administration. The stable installer repository and development installer repository document the installation side of this comparison.

Results

On 2026-10-10 I tested the two shortlisted tools in temporary containers with a fixed list of known ad/tracker and normal domains: 100 in each group, versioned 2026-10-10. Normal domains included content delivery, authentication and other service endpoints that should remain reachable. I used A queries and two passes per resolver. This small, selected sample measures DNS behavior; it does not measure how many ads disappear from web pages.

The sample favors Pi-hole. The 100 ad/tracker domains were selected from StevenBlack hosts, which was also Pi-hole’s only enabled list. Its 100% raw blocking result is close to built in. AdGuard Home’s 98% used the separate AdGuard DNS filter and is the more independent result on this sample. These figures do not establish general blocking superiority.

I queried each resolver explicitly. The controlled baseline used the same unfiltered public upstream as both candidates, from the same test client. Only 79 ad domains resolved there in the first pass and 80 in the warm pass; I excluded the remaining 21 and 20 errors from candidate-only credit. All 100 normal domains resolved at that baseline. Errors, including timeouts, remained separate from blocks.

Each timing cell gives median / p95 in milliseconds, with its sample count in parentheses. Candidate cold means its own cache was cleared; the upstream’s cache remained outside my control. The baseline first pass is therefore unverified, rather than a cold measurement.

The reference rows are a separate blocking observation, not the candidates’ upstream baseline. They show the filtering DNS service already blocked all 80 ad domains that resolved at the unfiltered upstream in the warm pass. Neither candidate added coverage over the current filtering service on this set. Any reason to host one is control over lists, per-client rules and logs. The reference had one normal-domain timeout in each pass, involving different domains; neither was counted as a false block.

AdGuard Home’s one ad-domain error in each pass was a response without an address, also excluded by the upstream baseline. Its unblocked, upstream-resolving ad domain accounted for the remaining difference. Both candidates resolved all 100 normal domains. I would need a larger, independently selected sample to assess false blocks or coverage beyond this result.

I measured idle resources more than five minutes after the last query. RSS measures the DNS process; container memory is a broader measure. Both containers had one CPU, 512 MB allocated RAM and 2 GB allocated disk. Installer duration excludes the extra configuration needed to reach a working filter; working-filter times are approximate.

I tested AdGuard Home v0.107.79 with the AdGuard DNS filter and Null IP blocking. I tested Pi-hole core v6.4.3, web v6.6 and FTL v6.7.1 with StevenBlack hosts only and NULL blocking. Both used the same unfiltered upstream. DNSSEC stayed on for AdGuard Home and off for Pi-hole, following their defaults, so these timings describe the tested configurations rather than an isolated comparison of DNS engines.

I cleared AdGuard Home’s cache through its API and Pi-hole’s cache by restarting its DNS process. Candidate-cold normal lookups had a 28 ms median; warm replies had a 0 ms median and 1 ms p95. Blocked replies were also local and measured 0 / 1 ms. I kept these timings separate so a filter answering more local blocks would not appear faster at normal lookups. Zero milliseconds reflects the timing tool’s integer-millisecond resolution.

I ran one comparison per candidate on one date. Encrypted upstream transport, IPv6 AAAA queries, per-client rules and deployment behind a router were not tested. Integration fit remains reasoning rather than a demonstrated deployment. The temporary containers were removed after the test.

What I learned

• AdGuard Home: Defaults changed the experiment before performance did. In this test, adblock-style rules returned REFUSED until I selected Null IP mode; its default per-client rate limit also shapes a benchmark. A refusal or a throttled query needs interpretation before it becomes a blocking score. I measured 59 MB idle process RSS and 523 MB used disk, with about three minutes to a working filter.
• Pi-hole: The installer needed attention: it asked yes/no prompts and picked defaults I would review. I answered the prompts for this temporary test; those defaults need deliberate configuration before a lasting deployment. Its 100% raw blocking result was expected because the test domains came from its enabled StevenBlack list. It used less process memory here, 9 MB RSS, but more disk, 611 MB, and took about four minutes to reach a working filter.
• Unbound: A resolver is not automatically an ad blocker. Full recursion removes a central forwarding provider, but it still exchanges queries with authoritative servers; query-name minimization limits disclosure. The project overview explains this distinction.
• PowerDNS: I need to judge the component the installer actually deploys. An authoritative nameserver does a different job from filtering a client’s DNS lookups.
• nebula-sync: I found a configuration replicator in the same category as the resolvers. It becomes relevant after choosing Pi-hole and deciding to run more than one instance.
• AdGuardHome-Sync: I would consider this for multiple AdGuard Home instances, not as a competing DNS filter.
• NextDNS CLI: Running a client locally does not make the filtering service self-hosted. The cloud service remains responsible for resolving and filtering queries.
• CoreDNS: I can build DNS behavior from plugins, but its default installer configuration does not deliver the filtering job I am comparing.
• Blocky: I can get a focused filter with versioned configuration files. Whether I prefer that to a UI is an administration choice rather than a blocking score.
• Technitium DNS: I can combine filtering with a broader DNS server, but that expands the scope beyond adding a filter.

Decision

Decision (2026-10-10): I keep the filtering DNS service I already use and don’t host a filter. All three resolvers blocked 98-100% of a sample drawn from one list, so this test can’t rank their coverage; it only shows that a local filter would add nothing I could measure here. The verdict rests on control and running cost instead: the service I use already filters with no false blocks on this sample and costs me no service to maintain.

What would change the verdict: wanting per-device rules, my own block lists and exceptions, or a query log I control. Then I would pick AdGuard Home: one binary with a UI and the more independent result here (98% with its own list). Its documentation lists encrypted upstreams (DNS-over-HTTPS and DNS-over-TLS); I didn’t test them. Pi-hole is the close second, and the better fit if I want its ecosystem of lists.

What adopting one would change:

Running either long term is a separate change with its own plan; this comparison only measured them.