Standard DNS queries travel across the network in plaintext, meaning anyone positioned to observe that traffic — your ISP, or an attacker who’s successfully performed the ARP spoofing — can see every domain you’re resolving, even if the actual website connection itself is encrypted via HTTPS. DNS-over-HTTPS and DNS-over-TLS close this specific privacy gap by encrypting the DNS queries themselves.
Why Plaintext DNS Is a real Privacy Gap
Even with every website you visit using HTTPS, the DNS lookup preceding that connection — translating a domain name into an IP address — traditionally happens over plain, unencrypted UDP, visible to anyone monitoring network traffic between you and your DNS resolver. This creates a real metadata leak: even without seeing page content, an observer can build a complete picture of every domain you’ve queried.
DoH vs DoT: Two Approaches to the Same Goal
- DNS-over-HTTPS (DoH) – wraps DNS queries inside standard HTTPS traffic on port 443, making DNS queries essentially indistinguishable from regular web browsing traffic at the network level
- DNS-over-TLS (DoT) – uses a dedicated port (853) specifically for encrypted DNS, keeping DNS traffic identifiable as DNS (just encrypted) rather than blending in with general web traffic like DoH does
Neither is universally “better” — DoH’s blending-in property can be advantageous for privacy against network-level DNS blocking, while DoT’s dedicated port makes it easier for network administrators to specifically identify and manage DNS traffic separately from general browsing.
Configuring DoH/DoT Forwarding in Pi-hole
Building on the Pi-hole setup , Pi-hole itself doesn’t natively speak DoH/DoT to upstream providers without an additional component — typically cloudflared running alongside it, translating Pi-hole’s standard DNS queries into encrypted DoH queries sent to Cloudflare or another supporting provider:
sudo apt install cloudflared -yConfigure cloudflared to listen locally and forward to a DoH endpoint, then point Pi-hole’s upstream DNS setting at this local cloudflared instance rather than directly at a plaintext upstream server.
Configuring DoH in Technitium DNS Server
Technitium () includes native DoH/DoT forwarding support directly in its settings, without needing a separate helper tool like cloudflared — configure the upstream forwarder URL as a DoH endpoint directly under Technitium’s DNS settings, a genuinely simpler setup path compared to Pi-hole’s reliance on an additional component.
Configuring DoT in Unbound
For the Pi-hole with Unbound setup () specifically, Unbound’s own recursive resolution to root servers doesn’t typically use DoH/DoT itself, since it’s directly querying authoritative servers rather than forwarding to a single upstream provider — DoH/DoT specifically applies to the forwarding scenario (querying a single upstream resolver), not full recursive resolution against the DNS hierarchy directly.
Browser-Level DoH: A Separate Consideration
Independent of your homelab’s DNS infrastructure, modern browsers (Firefox and Chrome specifically) increasingly enable DoH by default, potentially bypassing your carefully configured Pi-hole or Technitium DNS server entirely and sending queries directly to a browser-configured DoH provider instead — worth explicitly checking and disabling in browser settings if you want browsing traffic to actually respect your local DNS infrastructure (and its ad-blocking) rather than bypassing it via browser-level DoH.
The Interaction with Split-Horizon DNS
If you’ve implemented split-horizon DNS (), ensure whatever DoH/DoT forwarding you configure applies specifically to your upstream forwarding (queries your local server can’t answer itself), not to internal queries that should still resolve to your local, internal IP addresses — the encryption applies to the upstream leg of resolution, not to your own local DNS server’s authoritative answers for your own internal domains.
Performance Considerations
DoH and DoT add a small amount of latency compared to plaintext DNS, due to the TLS handshake overhead, though this is typically negligible in practice given DNS response caching (already handled by Pi-hole, Technitium, or Unbound themselves) means most repeat queries never actually need to hit the encrypted upstream connection at all.
Verifying Encrypted DNS Is Actually Working
Confirm your DNS queries are truly being encrypted rather than silently falling back to plaintext, using online DNS leak test tools, or by directly inspecting traffic to confirm DNS queries aren’t appearing as plaintext UDP traffic on port 53 leaving your network toward your upstream provider.
Final Thoughts
Setting up DNS-over-HTTPS and DNS-over-TLS closes a real, often-overlooked privacy gap in an otherwise well-secured homelab network — encrypting the DNS metadata that would otherwise remain visible even with every other connection properly encrypted. Combined with Pi-hole or Technitium’s existing ad-blocking and the network segmentation covered throughout this series, encrypted DNS forwarding rounds out a really privacy-conscious home network setup.
Leave a Reply