Most Pi-hole setups leak your browsing to your ISP — here's the encryption layer that stops it

At a glance:

• Most Pi-hole setups only block ads and trackers locally but don't encrypt DNS traffic, allowing ISPs to see browsing activity
• DNS-over-HTTPS (DoH) can close this privacy gap, but Cloudflare's proxy solution was deprecated in late 2025
• A self-hosted dnscrypt-proxy solution can encrypt DNS traffic alongside Pi-hole for complete privacy

The Pi-hole Privacy Gap

Pi-hole has become one of the most popular privacy-focused local solutions for a cleaner browsing experience. When users set up their homelab servers, they often implement Pi-hole to get a complete privacy solution. The main focus is typically on fewer ads, trackers, and better control over their network. A clean Pi-hole setup effectively solves the ad and tracker problem, but once users start digging into how DNS actually works, they notice the setup is missing something crucial.

Pi-hole blocks and filters everything locally, but as soon as traffic leaves the network, the view of what's happening becomes completely visible. From the router to the ISP, or any intermediary in between, every DNS request made by devices is exposed, including the websites and services being accessed. This means that while Pi-hole prevents unwanted content from loading, it doesn't hide what users are trying to access from their internet service provider or other network observers.

Understanding DNS Limitations

Pi-hole is easy to set up and works well for most users who just need ad and tracker blocking. Users only need to set it up once, add it as their DNS, and can forget about it. Pi-hole intercepts each domain request a device makes, cross-checks it against the blocklist, and then lets it pass. This works for most users because it provides a cleaner, faster browsing experience, and the story seemingly ends there.

However, this is where the misunderstanding begins. Pi-hole doesn't change how DNS works; it's merely a watchman. When a device requests a domain, it passes through the Pi-hole, which decides whether to block the request or forward it. Once Pi-hole clears the domain, it forwards the request upstream to a DNS resolver. For most users, that upstream communication is handled via standard DNS (usually on port 53), which is not encrypted. Pi-hole does an excellent job of filtering the requests it resolves, but it doesn't hide what's leaving the network. Some might confuse Pi-hole's filtering with what DNSSEC does, but DNSSEC only ensures that responses are delivered without tampering - the request and response remain safe but not private.

The Privacy Most Users Overlook

Your ISP can still see everything about your DNS requests, even with Pi-hole in place. Pi-hole blocks bad requests, but it doesn't encrypt traffic. Once requests leave the network, they are still sent in plain text. Your ISP can see those plaintext messages and what your device has requested, such as the websites visited and the services used. While they can't see the content of those requests, like specific pages or full URLs, they can see what services are used, when you're online, and how frequently certain platforms are accessed.

Many people argue that public resolvers, such as Cloudflare and Google DNS, will solve this problem. However, they don't. You're simply changing the resolver to a public DNS provider, but not how the traffic travels or whether it's encrypted. You're moving from the standard DNS resolver to a public provider; the process remains the same, and the path remains unsecured. Pi-hole can clean up what you connect to, but it still falls short of hiding it from your ISP or any intermediary. This distinction matters more than most people realize for maintaining true privacy.

The Solution: DNS-over-HTTPS

When faced with this privacy gap, the obvious solution is to implement DNS-over-HTTPS (DoH), which encrypts DNS queries within HTTPS traffic. This prevents ISPs and intermediaries from seeing what domains are being queried. However, the implementation isn't always straightforward. Many users initially consider Cloudflare's DNS over HTTPS proxy, which was a popular solution, but it was deprecated in late 2025, leaving users to find alternatives.

Rather than settling for another cloud-based alternative, the author chose to implement a self-hosted solution that could work alongside Pi-hole. This approach maintains the local filtering capabilities of Pi-hole while adding an encryption layer for upstream traffic. The goal was to keep the existing Pi-hole setup intact while addressing the privacy vulnerability in the DNS resolution process.

Implementing dnscrypt-proxy

The author deployed dnscrypt-proxy alongside Pi-hole via Portainer on Docker, creating a local encryption layer. Running the proxy was straightforward, though not as simple as many tutorials suggested. Initially, the author tried configuring it using a .toml file, but this failed due to resolver source issues. Switching to environment-based configuration via Docker Compose environment variables proved more reliable than TOML configuration.

With dnscrypt-proxy in place, Pi-hole continued its role of blocking ads and trackers, while dnscrypt-proxy handled how queries were sent upstream. Instead of plain DNS over port 53, all DNS traffic was now wrapped inside HTTPS. This meant that everything leaving the network looked like regular traffic, but it was actually encrypted. After setting it up, the author simply replaced Pi-hole's upstream DNS servers with dnscrypt-proxy#5053 (or 127.0.0.1#5053), requiring no additional per-device configuration since the DNS was already updated in the dual-WAN gateway.

Trade-offs and Considerations

There was one trade-off the author noticed after setting up the solution. Since dnscrypt-proxy was hosted on the local server, if the server went down, DNS would go down with it. Two potential solutions emerged: either add another Pi-hole with dnscrypt-proxy on another server, or add a publicly available DNS provider as a fallback. Both solutions presented some difficulty in the author's case, but the goal was to keep the network usable most of the time, even if that meant sacrificing strict privacy during server outages.

This highlights an important consideration in implementing privacy solutions: there's often a balance between complete privacy and network reliability. For users who prioritize constant connectivity over absolute privacy, a fallback to a public DNS provider might be necessary. However, for those who prioritize privacy and can tolerate occasional downtime, a fully self-hosted solution provides the highest level of protection.

Conclusion

Pi-hole works exactly as advertised - it blocks ads and filters out requests, but it was never designed to be a complete privacy solution. It works locally and blocks connections, but it doesn't control who can see those connections once they leave the network. Adding DNS-over-HTTPS fills that gap and encrypts connections. With Cloudflare's DNS over HTTPS proxy no longer available, implementing this protection required a self-hosted approach using dnscrypt-proxy.

This small upgrade changes what the network actually exposes to ISPs and intermediaries. While it requires a bit more technical setup than simply using Pi-hole alone, the privacy benefits are significant. For users serious about protecting their browsing activity from their ISP and other observers, this layered approach provides a comprehensive solution that maintains Pi-hole's ad-blocking benefits while adding crucial encryption for DNS traffic.