Unbound Recursion vs Cloud DoH on a Pi-hole: When Home DNS Becomes the Outage

The recommended hardening after a Pi-hole weekend is Unbound. Recurse from the roots. Stop sending every name to 1.1.1.1. Feel like a grown-up. Then a Tuesday arrives when the roots are fine, your ISP is filtering outbound UDP 53 to anyone but their own resolvers, and the house decides the internet is dead. Chrome is not dead. Your recursive resolver is. Cloud DoH would have worked. Your privacy lab just became the outage.

Unbound versus Cloudflare-or-NextDNS-on-the-Pi-hole is not a purity contest. It is a question about which failure you prefer: a vendor seeing query names, or a living room that cannot resolve netflix.com because a Pi could not finish a chain from the root.

What Unbound is actually doing

Pi-hole filters. Someone still has to recurse or forward. If you point Pi-hole at Unbound on localhost, Unbound talks to root servers, then TLD servers, then the name’s nameservers. The first lookup is slower. The cache makes the next one fast. Nobody at Cloudflare gets a log line for mail.yourbank.example. That is the win people want.

The win has costs that tutorials skip. You now depend on reaching many IPs on port 53, on DNSSEC validating correctly, on root hints that are not ancient, and on a process that can fork and cache without the SD card going read-only. You also still leak SNI and destination IPs to the ISP when someone visits a site. Recursion is not a cloak. It is a smaller DNS observer set.

I like Unbound. I run it. I also keep a measured fallback because I have been the person explaining to a partner that “the internet” failed because I wanted cleaner query privacy on a residential fiber that quietly broke recursion. The partner did not want a lecture on root servers. They wanted the TV to find the app store. That sentence is the SLA.

If you cannot explain Unbound’s first-query delay in one breath, do not deploy it as the only resolver the week guests arrive. Deploy it on a Tuesday and watch the query log for SERVFAIL, not only for blocked ads.

The Unbound outages I have actually hit

ISP captive resolvers. Some networks allow outbound 53 only to the ISP’s own anycast. Unbound cannot walk the roots. Every name fails or hangs. Pi-hole’s graph is empty. Phones show “connected, no internet.” Forwarding to 1.1.1.1 over DoH on 443 would have bypassed the filter. Recursion cannot. If you travel the Pi, or you are on a university or hotel uplink, Unbound is a paperweight. Even at home, a “security” firmware update can start this filter. Test from the Pi: dig a root, dig a TLD, dig a leaf. If only the ISP resolver answers, you are not ready for recursion as the only path.

DNSSEC is a site-shaped outage. A mis-signed zone, a clock skew on the Pi, or a middlebox that truncates DNSSEC payloads will make Unbound SERVFAIL. The site is up. Your house is not. Cloud resolvers sometimes fail open or already have an opinion. Unbound is stricter if you configured it that way. Strict is good until it is a kid’s homework portal. Learn delv and do not immediately disable DNSSEC because one name is broken. Also do not leave the Pi’s clock on a failed NTP path. Time is part of DNS now.

Cold cache after a reboot. The first ten seconds after a power blip feel like a slow network. People reboot the router. The Pi is still walking roots. A cloud DoH forwarder has a warm anycast cache. If your household’s patience is four seconds, you will get blamed for Unbound even when it is working. A larger cache and not rebooting the DNS box for fun helps. So does not putting DNS on the same Pi you tinker with nightly.

IPv6 half-stack. Unbound prefers AAAA paths you did not finish. Broken IPv6 plus happy-eyeballs on clients plus a recursive resolver that believes v6 is fine is a night of “only some sites.” Force the story: v4-only Unbound, or a working v6. A maybe is an outage.

The disk and the process. Unbound is light until the card is not. A wedged Unbound is a house-wide failure if it is the only upstream Pi-hole has. Two Unbounds, or Unbound plus a DoH forwarder as secondary, is the same conversation as two Pi-holes. One recursive resolver on an SD card is a hobby.

What cloud DoH on the Pi-hole actually costs

You send query names to a company. You gain a path over 443 that looks like HTTPS, a cache that is always warm, and an operator who is not you. NextDNS and Cloudflare both have blocklists you can abuse instead of gravity. That can duplicate Pi-hole or fight it. Pick one policy engine.

DoH from the Pi to the cloud does not stop Chrome on a laptop from doing its own DoH to someone else. You still need the client fight I wrote about in the Pi-hole versus AdGuard piece. Recursion does not win that fight either.

The privacy story is “Cloudflare does not see my LAN hostnames if I split DNS correctly, but they see the rest.” Unbound’s story is “nobody in that set sees the rest, unless I leak DoH from browsers anyway.” Be honest about browsers before you claim Unbound achieved privacy.

A hybrid that fails loud instead of quiet

Pi-hole primary upstream: Unbound on localhost. Pi-hole secondary: nothing, or a DoH proxy you can disable. If Unbound dies, I would rather the house fail closed so I notice, unless I am away. When I am away, a VPS-side Healthchecks probe on a name resolution from the house tells me DNS died. If I cannot have that, a DoH fallback that is documented is better than a partner who enables phone Private DNS and never tells me.

Some people put Unbound first and 1.1.1.1 second in Pi-hole. Devices will skip to the second when Unbound is slow. That undoes recursion for the lookups you cared about and keeps Unbound for the ones that were easy. I do not like that as a privacy design. I like it as an availability design if I say it out loud. Write the sentence: “I will leak to Cloudflare when Unbound is sad.” If you cannot say it, do not configure it.

A cleaner hybrid: Unbound at home when the path to the roots works. A travel profile or a second Pi-hole upstream list that is DoH-only when you detect ISP filtering. That is more automation than most households need. A note on the router that says “if DNS dies, switch Pi-hole upstream to Cloudflare” is enough if you can reach the admin UI without DNS. That last clause is why you bookmark an IP, not a name.

When Unbound is the right default

You have tested outbound 53 to the world. You have two instances or a DoH escape you accept. You monitor Unbound, not only Pi-hole HTTP. You update root hints on a calendar. You do not reboot the DNS host for compose experiments. You understand DNSSEC well enough to debug one SERVFAIL without nuking validation.

When those are true, Unbound is a good default. The query privacy is real for the traffic that actually uses the Pi. The cache is yours. The failure modes are yours too, which is the point of a homelab if you staff it.

When cloud DoH is the adult default

You are on an ISP that already broke recursion. You travel the resolver. You will not maintain two Unbounds. The household SLA is “it just works” and you are the only DNS person. Pay NextDNS or use Quad9/Cloudflare and keep Pi-hole for the list. You still have more privacy than sending every client to the ISP’s resolver in the clear, and you are less likely to be the outage.

There is no shame in this. Shame is how people leave Unbound as the only path on a filtered network and then disable Pi-hole entirely after a fight. A working filter on Cloudflare is still a filter. A broken recursive resolver is a story about principles that nobody in the living room agreed to.

The close

Unbound makes the Pi-hole a recursive resolver. That is a privacy improvement and a new way to take the house down. Cloud DoH makes the Pi-hole a filtered stub to a vendor. That is a privacy leak and a way to survive an ISP that will not let you walk the roots.

Test the walk. Bookmark the Pi by IP. Monitor port 53. Decide in writing whether a second upstream is a leak you accept. Home DNS becomes the outage when it is the only path and the path is your hobby. Treat it like the router, or stop being surprised when the living room votes to use 8.8.8.8 and your gravity list dies with your principles.