How to Block DNS-over-HTTPS (DoH) on Your Network to Enforce Pi-hole

A banner ad for cheap flights appeared below the search bar. Pi-hole was running, blocklists were current, and the query log showed nothing. That silence was the giveaway: the browser had quietly switched its DNS to HTTPS, tunneling queries through port 443 where Pi-hole—listening on port 53—couldn't see them. The fix isn't chasing every browser with a settings toggle. It's closing the hole at the network so DoH can't leave the house without permission.

Why DoH Breaks Pi-hole (and Why "Just Disable It in the Browser" Isn't Enough)

DNS-over-HTTPS wraps a DNS query inside a standard HTTPS connection. To a firewall or a Pi-hole sitting on port 53, the traffic looks identical to a website visit. The query goes straight from the browser to a DoH resolver—Cloudflare's 1.1.1.1, Google's 8.8.8.8, or any of a growing list—without ever touching the local DNS server. Pi-hole never gets a chance to inspect, filter, or block anything.

Browser defaults make this worse because they're inconsistent and opportunistic. Firefox enables DoH by default in several regions, using Cloudflare as the resolver and falling back to system DNS if the DoH server is unreachable. Chrome and Edge check whether the system resolver is already blocking certain domains, and if not, they may silently upgrade to DoH while keeping the same provider. Neither browser asks permission. Neither warns the user when the switch happens.

Disabling the setting on a single device feels like control, but it's whack-a-mole. Guests arrive with their own laptops. A smart TV update resets network preferences. An IoT sensor ships with DoH baked into its firmware and no settings menu. A family tablet gets a browser update that re-enables the "secure DNS" toggle. Trusting every device on the network to behave isn't a strategy. Enforcement belongs at the router.

The Strategy: Block, Redirect, and Deceive

Closing the DoH bypass requires more than one rule. Applications that want encrypted DNS are persistent—they probe, retry, and fall back through a chain of options until something works. A single block gives them a target to work around. A layered approach removes the options one by one.

The first layer blocks known DoH servers at the IP level. Firewall rules prevent any device from reaching the public addresses of major DoH providers on port 443. The second layer catches the sibling protocol, DNS-over-TLS, by hijacking outbound port 853 traffic and redirecting it to Pi-hole. The third layer poisons the DNS bootstrap step by returning NXDOMAIN for the domains applications use to discover DoH servers. When all three layers fail, a fourth blanket rule locks down outbound DNS entirely so no device can reach any external resolver except through Pi-hole.

No single method is bulletproof. Hardcoded IPs bypass domain blocks. New providers bypass IP lists. Sophisticated clients retry on different ports. But layering these defenses turns DoH from a silent bypass into a series of obstacles that, for the vast majority of devices, ends in surrender back to plain DNS where Pi-hole can do its job.

Step 1: Identify and Block Known DoH Servers

The most direct approach stops the traffic before it reaches the internet. Most public DoH resolvers have well-known IP addresses that don't change frequently. Create a firewall alias containing them, then block outbound traffic from the LAN to that group on port 443.

The major targets include:

The firewall rule is simple: source is the LAN subnet, destination is the DoH alias group, destination port is 443, action is drop or reject. On OPNsense, this works as a floating rule or a LAN rule assigned early in the processing order—the same approach used when you isolate IoT devices with aliases and schedules. On a Linux router using nftables, a single rule with an ip set does the same job.

There's a trade-off worth naming. Blocking Cloudflare's 1.1.1.1 on port 443 also prevents reaching the Cloudflare website and any other service hosted behind that address. For a home network, this collateral damage is usually invisible and acceptable. If someone needs to reach a site hosted on one of these IPs, an exception rule for specific source devices handles it without opening the hole for DNS.

Building the DoH Destination List

Static IP lists rot. Providers add new addresses, retire old ones, and sometimes reassign them to unrelated services. Public blocklists on GitHub track DoH server IPs and update periodically. Some firewall distributions can ingest these lists automatically as URL table aliases. For those that cannot, a quarterly manual review against an updated list catches most drift. The goal isn't to block every possible DoH endpoint on the internet—it's to block the ones an average browser or device will try by default.

Step 2: Hijack DNS-over-TLS (Port 853)

While DoH hides inside HTTPS on port 443, DNS-over-TLS uses a dedicated port: 853. Many devices that support encrypted DNS will try DoT as a fallback when DoH fails. A NAT redirect rule on the router catches any TCP traffic headed to port 853 and diverts it to Pi-hole's IP address on port 53.

The rule works like this: any packet from the LAN with a destination port of 853 gets its destination rewritten to the Pi-hole's IP, still port 53. The client initiates what it thinks is a DoT handshake, receives a plain DNS response instead, and in most cases abandons the DoT attempt and retries with unencrypted DNS.

This is a blunt instrument. Pi-hole cannot perform a proper DoT handshake, so the initial connection always fails from the client's perspective. Well-behaved clients fall back to port 53. Poorly behaved ones log errors and may keep retrying, generating noise in logs. Legitimate DoT use—say, a device configured to use a trusted resolver over TLS for privacy—breaks entirely. For a home network where the goal is forcing all DNS through Pi-hole, that breakage is the point. The hijack is a tripwire that herds devices back into the filter.

Step 3: Null-Route and Sinkhole DoH Domains

Many DoH clients don't connect to an IP address directly. They resolve a bootstrap domain first to discover the server, then establish the encrypted connection. If Pi-hole returns NXDOMAIN for that bootstrap domain, the client often gives up and falls back to the system DNS setting—which, in a properly configured network, points to Pi-hole.

The domains to block include provider bootstrapping names like cloudflare-dns.com, dns.google, dns.quad9.net, and doh.cleanbrowsing.org. Adding these to Pi-hole's blocklist as exact matches or regex patterns prevents the initial resolution. The client never learns the DoH server's IP, so the connection never starts.

The limitation is real: applications that hardcode IP addresses skip this step entirely. Google Chrome, for example, can fall back to 8.8.8.8 without resolving a domain first, though newer versions check the system resolver's behavior before upgrading. Domain blocking catches the bootstrapping clients. The IP blocks and port hijacks handle the hardcoded ones.

The Firefox Canary Domain: A Special Case

Firefox checks for the existence of a specific domain, use-application-dns.net, before enabling DoH on a network. If Pi-hole returns NXDOMAIN for that domain, Firefox interprets it as a signal that the network administrator wants to manage DNS and disables DoH automatically. No configuration change needed on the client. No about:config tweaks. Adding this single domain to Pi-hole's blocklist immediately brings every Firefox browser on the network back under the Pi-hole umbrella. For households where Firefox is the primary browser, this step alone can resolve most of the DoH bypass problem in under five minutes.

Step 4: Lock Down Outbound DNS Entirely

The previous steps target specific protocols and destinations. This step removes the choice entirely. Firewall rules block all outbound DNS traffic—UDP port 53, TCP port 53, and TCP port 853—from every device on the LAN except Pi-hole. A companion rule then explicitly allows Pi-hole's IP to reach its configured upstream resolvers.

The block rule sits near the top of the LAN ruleset. Source is the LAN subnet, destination port is 53 or 853, protocol is both UDP and TCP, action is drop. Below it, an allow rule permits traffic from Pi-hole's static IP to any destination on those same ports. Without the allow rule, Pi-hole itself goes deaf and DNS stops working network-wide.

Gotchas hide here. Some IoT devices ship with hardcoded DNS servers and no way to change them. A smart thermostat might refuse to function if it cannot reach 8.8.8.8 directly. The fix is to log the blocked traffic for a few days before enforcing the drop rule. Review the firewall logs, identify which devices are trying to reach external DNS servers, and decide case by case. For stubborn devices that truly break, a NAT redirect rule can silently forward their hardcoded queries to Pi-hole instead of blocking them outright. The device thinks it's talking to Google; Pi-hole does the filtering anyway.

Step 5: Validate and Monitor

Testing confirms the blocks are working and reveals gaps. Cloudflare's Browsing Experience Security Check page at 1.1.1.1/help reports whether a browser is using DoH, DoT, or plain DNS. Visiting the page from a device on the LAN should show "No" for encrypted DNS and list the Pi-hole's IP or the local resolver. If it shows "Yes" for DoH, something has bypassed the rules.

Command-line tools provide a second check. Running dig against a known DoH-capable resolver from behind the firewall should time out or return a refused connection. Using curl to send a DNS query to https://cloudflare-dns.com/dns-query should fail. The exact error message—connection refused, timeout, or a firewall reset—depends on how the block rule is configured, but any failure is a success in this context.

Firewall logging is the ongoing audit trail. Enabling logging on the DoH block rules captures every attempt a device makes to bypass the filter. Reviewing these logs reveals which devices are trying, how often, and whether new IPs or domains have appeared that need adding to the blocklists. A trickle of blocked queries from known providers is normal background noise. A sudden spike from a new device suggests a fresh application or update that needs attention.

Conclusion

DNS-over-HTTPS is a privacy feature that arrives with a side effect: it breaks network-wide filtering put in place deliberately. The browser's good intentions collide with the administrator's, and the browser wins by default. Reversing that outcome means treating DoH not as a setting to disable on each device, but as unwanted traffic to control at the network boundary.

The layered approach—blocking known DoH server IPs, hijacking port 853, sinkholing bootstrap domains, and locking down outbound DNS—turns the bypass into a series of dead ends. No single rule catches every attempt, but together they make the path of least resistance the one that goes through Pi-hole. The maintenance burden is real: IP lists age, new providers launch, and firmware updates change default behavior. Watching the firewall logs and refreshing the blocklists quarterly keeps the gaps small. A quiet browsing experience, free of cheap flight ads, is the payoff for that vigilance.