After setting up Pi-hole with Unbound as a recursive DNS resolver, I wanted to verify that the configuration was actually working as intended. The goal was simple: prove that every device on the network stays anchored to the Pi-hole cluster and never falls back to the ISP or leaks queries to third-party DNS providers.

What DNS leaks are and why they matter

A DNS leak occurs when your device sends DNS queries to servers you didn’t configure, bypassing your intended DNS resolver. This can happen for several reasons: misconfigured network settings, VPN failures, or devices falling back to default resolvers when your primary DNS server appears unavailable.

When DNS queries leak, they expose your browsing behavior to whoever operates those DNS servers. Your ISP can see every domain you look up, even if you’re using a VPN or privacy-focused DNS setup. Third-party DNS providers like Google can track your queries, build profiles of your internet activity, and potentially sell that data or use it for advertising.

For a homelab running Pi-hole with Unbound, DNS leaks defeat the entire purpose of the privacy-focused setup. If queries are leaking to your ISP or public DNS providers, you’re not getting the privacy benefits you configured. You’re also not getting the ad blocking and local DNS control that Pi-hole provides.

The baseline configuration

Before running leak tests, I verified the baseline configuration on both the workstation and the Pi-hole servers themselves.

On macOS, scutil --dns shows the Wi-Fi interface pinned to the Pi-hole cluster addresses:

resolver #1
  nameserver[0] : 10.0.20.12
  nameserver[1] : 10.0.20.13
  if_index : 7 (en0)

The Pi-hole servers themselves have their resolv.conf configured to use the same pair, creating a redundant setup where each Pi-hole can resolve queries through Unbound independently.

When I ran dig example.com from both the workstation and the Pi-hole servers, the queries returned the same Akamai edge IPs with SERVER: 10.0.20.12#53 in the response. This confirmed that queries were reaching the Pi-hole cluster, but it didn’t prove that leaks weren’t happening elsewhere in the resolution chain.

External verification methods

To verify that no leaks were occurring, I used several external verification methods that check different aspects of DNS resolution.

Cloudflare trace endpoint

Cloudflare’s cdn-cgi/trace endpoint reports information about the connection, including whether you’re using Cloudflare’s DNS services. When I queried https://1.1.1.1/cdn-cgi/trace from both the workstation and the Pi-hole servers, the response showed warp=off and gateway=off, confirming that we weren’t using Cloudflare’s DNS or WARP services. The response also showed colo=SJO, indicating the Cloudflare data center location, which matched expectations for our geographic region.

DNS leak test websites

Web-based DNS leak test tools provide a comprehensive view of which DNS servers are actually resolving your queries. I used dnsleaktest.com and browserleaks.com to verify that all DNS queries were going through the Pi-hole cluster and exiting through our ISP’s network, not through third-party DNS providers.

These tools perform multiple DNS lookups and report which resolver IPs answered the queries. The results showed only our ISP’s DNS resolver IPs, confirming that queries were exiting through our ISP’s network rather than Cloudflare, Google, or any other third-party DNS provider. If queries were leaking to external DNS providers, the test results would have shown their resolver IPs instead.

This was the key verification: the resolver IPs matched our actual internet service provider, not a third-party DNS provider. The ASN information in the test results also matched our ISP’s ASN, providing additional confirmation that no leaks were occurring.

Resolver identity queries

To verify that queries are actually going through the local Pi-hole and Unbound resolvers, I used resolver identity services that echo back the IP address of the resolver making the query. These services include whoami.akamai.net and o-o.myaddr.l.google.com.

When I ran dig whoami.akamai.net without specifying a resolver (which uses the system’s configured DNS), the response showed our ISP’s IP address. This confirmed that the query went through Pi-hole, through Unbound’s recursive resolution, and exited through our ISP’s network. If the query had leaked to a third-party DNS provider, the response would have shown that provider’s resolver IP instead.

The key is running these queries without the @ flag, which forces dig to use your local DNS configuration. Using @1.1.1.1 or @8.8.8.8 would bypass your local DNS entirely and tell you nothing about whether your Pi-hole setup is working correctly.

Cloudflare help page

Cloudflare’s diagnostic page at https://1.1.1.1/help provides detailed information about your DNS configuration. When I accessed this page, it confirmed that we weren’t using Cloudflare’s DNS services and showed our actual resolver information. This page is particularly useful because it provides a clear, human-readable summary of your DNS setup and can help identify misconfigurations.

Testing methodology

To verify DNS leak protection comprehensively, I tested from multiple vantage points:

Local workstation testing: Verified that scutil --dns showed only the Pi-hole cluster IPs, confirmed that dig queries were answered by the Pi-hole servers, and checked that DNS leak test websites and resolver identity queries reported the expected ISP information.

Pi-hole server testing: Verified that the servers themselves were configured correctly and that queries from the servers also showed the expected ISP ASN when checked through external endpoints.

VLAN testing: Tested from devices on different VLANs (workstation on VLAN 10, servers on VLAN 20) to ensure that DNS configuration was consistent across network segments and that no VLAN-specific misconfigurations were causing leaks.

Multiple query types: Tested with different domain types (common domains, CDN domains, international domains) to ensure that resolution behavior was consistent regardless of the query type.

The key insight is that DNS leak testing requires checking multiple indicators, not just one. A single test might miss leaks that only occur under specific conditions. By combining local resolver checks, dig server verification, and external ASN/ISP verification, you can get confidence that your DNS setup is working as intended.

The results

No leaks were detected. Both the workstation and the VLAN 20 Pi-hole servers resolve exclusively through the Pi-hole primary cluster, and the upstream trace matches the ISP’s ASN instead of Cloudflare, Google, or any unexpected third-party DNS provider.

The verification confirmed that:

• All devices are using the Pi-hole cluster as their DNS resolver
• No queries are leaking to ISP DNS servers or third-party providers
• Unbound is performing recursive resolution correctly
• The privacy benefits of the Pi-hole plus Unbound setup are actually working

This verification process gave me confidence that the DNS infrastructure is providing the privacy and control benefits I configured it for. Without this testing, I would have been assuming the setup was working correctly without actually verifying it.

Why this verification matters

Setting up Pi-hole with Unbound is only half the work. Verifying that the setup is actually working as intended is just as important. DNS leaks can be subtle and hard to detect without specific testing, and misconfigurations can persist for months or years without being noticed.

Regular verification after network changes helps catch configuration drift and ensures that your privacy-focused DNS setup continues to provide the benefits you configured it for. The verification process itself is straightforward once you understand what to check, and it provides valuable confidence that your infrastructure is working as intended.

For a homelab environment, this kind of verification is especially valuable because you’re often making changes to network configuration, adding new services, or modifying firewall rules. Each change has the potential to introduce DNS leaks, so having a verification process helps catch issues before they become long-term problems.

The peace of mind that comes from knowing your DNS queries aren’t leaking to third parties is worth the time spent on verification. Privacy-focused infrastructure only works if it’s actually working, and verification is how you confirm that it is.