Mission Log

Pi-hole + Unbound: What They Do and Why They Replace Your ISP's DNS

Pi-hole blocks ads at the DNS level. Unbound resolves queries directly against root servers. Together they keep your DNS private and local.

Tools

Every device on your network makes dozens of DNS queries per hour. Every one of those queries tells someone — your ISP, Google, Cloudflare — exactly which domains you are visiting, when, and how often. Even if you are running HTTPS everywhere, your DNS traffic is a full record of your browsing behavior flowing to a third party you did not choose. Pi-hole and Unbound together let you take that back: filter out the junk at the network level and resolve the rest yourself, without an upstream provider watching.

TL;DR

  • Pi-hole is a network-wide DNS sinkhole that blocks ads and trackers before they resolve.
  • Unbound is a recursive DNS resolver that queries authoritative nameservers directly, cutting out upstream DNS providers.
  • Combined, they give you ad blocking and DNS privacy on every device on your network without installing anything per-device.
  • The privacy gain is real: no single third party sees your complete query history.

Why This Matters

DNS is the most under-secured layer in most home networks. You can run a VPN, encrypt every connection, and still hand your entire browsing history to your ISP’s default resolver or a public DNS provider.

Most people change their DNS to Google (8.8.8.8) or Cloudflare (1.1.1.1) and call it done. That is better than your ISP’s resolver in some ways — faster, more reliable — but you are still sending every query to a single company. You are trading one observer for another.

Pi-hole and Unbound give you a third option: handle DNS yourself. Block the queries you do not want at the network edge, and resolve the rest directly against the authoritative source. No middleman.

What Pi-hole Does

Pi-hole is a DNS sinkhole. It sits between your network clients and whatever upstream DNS resolver you configure, and it filters queries against blocklists before forwarding legitimate ones.

Here is how it works in practice:

  1. You configure your router (or individual devices) to use Pi-hole as the DNS server.
  2. When a device makes a DNS query, Pi-hole checks it against its blocklists.
  3. If the domain is on a blocklist (ad server, tracker, telemetry endpoint), Pi-hole returns a null response. The request never leaves your network.
  4. If the domain is clean, Pi-hole forwards the query to whatever upstream resolver you have configured.

The result: ads, trackers, and telemetry get blocked network-wide. Every device benefits — phones, tablets, smart TVs, IoT devices — without installing an ad blocker on each one. The devices that do not let you install an ad blocker (looking at you, smart TVs) are exactly where Pi-hole shines.

Pi-hole also gives you a clean admin dashboard for monitoring query traffic. You can see which devices are making the most queries, which domains are being blocked, and which upstream queries are getting through. That visibility alone is worth the setup.

How many of your devices are phoning home to telemetry endpoints right now? Pi-hole’s query log is an eye-opener the first time you look at it.

What Unbound Does

Unbound is a validating, recursive DNS resolver. Instead of forwarding your DNS queries to an upstream provider, it resolves them itself by walking the DNS hierarchy from the root servers down.

Here is the difference:

With a forwarding resolver (Google, Cloudflare, your ISP):

Your device -> Pi-hole -> Google (8.8.8.8)
                          Google queries root -> TLD -> authoritative
                          Google caches and returns the answer

Google sees every query you make. They promise to handle it responsibly. You trust that promise.

With Unbound as a recursive resolver:

Your device -> Pi-hole -> Unbound (local)
                          Unbound queries root -> TLD -> authoritative
                          Unbound caches and returns the answer

No single external entity sees your full query history. The root servers see that you asked about .com. The .com TLD servers see that you asked about example.com. The authoritative server for example.com sees your full query. But no one server sees everything. That is a meaningful privacy improvement.

Unbound also validates DNSSEC signatures, which protects against certain types of DNS spoofing attacks. It is not a privacy feature directly, but it adds integrity to the responses you receive.

Why Combine Them

Pi-hole and Unbound solve different problems, and they complement each other cleanly.

Pi-hole alone blocks ads and trackers but still forwards legitimate queries to whatever upstream resolver you configure. If that upstream is Google or Cloudflare, you still have a privacy gap.

Unbound alone gives you recursive resolution and privacy but does not block ads or trackers. You would need to maintain your own blocklists and filtering logic.

Together, the architecture looks like this:

LAN clients -> Pi-hole (filtering) -> Unbound (recursive resolution) -> root servers

Pi-hole handles the policy layer: what gets blocked, what gets through. Unbound handles the resolution layer: resolving allowed queries without leaking them to a third party. Each component does one thing well.

This is the setup that gives you both network-wide ad blocking and genuine DNS privacy. It runs entirely on your own hardware, and the only external communication is Unbound’s queries to authoritative nameservers — which is how DNS was designed to work in the first place.

Privacy: What You Actually Gain

Let’s be concrete about the privacy improvement.

Using Google/Cloudflare DNS: One company sees 100% of your DNS queries. They know every domain every device on your network resolves. They correlate that with your IP address, and in Google’s case, potentially with your Google account. Their privacy policies say they handle this data responsibly, and for most people that is probably fine. But it is still a full record of your network activity held by a third party.

Using Pi-hole + Unbound: No single external entity sees your complete query history. Root servers, TLD servers, and authoritative servers each see a fraction of each query. Your ISP cannot see your DNS traffic at all (though they can still see the IP addresses you connect to). The only complete record of your queries exists on your own Pi-hole, on your own hardware, under your own control.

The tradeoff: you are responsible for keeping it running. If Pi-hole or Unbound goes down, your network loses DNS resolution until you fix it or clients fall back to a secondary resolver. In practice, this is rare — both are lightweight and stable — but it is a real operational consideration.

There is also a latency consideration. The first query to a new domain takes slightly longer with Unbound because it is walking the DNS hierarchy instead of hitting a cached result at a large public resolver. After the first lookup, Unbound caches the result locally and subsequent queries are fast. For most homelab operators, the difference is unnoticeable.

Who This Is For

This setup is practical for:

  • Homelab operators who want network-wide ad blocking without per-device configuration.
  • Privacy-conscious users who want to stop sending DNS queries to third-party providers.
  • Parents who want a basic content filtering layer (Pi-hole supports custom blocklists).
  • Anyone with IoT devices that cannot run local ad blockers and phone home aggressively.

It runs on minimal hardware. A Raspberry Pi handles it easily. A Docker container on an existing server works just as well.

Summary

  • Pi-hole filters DNS queries against blocklists, blocking ads and trackers at the network level before they ever resolve.
  • Unbound resolves allowed queries recursively, querying authoritative nameservers directly instead of forwarding to a third-party provider.
  • Combined, they give you ad blocking and DNS privacy: no single external entity sees your complete query history.
  • The setup runs on minimal hardware and benefits every device on your network without per-device configuration.
  • The tradeoff is operational responsibility — you maintain your own DNS infrastructure, and if it goes down, your network feels it.

What’s Next?

If you want to run this stack in a Docker-based homelab behind a reverse proxy, the next step is wiring it into your existing infrastructure. For a walkthrough of running Pi-hole + Unbound behind Traefik with a clean admin redirect, see our integration guide.

Are you running Pi-hole with a different upstream resolver, or have you tried Unbound on its own? What blocklists are you running, and have you found any that cause more breakage than they are worth? Share your setup — DNS configs are one of those things where every network is slightly different.