Pi-hole does a great job of stopping specific domains you don’t want. For most people, after installing it and watching the block number climb, they assume all the important elements of privacy are covered. However, this isn’t entirely true. For queries Pi-hole can’t answer from its own cache or local configuration, it still needs somewhere else to resolve them. But the split between filtering and the actual resolution rarely gets any attention. Knowing this makes your half-setup more conspicuous but also easy to complete.

Pi-hole filters your queries, but usually doesn’t resolve them

Pi-hole decides; the upstream resolver replies

Pi-hole first checks whether it already has an answer cached and whether the requested domain should be blocked. If it isn’t blocked and there isn’t a usable local answer, Pi-hole forwards the query to whichever upstream DNS server you’ve configured.

Whatever address occupies the Upstream DNS Servers field receives the query. For most setups that I’ve come across, this field usually contains Cloudflare, Google, Quad9, or the ISP’s resolver. Once Pi-hole hands over the query, it waits for a reply; it doesn’t resolve the name itself. For a cache miss that isn’t blocked, the path is device → Pi-hole → upstream resolver → answer → device.

Gravity decides which queries are allowed, and the upstream field answers the query. Interestingly, some people treat Pi-hole as a complete private DNS resolver, but its standard setup still forwards unresolved queries to an upstream resolver. The half-setup starts becoming visible when you pay attention to the Upstream DNS Servers field.

The encryption protecting the pipe doesn’t protect the plumber

Cloudflare or Google is still on the other end of the line

As a privacy fix, most people may turn on DNS-over-HTTPS or DNS-over-TLS. Adding DoH or DoT through a local proxy encrypts the connection between that proxy and the public resolver. Pi-hole can still perform the filtering first, but the public resolver remains the party receiving the queries that Pi-hole allows through.

Although limited, the data this resolver receives is still useful. It wouldn’t see the page content, but it sees domain names, timing, and request patterns from your network. Once ads and trackers are removed, the list of domain names and timing can be sufficient to create a picture of the local network’s activity.

Even though the hand-off is encrypted, there is still a hand-off. If your goal is to stop giving one company the DNS queries your network forwards, encrypting the pipe doesn’t change who receives them.

Unbound removes the provider

The root servers answer directly now — no single company in between

Unbound is a validating, recursive, caching resolver. In simple terms, it performs the recursion itself instead of forwarding queries to a third-party recursive resolver. Unbound takes over the job normally performed by the public upstream. Pi-hole still filters first, and the rest of the experience — blocking, the dashboard, and the day-to-day — remains the same.

Pi-hole hands over all queries that pass through gravity and are not already in the cache to Unbound. A simplified first-resolution path can look like device → Pi-hole → Unbound → root/TLD/authoritative servers → back through Unbound → Pi-hole → device. With Unbound now tracing the chain from top to bottom, the forwarded queries aren’t all handed to a single third-party recursive resolver; the network now does its own resolving.

With this change, Unbound’s local cache answers the repeat lookups, and it stays fast. Also, enabling DNSSEC (Domain Name System Security Extensions) validation in the Pi-hole Unbound configuration is recommended to ensure bogus responses can be rejected rather than passed on to the client.

There’s still a metadata trail — and a reason you might still want to forward

It’s important to know the true scale of this upgrade. Unbound changes who gets the complete query history. However, that’s different from hiding the existence of the DNS traffic. Your ISP can still see that the network is sending DNS queries; it can observe destinations and timings for those connections.

For practical day-to-day use, the main cost is in first-time lookups. For these, Unbound may need to perform full recursive resolution since there may not be a warm cache at a large public resolver. This may mean first answers take a bit longer. However, this delay disappears once the relevant records are cached.

It’s also worth pointing out that some ISPs, captive networks, or managed networks may interfere with or block direct recursive DNS traffic. For these, the more reliable choice may still be forwarding to a trusted public resolver.

So what you may want to do is open Pi-hole’s upstream DNS settings. If you see a public resolver listed there, Pi-hole is still forwarding allowed queries to that provider. Pointing Pi-hole at a local Unbound instance moves the recursive work onto your own network instead. However, a local Unbound instance means your network is performing the recursive resolution locally, rather than sending it to an external provider.