Pi-hole Meets Unbound: Network-Wide Ad Blocking and Truly Private DNS

Browser ad blockers are good, but they only protect the browser. Your smart TV, your phone’s apps, the various gadgets quietly phoning home across your network, none of them benefit from an extension you installed on a laptop. Pi-hole solves this at the source by blocking unwanted domains for every device on your network at once. Pair it with Unbound and you go a step further, resolving DNS yourself rather than trusting a third party with the record of every site you visit. This guide builds that combination, explains why each piece matters, and is candid about the gotchas. If you have ever cleared a DNS cache to fix a stubborn lookup, you already understand more of this than you think.

How DNS-Based Ad Blocking Works

Every time a device loads a web page, it asks a DNS resolver to translate human-friendly names like ads.example.com into IP addresses. Ordinary content arrives from one set of domains, while advertisements, trackers, and telemetry arrive from a largely separate, well-known set. That separation is the whole trick.

Pi-hole acts as the DNS resolver for your network. When a device asks for a domain on a blocklist, instead of returning the real address Pi-hole returns nothing useful, so the connection to the advertiser or tracker simply never happens. The page still loads, but the slot where the ad would have appeared stays empty because the browser could not reach the ad server in the first place.

Because this happens at the DNS layer rather than inside a browser, it is application-agnostic. Apps, consoles, televisions, and background services all use DNS, so all of them get filtered. The cost is precision: DNS blocking works on whole domains, so it cannot strip a single advert from a page served by the same domain as the content. It is a blunt instrument, but a remarkably effective one.

This is the same mechanism I describe in DNS sinkholing to block malware domains — the difference is only the blocklist. Point a sinkhole at ad domains and you get an ad blocker; point it at command-and-control and phishing domains and you get a security control. Pi-hole happily does both at once, because to the resolver a bad domain is a bad domain regardless of why you decided to block it.

Installing Pi-hole

Pi-hole runs happily on a Raspberry Pi, an old PC, or a virtual machine, on most Debian-based Linux distributions. The official installer is a single command:

1

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

The installer asks a few questions: which upstream DNS provider to use temporarily, which blocklists to start with, and whether to enable the web admin interface. Accept the defaults for now; we will replace the upstream provider with Unbound shortly. When it finishes, it prints the admin password and the address of the dashboard.

Give the machine a static IP address before you go further, either in the host’s network configuration or as a DHCP reservation on your router. Pick something out of your DHCP pool range — say 192.168.1.53, a nod to DNS’s port 53. A DNS server that changes address is a DNS server that breaks your whole network the moment it moves. Once that is settled, log in to http://192.168.1.53/admin and you will see queries already flowing if anything on the box is making lookups.

One habit worth forming now: pin the version of anything you self-host and read the release notes before upgrading. Pi-hole’s move to v6 changed the config file format and the API, and people who ran a blind pihole -up in the middle of that transition had a bad afternoon. This box becomes load-bearing infrastructure the moment your router points at it, so treat upgrades as maintenance windows, not idle tinkering.

Pointing Your Router at Pi-hole

Pi-hole only blocks for devices that actually use it. The cleanest way to enrol every device is to set Pi-hole as the DNS server in your router’s DHCP settings, because then every device that joins your network is handed Pi-hole’s address automatically.

Log in to your router, find the DHCP or LAN settings, and set the primary DNS server to your Pi-hole’s static IP. Resist the urge to add a public DNS server like a big provider’s address as a secondary, because devices will sometimes prefer the secondary and quietly bypass all your filtering. If you want redundancy, run a second Pi-hole rather than pointing the backup at an unfiltered resolver.

After changing the router, devices pick up the new DNS server when their lease renews. To test immediately, reconnect a device to the network or renew its lease, then watch the Pi-hole dashboard light up with its queries.

Blocklists

Pi-hole ships with a sensible default blocklist, and for many people that is enough. The dashboard shows what proportion of queries it is blocking, which is oddly satisfying to watch.

You can add more lists under Adlists in the admin interface, pasting in the URL of any well-maintained list. The temptation is to add dozens of aggressive lists, but restraint pays off: huge, overlapping lists slow things down and dramatically increase the chance of blocking something you actually wanted, like a login button that depends on a tracking domain. Start conservative, live with it for a week, and only add more if you genuinely see ads getting through.

When something breaks, the Query Log is your friend. It shows exactly which domain was blocked, so you can whitelist it with a click and get on with your day.

Why Add Unbound

Pi-hole decides whether to block a domain, but it still has to resolve the domains it allows, and by default it forwards those lookups to an upstream provider. That means a third party still sees every site you choose to visit. You have blocked the trackers but handed your browsing history to whoever runs your upstream resolver.

