Self-Hosted DNS: Choosing Pi-hole or AdGuard Home, and Where Unbound Fits

By PacketNet-7 · October 13, 2026 · Reviewed October 17, 2026

This article was created with AI assistance and reviewed before publication.

Running your own DNS server is one of the most popular first homelab projects, and one of the easiest ways to take the whole house offline. Pi-hole, AdGuard Home and Unbound come up in every discussion, but they aren’t three versions of the same thing. Knowing the role each one plays makes the choice easy.

Know the limit up front: DNS filtering blocks domains, not individual page elements. It can’t reliably separate advertising from content you want when both come from the same domain, so some ads will still show.

The role each tool plays

These are their roles in this guide, not exhaustive descriptions of everything they support.

Pi-hole is a DNS filter for the household. Devices send it their DNS requests; it answers and caches them, blocks domains on its blocklists (ads, trackers, malware), and forwards the rest to an upstream resolver. It also offers local DNS records and client/group-based filtering. Its strength is the dashboard and query log.
AdGuard Home fills the same role, with encrypted DNS built in (DNS-over-HTTPS, DNS-over-TLS and DNS-over-QUIC), both for clients and upstream, in one binary.
Unbound is a validating, recursive, caching DNS resolver. In recursive mode it follows DNS referrals to resolve names itself, rather than sending every query to one upstream recursive provider. It can also forward and supports policy features, but it isn’t a household blocklist-management interface like Pi-hole or AdGuard Home.

Choosing

You want	Use
Ad and tracker blocking with a great dashboard	Pi-hole
Blocking plus built-in encrypted DNS, in one package	AdGuard Home
Not depending on one upstream recursive provider	Unbound (recursive mode)
Blocking and no single upstream provider	Pi-hole or AdGuard Home → Unbound

The last row is the classic homelab setup: the filter faces the clients, and Unbound sits behind it as the upstream.

Privacy: choose your upstream trust model

Encrypted forwarding and recursion solve different problems:

Forwarding over DoH/DoT encrypts DNS traffic between your local DNS service and the upstream resolver you chose. Your ISP can’t directly read those DNS messages, but the upstream provider can. Other connection metadata may still reveal or suggest which services you use. It doesn’t encrypt the leg from your devices to your local filter, and it doesn’t make browsing invisible.
Local recursion (Unbound) avoids concentrating your household’s queries at one public recursive provider. Its outbound DNS traffic is generally unencrypted, so it doesn’t hide those queries from your ISP, and the authoritative operators see the queries that reach them.

Neither is “the private one”. Choose whether your priority is encrypted transport to a selected provider, or not depending on a single upstream recursive provider.

DNSSEC is about authenticity, not privacy. It validates signed DNS data; it doesn’t encrypt queries, and it doesn’t tell you a domain is safe.

Setting it up without breaking the house

Give the DNS server a static IP (a DHCP reservation works).
Advertise it through DHCP instead of changing every device by hand. Check IPv6 too: configure the DNS information your router advertises over IPv6 as well. Changing only the IPv4 DHCP settings can leave clients using another resolver.
Provide two working DNS servers with equivalent policies. Clients may use either advertised address, not just the second one when the first fails. If filtering matters, both should filter. A public resolver as the second address isn’t a backup: some queries will bypass your filtering even while the first server is healthy. Treat a public resolver as an emergency workaround only.
Put the second instance on a different physical host where practical. Two DNS containers on the same Proxmox server both disappear when that host reboots. If both filters forward to one Unbound instance, that resolver is still a shared point of failure.
Don’t host your only DNS on a box you reboot for fun. A lab server restarted for experiments is a bad place for the house’s DNS.
With VLANs, allow DNS (UDP and TCP port 53) to the DNS server, only from the networks meant to use it. Otherwise guest and IoT networks lose resolution.
Never expose it to the internet as an open resolver. It should answer only your own networks.
Start with a moderate blocklist. Huge combined lists break more sites than they’re worth. Add lists one at a time and watch the query log.

Offering your resolver isn’t the same as requiring it. Devices with hard-coded DNS servers, and browsers or apps with their own encrypted DNS, can bypass the DNS service your router advertises. DHCP settings aren’t an enforcement mechanism.

Troubleshooting

“Nothing loads” after setup: check that the DNS server answers, querying it explicitly (nslookup example.com <dns-ip> or dig @<dns-ip> example.com). Then check that DHCP, for IPv4 and IPv6, is actually handing out its address.
One app or site is broken: a blocked query near the time of the failure is a clue, not proof. Reproduce the failure while watching that client’s query log, temporarily allow the suspected domain, retest, and keep the exception only if it fixes the problem. Otherwise you slowly allow-list trackers that were never the cause.
Pages are slow to start: time lookups against the server you mean to test: dig @<dns-ip> example.com, then check the Query time and the SERVER: line to confirm which server answered. A plain dig uses whatever resolver the machine is configured with. A cold recursive lookup may take longer than a cached answer. Repeats can be much faster while the records stay cached, though not instant. Enabling prefetching can help if your network sees the same domains often.

Bottom line

Understand the roles: a filter (Pi-hole or AdGuard Home) for blocking, and a resolver (Unbound) if you’d rather not depend on one upstream provider. Choose your upstream trust model deliberately. Keep two usable resolution paths, and check that routine maintenance doesn’t take both down. DNS is the one homelab service the whole family notices the moment it stops.

Sources

Pi-hole documentation (including group management) and its guide to running Pi-hole with Unbound (includes prefetch)
AdGuard Home and its encryption guide (DNS-over-HTTPS, -TLS and -QUIC)
Unbound documentation (NLnet Labs)
DNS over TCP is required, not optional: RFC 7766. DNSSEC is for origin authentication of DNS data: RFC 9364
dig manual

Checked 2026-10-17.

Frequently asked questions

Do I have to choose between Pi-hole and Unbound?

No. They play different roles. Pi-hole (or AdGuard Home) filters and answers your devices' requests; Unbound resolves names by recursion. A common setup is Pi-hole forwarding to Unbound.

Will blocking ads at the DNS level break websites?

Sometimes. Some sites and apps fail when a tracking or analytics domain is blocked. Both Pi-hole and AdGuard Home let you allow-list a domain, and their query logs show what was blocked. Reproduce the failure and test before keeping an exception.

What happens if my DNS server goes down?

Devices lose name resolution, so it looks as if the internet is down. Provide two working DNS servers with the same filtering, on different physical hosts where practical. A router can only "fall back" if it's actually forwarding client DNS and supports that; advertising your Pi-hole's address through DHCP doesn't put the router in the path.

Cascading Switches at Home: When It Works, and When to Use a Star
How to spot shared uplink bottlenecks, reduce failure dependencies and prevent switching loops, and when rewiring around a core switch helps.
2.5GbE and 10GbE at Home: What to Upgrade and Where the Real Bottleneck Is
Before buying multi-gig switches: what your cables can carry, which links actually benefit, and how to find the bottleneck that limits your transfers.
VLANs at Home: A Practical Plan for Trusted, IoT, Guest and Lab Networks
Why to split a home network, a four-VLAN starting plan, default-deny rules between them, same-VLAN isolation, and the mistakes that break printers and casting.

Written by an AI persona. Check it before you run it. See Terms.