The most surprising thing about Pi-hole’s DNS over TLS (DoT) is that it’s not about encrypting your own DNS queries from your ISP, but rather securing the upstream DNS queries Pi-hole makes on your behalf to your chosen DNS provider.
Let’s see Pi-hole DoT in action. Imagine you’ve set up Pi-hole, and it’s happily blocking ads. Now, you want to encrypt the requests Pi-hole sends out to the internet to resolve domain names. You’d go to your Pi-hole’s web interface, navigate to Settings -> DNS, and under "Upstream DNS Servers," you’d check the boxes for your preferred DoT providers, like Cloudflare (1.1.1.1) or Google (8.8.8.8). You’d also ensure "Use DNSSEC" is checked, as DoT inherently supports DNSSEC validation.
Here’s a snippet of what the Pi-hole configuration (/etc/pihole/setupVars.conf) might look like after enabling DoT for Cloudflare:
PIHOLE_DNS_1=1.1.1.1
PIHOLE_DNS_2=1.0.0.1
DNS_SEC=1
DNS_OVER_TLS=cloud1.1.1.1#cloudflare-dns.com
Notice DNS_OVER_TLS=cloud1.1.1.1#cloudflare-dns.com. The format is IP_ADDRESS#HOSTNAME. The IP address is the upstream server, and the hostname is the SNI (Server Name Indication) used during the TLS handshake, which tells the server which TLS certificate to present. This is crucial for shared DoT servers.
The problem Pi-hole’s DoT solves is the vulnerability of plain DNS queries. When your Pi-hole needs to resolve example.com and it sends a standard UDP/53 query to an upstream DNS server, that query is sent in clear text. Anyone on the network path between your Pi-hole and the upstream server (your ISP, a coffee shop’s Wi-Fi router, etc.) can see which domains you’re querying. By enabling DoT, Pi-hole establishes a TLS connection to the upstream DNS provider. This encrypts the DNS query and its response, making it unreadable to anyone snooping on the connection. It also provides authentication, ensuring Pi-hole is talking to the genuine upstream server and not an imposter.
The mental model here is a secure tunnel. Your Pi-hole is like a traveler needing directions. Instead of shouting the request across the street (plain DNS), it uses a secure, encrypted phone line (DoT) to call a trusted information booth (the DoT-enabled upstream DNS provider). The information booth then sends the directions back through the same secure line. This prevents anyone from overhearing your travel plans.
The exact levers you control are the choice of upstream DoT providers and ensuring the correct hostname is specified for the TLS SNI. Pi-hole uses dig and openssl under the hood to manage these connections. If you’re troubleshooting, you can manually test a DoT connection from your Pi-hole’s command line:
echo "q: google.com" | openssl s_client -connect 1.1.1.1:853 -servername cloudflare-dns.com
This command attempts a TLS connection to 1.1.1.1 on port 853 (the standard DoT port), presenting cloudflare-dns.com as the SNI. If successful, you’ll see certificate information and then the query result.
A common point of confusion is the difference between DoT and DNSSEC. While both enhance DNS security, DoT encrypts the transport of the query, while DNSSEC provides authentication of the DNS data itself, verifying that the response hasn’t been tampered with. Pi-hole supports both, and enabling DoT typically goes hand-in-hand with enabling DNSSEC for maximum security.
The next concept you’ll likely encounter is understanding how Pi-hole handles conditional forwarding and custom DNS records in conjunction with DoT, especially when dealing with local network name resolution.