Unbound closes that gap. It is a recursive DNS resolver, which means instead of asking another company, it talks directly to the authoritative servers that own each domain, starting from the internet’s root servers and walking down. The result is that no single upstream provider sees the full picture of your queries, you are not relying on anyone’s logging promises, and Unbound validates DNSSEC so you get tamper-evidence on the answers it returns.

The trade-off is a touch more latency on the first lookup of a fresh domain, because Unbound does the legwork itself rather than asking a resolver that already knew the answer. In practice its cache makes repeat lookups fast, and the privacy gain is the whole point.

Installing and Configuring Unbound

Install Unbound on the same machine as Pi-hole:

1
2

sudo apt update
sudo apt install -y unbound

Create a configuration file at /etc/unbound/unbound.conf.d/pi-hole.conf with a recursive setup that listens only on the local machine:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19

server:
    verbosity: 0
    interface: 127.0.0.1
    port: 5335
    do-ip4: yes
    do-ip6: yes
    do-udp: yes
    do-tcp: yes
    prefer-ip6: no
    harden-glue: yes
    harden-dnssec-stripped: yes
    use-caps-for-id: no
    edns-buffer-size: 1232
    prefetch: yes
    num-threads: 1
    so-rcvbuf: 1m
    private-address: 192.168.0.0/16
    private-address: 10.0.0.0/8
    private-address: 172.16.0.0/12

Restart Unbound and confirm it resolves:

1
2

sudo systemctl restart unbound
dig @127.0.0.1 -p 5335 vo.rs

A sensible answer with a NOERROR status means recursion is working. Now tell Pi-hole to use it. In the admin interface, under Settings to DNS, untick every public upstream provider and add a custom upstream of 127.0.0.1#5335. Save, and from this point Pi-hole sends every allowed lookup to your own recursive resolver. You are now blocking ads and resolving the rest privately, entirely within your own four walls.

Testing and Gotchas

To confirm blocking works, browse to a site you know carries adverts and watch the dashboard register blocks. To confirm Unbound is in the loop, run the dig command above and note that the first lookup of an unfamiliar domain is a little slower than a repeat, which is recursion doing its job.

Now the honest caveats. The biggest is that you have created a single point of failure: if the Pi-hole box dies, every device that depends on it loses DNS and the internet appears broken until you fix it or fail over. Plan for that with a second resolver or a documented recovery, and never casually reboot the machine in the middle of a household video call.

The second gotcha is that some software refuses to play along. Certain apps and devices hardcode their own DNS servers, ignoring whatever your router hands out, and an increasing number use DNS-over-HTTPS to tunnel lookups past local resolvers entirely. Some browsers enable encrypted DNS by default, which quietly sidesteps Pi-hole. You can mitigate this by disabling DoH in your browser settings and, on more capable routers, blocking outbound connections to known public DNS servers so devices are forced back to Pi-hole. A firewall rule that redirects all outbound port-53 traffic to the Pi-hole, and drops outbound 853 (DoT) and known DoH endpoints, is the heavy-handed but effective option.

The third is DNSSEC validation failures. Once Unbound is validating signatures, a domain with a broken or expired DNSSEC chain will fail to resolve for you even though it “works” for everyone on a permissive public resolver. This is Unbound doing its job — the answer really is untrustworthy — but it looks like your setup is broken. Check with dig +dnssec and look for the SERVFAIL status and the absence of the ad (authenticated data) flag before you blame Unbound. Nine times out of ten it is the remote domain that has misconfigured its keys, not you.

A related trap: don’t run your own DoH resolver and Unbound in a way that double-encrypts or loops. If you want encrypted DNS reaching the house from outside, that is a separate layer — I cover it in running your own DoH resolver at home — and it sits in front of Pi-hole, not behind Unbound. Keep the layers straight in your head or you will spend an evening chasing a resolution loop.

For everything that does cooperate, which is the overwhelming majority, the payoff is immediate: a quieter, faster, more private network where every device benefits from a single, tidy piece of infrastructure you fully control.

Is it worth it?

For anyone who runs their own network and cares about either privacy or ad load, unreservedly yes. The Pi-hole half pays off in an afternoon and delights the whole household; the Unbound half is a smaller, quieter win that matters mostly if you are uncomfortable handing your full browsing history to whichever resolver your ISP or a big provider runs. If you have never so much as reserved a static lease, the single-point-of-failure risk is real and you should build the recovery plan before you point the router — a broken resolver breaks everything, and the person who fixes it at 11pm is you. But if you already run a homelab and are comfortable with a machine your network depends on, this is one of the highest-satisfaction-per-hour projects on the whole self-hosting menu. Cheap, private, and every device benefits without installing a thing.