# Blocking DNS over HTTPS on a home network: keeping devices on Pi-hole or AdGuard Home with encrypted DNS upstream URL: https://webvpn.org/encryption/block-dns-over-https/ Updated: 2026-09-09 How and why to block DNS over HTTPS on a home network so devices use your Pi-hole or AdGuard Home, how to give the filter an encrypted upstream, and the limits. Blocking DNS over HTTPS on a home network means preventing devices and browsers from sending lookups directly to public encrypted resolvers, so that they use your Pi-hole or AdGuard Home and its filtering applies. The effective measures are serving the canary domain that makes Firefox disable DoH, redirecting all outbound port 53 to your resolver, blocking outbound port 853 to stop DNS over TLS, and blocking the IP addresses of well-known DoH resolvers at the firewall. To preserve privacy, give the filter an encrypted upstream, or run AdGuard Home with a certificate so it serves DoH and DoT to your devices itself. Encrypted DNS is good for privacy and awkward for anyone running network-wide filtering, because the two designs pull in opposite directions: one wants devices to reach a resolver of their choosing, the other wants all devices to use the local one. This guide takes the administrator's side and explains why DoH bypasses filters, the techniques to keep devices on Pi-hole or AdGuard Home, how to keep upstream lookups encrypted so nothing is lost, and the honest limits of blocking. ## Why DoH bypasses your filter Pi-hole and AdGuard Home work by being the DNS server your router hands out via DHCP. Every device asks them, they refuse ad and tracker domains, and everything else is forwarded upstream. A browser or device configured for DoH ignores the DHCP-assigned server and sends its lookups inside HTTPS to Cloudflare, Google or whoever it is set to, as the DoH guide on this site describes. The filter never sees those queries, ads reappear in that browser, and parental controls stop applying to that device. Some smart TVs and streaming devices hard-code public resolvers for the same effect even without encryption. The measures below keep queries on your resolver. None of them reduce what leaves your network unencrypted if you follow the encrypted upstream section. ## Measure one: the canary domain Mozilla defined a canary domain, use-application-dns.net, that Firefox looks up before enabling its default DoH. If the local resolver returns no answer or an error for that name, Firefox concludes the network wants to manage DNS and disables its automatic DoH. Pi-hole includes an option to serve the canary domain in its DNS settings, and AdGuard Home does the same. This is the gentlest control, since it only affects Firefox's default mode; a user who set Max Protection manually is not overridden. Chromium browsers do not use a canary domain; they disable DoH when the system resolver is one they do not recognise as DoH-capable, which a local resolver generally satisfies. ## Measure two: redirect port 53 Devices with a hard-coded plain DNS server, such as some streaming boxes, ignore DHCP but still use port 53. A firewall rule on the router that redirects all outbound TCP and UDP port 53 traffic to the Pi-hole or AdGuard Home address catches them. Most router firmware with a firewall or NAT section supports this, and OpenWrt, pfSense, OPNsense and UniFi document it. Note that this redirection is what triggers the Apple warning discussed in the troubleshooting guide on this site; if you want iOS devices satisfied, serve encrypted DNS from your filter as described below rather than only redirecting. ## Measure three: block port 853 DNS over TLS uses its own port, so a firewall rule blocking outbound port 853 stops it entirely. Android's Private DNS setting will then fail and fall back or warn, depending on its mode, keeping the device on the local resolver. Also block UDP 853 to cover DNS over QUIC. ## Measure four: block known DoH resolvers DoH cannot be blocked by port, since it shares 443 with the web. It can be blocked by destination. Maintain a firewall block list of the IP addresses of public DoH resolvers, and add their hostnames to your filter's blocklist so that clients cannot even resolve them. Community-maintained lists of DoH server IPs and hostnames exist for exactly this purpose and are importable into Pi-hole, AdGuard Home, pfSense and similar. This catches browsers configured to use a listed resolver. Update the list periodically, since resolvers add addresses. ## Measure five: give your filter encrypted upstream Blocking device-level DoH without encrypting your filter's upstream would leave your whole network's lookups readable by your ISP, which is worse than before. Fix that at the filter. AdGuard Home supports encrypted upstream natively. In Settings, DNS settings, enter upstreams as https://dns.quad9.net/dns-query or tls://dns.quad9.net, using addresses from the servers guide on this site. Enable parallel requests or load balancing as you prefer. Every query leaving your network is then encrypted. Pi-hole does not speak encrypted DNS itself. Install a companion on the same machine: cloudflared, configured as a DoH proxy on a local port; dnscrypt-proxy, which supports DoH and DNSCrypt; stubby for DoT; or unbound as a full recursive resolver, which talks directly to authoritative servers and removes the need to trust any public resolver at the cost of those queries being plain. Then set Pi-hole's upstream to the companion's local address. Pi-hole's documentation covers each. ## Measure six: serve encrypted DNS from your filter The most complete approach lets devices use encrypted DNS and still hit your filter. AdGuard Home, given a TLS certificate for a hostname you control, can serve DoH on port 443 and DoT on 853 to your network. Configure it under Settings, Encryption settings, with a certificate from Let's Encrypt or your own authority. Then point browsers, Android's Private DNS and Apple profiles at your AdGuard Home hostname. AdGuard's documentation includes an Apple profile generator for this. iOS stops showing the blocking warning because encrypted DNS works; it simply works to your resolver. Pi-hole lacks this feature natively, though placing a reverse proxy with a certificate in front of a DoH proxy is possible for those comfortable with the setup. ## The limits of blocking Be clear about what these measures achieve. They stop browsers in default modes, phones using standard settings, and devices with hard-coded plain resolvers. They do not stop a user who configures an obscure DoH server not on any list, who uses a VPN, or who uses Tor, all of which carry DNS somewhere your filter never sees. DoH was designed to be hard to block, and it is. For a household, that is usually acceptable: the goal is ad and tracker blocking and keeping children's devices filtered, not defeating a determined adult. For anything stronger, device-level controls such as parental control apps or managed device profiles are the tools, not network DNS. ## A seven-point checklist - Enable the canary domain in Pi-hole or AdGuard Home. - Redirect outbound port 53 to your resolver at the router. - Block outbound TCP and UDP 853. - Import a DoH resolver blocklist into the firewall and the filter. - Configure encrypted upstream in AdGuard Home or via a companion for Pi-hole. - Optionally serve DoH and DoT from AdGuard Home with a certificate, and point your devices at it. - Test from a device with browser DoH enabled and confirm ads are blocked and the resolver test page shows your filter's upstream. ## What Mozilla, the Pi-hole and AdGuard projects, and administrators document The measures above follow the vendors' documentation and administrator practice. Mozilla documents the canary domain and the conditions under which Firefox disables default DoH, and the Chromium project documents that its browsers upgrade to DoH only when the system resolver is a recognised DoH provider. Pi-hole's documentation describes serving the canary domain and adding encrypted upstream through cloudflared, unbound or similar companions; AdGuard Home's documentation describes encrypted upstream configuration and serving DoH, DoT and DoQ to clients with a certificate. Network administrators report that redirecting port 53, blocking 853 and blocking known DoH resolver addresses keep most consumer devices on the local filter, while acknowledging that DoH to unlisted servers and VPNs cannot be prevented at the network level. ## Filter locally, encrypt upstream, accept the edges Set up the canary domain, the port redirects and the resolver blocklist, and your Pi-hole or AdGuard Home sees the whole household's lookups again. Give it an encrypted upstream, or let AdGuard Home serve encrypted DNS itself, and you have filtering and privacy at once. What slips past, a VPN or a resolver nobody listed, is the price of a protocol designed to protect people from exactly this kind of control, and at home it is a price worth accepting. ## FAQ Q: Why would I block DNS over HTTPS on my network? A: If you run a filtering resolver such as Pi-hole or AdGuard Home for ad blocking, tracking protection or parental controls, any device or browser that uses DNS over HTTPS to a public resolver bypasses the filter entirely. Blocking DoH keeps devices on the local resolver so the filtering applies. Q: How do I stop devices bypassing Pi-hole with DNS over HTTPS? A: Serve the canary domain so Firefox disables DoH automatically, block outbound port 853 to stop DNS over TLS, redirect all outbound port 53 to Pi-hole, and block the IP addresses of well-known public DoH resolvers at the firewall. Give Pi-hole an encrypted upstream so your network's lookups remain private. Q: Can AdGuard Home do DNS over HTTPS? A: Yes, both directions. It forwards upstream over DoH, DoT or DoQ by entering tls:// or https:// upstream addresses, and with a certificate it serves DoH and DoT to your devices, so browsers and phones can be configured to use your AdGuard Home over encrypted DNS instead of a public resolver, satisfying both filtering and encryption. Q: Can DNS over HTTPS be blocked completely? A: Not reliably. DoH uses port 443 like all web traffic, so it can only be blocked by blocking the IP addresses or hostnames of known resolvers, and a client can use an unknown one. Blocking well-known resolvers and the canary domain stops browsers and most devices; a determined user with a VPN or an obscure DoH server can still bypass it. Q: Does blocking DoH hurt my privacy? A: Only if your local resolver then sends queries upstream in plain text. Configure Pi-hole or AdGuard Home to use an encrypted upstream, and lookups leave your network encrypted just as they would with device-level DoH, while the filter still applies. Inside your own network, plain DNS between devices and the filter is not a privacy concern.