Pi-hole and Unbound: Network-Wide Ad Blocking Done Properly

Overview

I ran Pi-hole for a year before adding Unbound, and the difference isn't what I expected. It's not that ads suddenly stopped — Pi-hole handles those fine on its own. It's that every DNS query in the house stops going to Google, Cloudflare, or my ISP, and I can see exactly what every device on the network is trying to reach.

Here's the setup, and the parts that took me longer than they should have.

Pi-hole alone vs Pi-hole + Unbound

	Pi-hole alone	Pi-hole + Unbound
DNS upstream	Cloudflare / Google / ISP	Root servers directly
Query logging by third party	Yes	No
Setup complexity	Low	Medium
Latency for uncached queries	~10ms	~50–100ms first time
Latency for cached queries	~1ms	~1ms

The latency difference only shows up on cache misses, which after a few days of running are a small fraction of queries. In practice I can't tell the difference.

Hardware and install

This will run on anything. A Pi Zero 2 W is enough. A Pi 3 or 4 is more than enough. If you're already running Home Assistant on a Pi, you can add Pi-hole as an addon — but I'd recommend running it on separate hardware, because when HA reboots, your whole network loses DNS and everyone in the house notices.

The official install script handles everything:

curl -sSL https://install.pi-hole.net | bash

Follow the prompts. When it asks about upstream DNS, pick anything for now — you'll change it to Unbound in the next step. Set a static IP on the Pi itself before running the installer; Pi-hole bakes the address into its config.

Adding Unbound

sudo apt install unbound

Pi-hole's documentation provides a config file that's known to work. It's worth fetching it rather than writing your own — the root hints, DNSSEC settings, and rate limiting have been tuned over years:

sudo curl -o /etc/unbound/unbound.conf.d/pi-hole.conf \
  https://raw.githubusercontent.com/pi-hole/docs/master/docs/guides/unbound.md

That URL is actually the doc page, not the config. The actual config lives in the same doc under a code block. Either copy it manually, or use this minimal version:

server:
    verbosity: 0
    interface: 127.0.0.1
    port: 5335
    do-ip4: yes
    do-ip6: no
    do-udp: yes
    do-tcp: yes

    root-hints: "/var/lib/unbound/root.hints"
    harden-glue: yes
    harden-dnssec-stripped: yes
    use-caps-for-id: no

    cache-min-ttl: 3600
    cache-max-ttl: 86400

    prefetch: yes
    num-threads: 1
    so-reuseport: yes
    msg-cache-size: 50m
    rrset-cache-size: 100m
    cache-max-negative-ttl: 60

    private-address: 192.168.0.0/16
    private-address: 10.0.0.0/8
    private-address: 172.16.0.0/12

remote-control:
    control-enable: no

Fetch the root hints file:

sudo curl -o /var/lib/unbound/root.hints \
  https://www.internic.net/domain/named.cache

sudo systemctl restart unbound
dig @127.0.0.1 -p 5335 example.com

If dig returns an answer with status: NOERROR, Unbound is working. Now point Pi-hole at it: in Settings → DNS, uncheck every upstream server and set Custom 1 (IPv4) to 127.0.0.1#5335. Save.

Point your devices at it

Two approaches:

Change DNS in your router's DHCP settings. Every device that gets an address from DHCP uses Pi-hole. This is the correct way. Devices with hardcoded DNS — smart TVs, some streaming sticks — will bypass it, but most won't.

Block outbound DNS at the router. Add a firewall rule that drops UDP 53 from any client except the Pi-hole. This forces hardcoded-DNS devices through Pi-hole anyway. It's the only way to catch a Chromecast that's trying to use 8.8.8.8 directly.

The second is worth doing. Before I added it, my smart TV was bypassing Pi-hole entirely and I had no idea until I looked at the query log and noticed the TV's IP wasn't showing up.

The lists: what to actually block

Pi-hole's default blocklist is small. The community-maintained lists are what makes it useful:

List	What it blocks
StevenBlack/hosts	Ads, trackers, malware — well maintained
OISD (Basic)	Lighter list, fewer false positives
Hagezi's lists	Tiered by aggressiveness; "Normal" is a good starting point

Start with one list. Add a second only if you're finding things getting through. Every additional list increases the chance of breaking a legitimate service, and "why doesn't my app work" is a much more annoying problem than "I saw one ad."

Hagezi's Normal list is what I'd recommend for a first-timer. StevenBlack's list catches more, but occasionally blocks things you need — the Reddit app, some email tracking pixels in transactional emails.

Debugging: the query log is the whole story

Every DNS query in your house is logged, with the client that requested it. This is the part that makes Pi-hole genuinely valuable beyond ad blocking.

When a device won't connect to something:

Go to Query Log in the Pi-hole admin
Filter by the client's IP
Look for blocked entries right before the failure

Nine times out of ten you find the domain that needs whitelisting. Add it, and it works.

# Bulk whitelist from the CLI
pihole -w domain1.com domain2.com domain3.com

# Bulk blacklist
pihole -b tracker.example.com

# Update gravity (re-fetch blocklists)
pihole -g

Things that will surprise you

Your phone on cellular data isn't covered. Pi-hole only sees DNS queries that go through your home network. When you're on 4G, ads come back. Solutions exist — running Pi-hole on a VPS and connecting via WireGuard or Tailscale — but that's a different project.

Some apps fail silently. An app that can't reach its analytics endpoint sometimes just... hangs. You'll blame the app, then realize Pi-hole blocked something it needed. This is why you keep the whitelist handy.

YouTube ads still get through. YouTube serves ads from the same domains as the videos. Blocking them requires different techniques entirely, and the ones that work break frequently. Don't set expectations based on YouTube.

Your router's DNS settings might get ignored. Some ISP-provided routers force their own DNS servers. You may need to disable "DNS Rebind Protection" or set the DNS in a different place than you'd expect. Check that clients are actually using Pi-hole by looking at the query log — if it's empty except for the Pi itself, this is why.

Was it worth it?

Yes, mostly for the visibility. The ad blocking is nice, but seeing which of my devices phones home to which analytics service is what actually changed how I set up my network. Half the "smart" devices in my house were quietly talking to endpoints I didn't recognize.

If you just want fewer ads, a browser extension does most of that for free. Pi-hole is for the network-level view.