Network DNS filtering in 2026: revisit Pi-hole, AdGuard Home and Blocky before you hand out another resolver over DHCP

Most teams think about DNS only when it breaks. Yet every laptop, phone, build agent and smart TV on an office or home network asks a resolver thousands of questions a day, and many of those answers lead to trackers, ad networks and the occasional malware domain. A network-level DNS filter answers those questions on your own box, blocks what you do not want, and gives you a query log that is often the fastest way to see what a device is really doing.

In this post we revisit three active open-source options: Pi-hole, AdGuard Home and Blocky. We look at history, licences, architecture, operations, hardening and how to pick one. This is not a ranking. No benchmark or hands-on drill was run for this post; the facts come from each project’s own repository, licence files and release notes as of early November 2026. This post is about filtering resolvers for clients, not authoritative DNS; we covered CoreDNS, PowerDNS and BIND 9 in an earlier post.

Why revisit DNS filtering now

• Pi-hole core v6.5 and FTL v6.8 were both released on 17 October 2026. The v6 line, first released on 18 February 2025, was the biggest change in the project’s life, so many older install guides on the internet no longer match what you get today.
• AdGuard Home v0.107.80 was released on 3 November 2026 (IST), mainly a dependency and Go toolchain security update.
• Blocky v0.35.0 was released on 5 September 2026 (IST), adding a per-client response metric, a “refused” block type and a fix so DNSSEC records are not returned to clients that did not ask for them.

All three are maintained. The real question is which operating model fits your team.

Pi-hole: the one most people already know

History and licence

The Pi-hole repository was created in June 2014 and the name comes from the Raspberry Pi it was first built for. The core is licensed under the European Union Public Licence (EUPL), as stated in the project’s own LICENSE file. GitHub shows it as “NOASSERTION” because it does not auto-detect EUPL, so read the file yourself before your legal team asks.

Architecture

• The DNS engine is FTL, written in C and built on a fork of dnsmasq. It keeps statistics and the query database in SQLite.
• With v6, the web interface and a REST API are served by FTL itself. The older setup with a separate web server and PHP is gone, which means fewer moving parts but also a different upgrade path from v5.
• Blocklists (“adlists”) are pulled on a schedule into a gravity database. Groups let you apply different lists to different clients.
• It can also act as a DHCP server, which helps when the router cannot point clients to a custom DNS server.

Where it fits

Pi-hole suits a single site where a person wants a friendly dashboard, a big community and lots of existing blocklists. It is one stateful instance by default; running two for redundancy means keeping their configuration in sync yourself or with community tools.

AdGuard Home: one binary with encrypted DNS built in

History and licence

The AdGuard Home repository was created in July 2016 by AdGuard, a company that also sells commercial ad blocking products. AdGuard Home itself is GPL-3.0. The backend is Go and the web interface is TypeScript.

Architecture

• A single Go binary carries the resolver, filtering engine, web interface, query log and statistics. Configuration lives in one YAML file that the web interface also writes to.
• It can serve clients over plain DNS, DNS-over-HTTPS, DNS-over-TLS and DNS-over-QUIC, and can use encrypted upstreams too. This is its strongest point if you want phones outside the office to use your filter through an encrypted endpoint.
• Per-client settings, blocked services lists, parental and safe search options, and an optional DHCP server are built in.

Where it fits

AdGuard Home suits teams that want encrypted DNS without wiring extra proxies, and like a single binary they can drop on a small VM. Like Pi-hole it is one stateful instance; a second instance needs its config copied across.

Blocky: config as code, stateless and metrics first

History and licence

Blocky was started in November 2019 and is written in Go under the Apache-2.0 licence. It has no admin web interface of its own; you manage it through a YAML file and an API.

Architecture

• Everything is in one YAML file: upstream groups, block and allow lists, client groups, conditional forwarding and caching. That file can live in Git and go through review like any other config.
• It exposes Prometheus metrics, so dashboards and alerts sit in Grafana with the rest of your stack rather than in a separate UI.
• The query log can go to a database such as MySQL or PostgreSQL, or to files, instead of being tied to the resolver host.
• Multiple instances can share cache and blocking state through Redis, which makes running two or more behind a virtual IP or in Kubernetes much simpler.
• It supports encrypted upstreams and can serve DNS-over-HTTPS and DNS-over-TLS.

Where it fits

Blocky suits platform teams that already run Prometheus and GitOps and want the DNS filter to behave like any other stateless service. It is less friendly for a non-technical person who wants to click “allow this domain” on a phone.

The things to check whichever you pick

Redundancy

If the DNS filter is the only resolver handed out by DHCP and it goes down, the whole network “loses the internet”. Hand out two resolvers that both filter, never one filter and one public resolver, otherwise clients will quietly bypass the filter whenever the first is slow.

Never expose it as an open resolver

Bind the DNS port to internal interfaces or a VPN only. An open resolver on the internet gets abused for amplification attacks within days. Put the admin UI or API behind the VPN or a reverse proxy with authentication, and change the default credentials on first start.

Encrypted DNS on clients

Browsers and some apps may use their own DNS-over-HTTPS and skip your resolver. Decide a policy: either push managed browser settings, or accept that the filter is best effort. Filtering is a hygiene layer, not a security boundary.

Query logs are personal data

A DNS log shows which sites each person visits. Set a short retention, restrict who can read it, and tell people it exists. For Indian organisations, treat it with the same care you would give any personal data under the DPDP Act.

Blocklists break things

Aggressive lists will break login flows, payment pages and SaaS dashboards. Start with one well-maintained list, keep a documented allow list, and make sure someone can unblock a domain quickly during working hours.

Backups and upgrades

• Pi-hole: back up the gravity and FTL databases plus the config through its own Teleporter export, and read the v6 migration notes before upgrading a v5 box.
• AdGuard Home: back up the YAML config and the data directory. Its built-in updater is convenient but test new releases on a second instance first.
• Blocky: the YAML file in Git is the backup. Pin the container tag rather than using latest.

How to choose

• Pick Pi-hole for a single office or home network where a friendly dashboard and community support matter most, and you are fine with the EUPL.
• Pick AdGuard Home when you need encrypted DNS endpoints for clients out of the box and want one binary with a UI.
• Pick Blocky when DNS filtering should be config in Git, metrics in Prometheus and several stateless replicas behind one address.

Revisit checklist

• List which resolvers your DHCP server hands out today, and whether any of them bypasses filtering.
• Run two filtering instances and test that clients keep working when one is stopped.
• Confirm the DNS port is not reachable from the internet.
• Set query log retention and access rules, and write them down.
• Start with one blocklist and an allow list owned by a named person.
• Pin versions, subscribe to release notes, and keep a tested backup of the configuration.

DNS filtering is small, cheap and easy to forget. Revisit it once a quarter: read the release notes, check the logs you keep, and unlearn the habit of treating the resolver as a box nobody owns.