Why DNS-over-HTTPS Breaks Pi-hole and Parental Controls

Firefox can silently bypass your filtering without changing a single setting on your Pi-hole. Here is why, and the three ways to fix it.

What DNS-over-HTTPS Actually Does

DNS-over-HTTPS wraps DNS lookups inside encrypted HTTPS traffic on port 443. That is the same port and protocol used for ordinary web browsing. It makes DoH queries indistinguishable from regular HTTPS traffic to anything watching the network, including Pi-hole.

Traditional DNS runs in plaintext over port 53. A tool like Pi-hole sits between your devices and the internet. It intercepts those plaintext DNS requests and refuses to answer for domains on its blocklist. That interception only works if the device actually sends its DNS traffic to Pi-hole in the first place.

DoH changes that assumption. When a browser uses DoH, it sends the DNS query straight to a DoH provider over an encrypted HTTPS connection. That bypasses whatever DNS server your router or device is configured to use. Pi-hole never sees the query, so it cannot block or log it. To see how each DNS record type functions under normal conditions, read our guide on DNS records explained.

Why Firefox Turned DoH On by Default

Mozilla enabled DoH by default for Firefox desktop users in the United States starting in 2019. It extended that to Canada in 2021. Rollout to Russia and Ukraine began in March 2022, with plans to expand further. Mozilla’s stated goal is closing a privacy gap. Plaintext DNS queries are visible to anyone on the network path.

That privacy goal is legitimate on its own terms. Unencrypted DNS lets an ISP or a coffee shop network see every domain a device looks up. So can anyone else on the same network segment. That holds true even over an otherwise encrypted website connection. Mozilla’s rollout treats DoH as a default security upgrade rather than an opt-in feature. That default-on choice is where the conflict with local filtering starts.

Before switching a user to DoH, Firefox runs a set of internal checks Mozilla calls DoH heuristics. These checks ask whether parental controls are enabled on the device. They also check whether the current DNS server appears to be filtering content. A third check looks for organization-managed devices with a custom DNS setup. Firefox re-runs these checks every time the device joins a new network. That is why the same laptop can behave differently at home versus at the office.

The Canary Domain: Firefox’s Opt-Out Signal

Firefox looks up one specific hostname, use-application-dns.net. It uses the operating system’s normal DNS server, before deciding whether to enable DoH. If that lookup fails or returns no address records, Firefox reads it as a signal. The network relies on DNS filtering, so it disables DoH for that session.

This canary domain exists for a reason. Pi-hole, pfSense, enterprise DNS filters, and ISP-level parental controls all need a standard way to opt Firefox out of DoH. Mozilla does not need to know about every individual filtering product. A network operator adds one DNS entry, and Firefox respects it automatically.

The mechanism only works one direction. It tells Firefox “this network relies on DNS filtering.” Firefox then falls back to whatever DNS server the operating system already has configured. It reports nothing back to the network, and it has no effect on any other browser.

Why Pi-hole and Parental Controls Break Silently

Pi-hole keeps working normally for every device and app that still uses plaintext DNS. Only Firefox installations that adopted default DoH stop sending queries to Pi-hole. Filtering appears to work network-wide while quietly failing for a subset of devices.

This partial failure is what makes the problem confusing to diagnose. A parent checks the Pi-hole dashboard, sees blocked queries logged from most devices, and assumes filtering is working everywhere. Meanwhile, one teenager’s Firefox browser resolves every domain directly through an external DoH provider. That happens completely outside Pi-hole’s visibility, with no error message shown to the user.

The same pattern applies to any DNS-based ad blocker, malware filter, or enterprise content policy. Each one depends on devices actually sending their DNS traffic to a specific server. If you suspect a broader DNS issue rather than DoH, start with our network troubleshooting guide.

How to Tell If DoH Is the Cause

First, check whether the affected device is running Firefox — this failure mode is Firefox-specific. Then run the check below on that device, on the network in question, to see whether the canary domain is reachable right now.

Inside Firefox itself, type about:networking#dns into the address bar. It shows a live table of recent DNS lookups. One column shows whether each lookup used Firefox’s Trusted Recursive Resolver — Mozilla’s internal name for DoH. A “true” value there confirms DoH handled that lookup.

You can also check Firefox’s own settings directly. Go to Settings, then Privacy and Security, then scroll to DNS over HTTPS. See which protection level is currently selected. Anything other than Off means that Firefox installation can bypass Pi-hole for at least some lookups.

Fixing It: Three Practical Paths

The most durable fix is blocking the canary domain at the network level. It protects every Firefox installation on that network automatically. Disabling DoH per browser works too, but it only covers the devices you configure by hand.

Configure the Canary Domain (Network-Level)

On Pi-hole, add use-application-dns.net as a domain that returns no A or AAAA records. That satisfies Firefox’s opt-out condition. pfSense, most enterprise DNS filters, and several consumer router firmwares support the same setup, through a custom DNS zone or blocklist. Once configured, every Firefox browser on that network respects the signal automatically, with no per-device changes needed.

Turn Off DoH in Firefox Directly

On an individual device, open Firefox Settings, then Privacy and Security. Scroll to DNS over HTTPS and set the protection level to Off. This fixes that one browser instance immediately. It does not protect other devices or other browsers. Firefox on a phone that joins the network later stays unprotected too.

Use Enterprise Policy (Managed Devices)

On organization-managed computers, Firefox supports enterprise policies that disable DoH centrally. Admins can push the setting through a configuration file or Windows Group Policy, without touching each device by hand. This path fits IT-managed environments better than home networks, where a settings change or the canary domain is usually simpler.

What About Chrome, Edge, and Other Browsers?

Chrome, Edge, and Brave use a different DoH model than Firefox. Instead of switching to a separate DoH provider by default, they try something different. They auto-upgrade the DNS provider already configured on the device to that same provider’s DoH service. That generally means they keep respecting Pi-hole unless a user manually picks a different provider.

Chromium’s own developer documentation is direct about this. The project has no plans to adopt a canary-domain approach like Firefox’s. Its auto-upgrade model is built to preserve whatever DNS provider the user or network already has configured. In practice, Chrome-based browsers rarely cause the silent-bypass problem this article describes. A user who manually selects a public DoH provider inside Chrome’s settings can still route around Pi-hole on purpose.

Safari does not implement Firefox-style automatic DoH at all as of this writing. That leaves Firefox as the browser most likely to cause this specific, confusing failure on a home or small-office network.

Frequently Asked Questions

Confirm what your network is actually returning for any domain with our DNS Record Lookup. Read up on the full resolution chain in how DNS works. If you suspect DNS is escaping a VPN tunnel, rather than just Pi-hole, see what a DNS leak is. For broader DNS errors, start with DNS Server Not Responding.