Chrome vs Firefox Secure DNS Settings Compared

Chrome and Firefox both ship with DNS over HTTPS (DoH) support built in, but they implement it in ways that are quietly incompatible. Enabling Secure DNS in one browser does not mean the other is protected. Depending on which mode you pick, Firefox can block DNS lookups that Chrome would happily fall back on, and Chrome will silently upgrade or skip DoH depending on your ISP without telling you either way. This article breaks down exactly how each browser handles Secure DNS, where the settings live, how to verify the feature is actually running, and how to avoid the failure modes that frustrate both end users and sysadmins.

What Browser-Level Secure DNS Actually Does

Ordinary DNS queries leave your device as plaintext UDP packets on port 53. Your ISP, anyone on your local network segment, or a compromised router can read every domain name you resolve, even when the eventual page connection is HTTPS-encrypted. DNS over HTTPS (DoH) wraps those queries inside a standard HTTPS request on port 443, making them opaque to passive observers and indistinguishable from ordinary web traffic at the network layer.

The distinction most users miss: browser-level DoH runs inside the browser process and bypasses your operating system's DNS resolver entirely. Windows's configured DNS server, macOS's resolv.conf, your router's DHCP-pushed DNS address—none of these apply once a browser is using its own DoH client. This is both the feature's value and its main source of problems. Internal hostnames, split-horizon corporate DNS, and VPN-pushed resolvers all depend on the OS resolver, which browser DoH circumvents unless you explicitly configure exclusions.

Per the IETF RFC 8484 specification, DoH uses standard HTTPS GET or POST requests to a resolver endpoint, making it functionally indistinguishable from ordinary web traffic at the network layer—which is why firewalls cannot block DoH by port number alone without also breaking all HTTPS.

Chrome Secure DNS: Settings and Behavior

Where the Setting Lives

Open chrome://settings/security and scroll to the "Use secure DNS" section. Chrome offers two modes:

• With your current service provider: Chrome detects whether your current DNS resolver supports DoH and upgrades automatically if it does. No provider choice required.
• With a custom provider: You select from a dropdown (Google Public DNS, Cloudflare, NextDNS, OpenDNS, CleanBrowsing, Comodo) or paste any custom DoH URL into the text field below the dropdown.

Chrome's Auto-Upgrade Logic

The default mode relies on a hardcoded list Google maintains of ISPs and public resolvers whose DoH endpoints Chrome knows about. If your configured DNS IP matches an entry on that list, Chrome transparently upgrades to DoH. If your ISP is not on the list, Chrome continues with plaintext DNS—silently, with no indicator anywhere in the browser UI.

This means your protection in default mode depends entirely on whether your ISP appears on Google's approved list. Smaller ISPs, most enterprise DNS servers, and custom resolvers are typically not on the list. To verify whether Chrome is actually using DoH right now, open the following page and look for "(DoH)" appended to resolver entries:

Bare IP addresses without the DoH suffix mean those queries are leaving your machine as unencrypted plaintext DNS on port 53.

Custom Provider Mode and DoH Endpoints

When entering a custom DoH URL, use a standard HTTPS address. The most widely used endpoints:

NextDNS generates a unique per-account DoH URL at nextdns.io/setup. If you use NextDNS on your router for filtering, pointing Chrome at the same account URL keeps the browser under the same blocklist policy as the rest of your network.

Enterprise Group Policy Controls

In managed Windows environments, the DnsOverHttpsMode Group Policy key controls DoH for all Chrome users on the machine:

When this policy is active, the toggle in chrome://settings/security appears grayed out and cannot be changed by the user. The companion policy DnsOverHttpsTemplates specifies which DoH endpoint to use when mode is set to "secure". For OpenWrt or DD-WRT environments, there is no Chrome-native split-DNS policy enforcement—you must either configure DoH at the resolver level or push a policy via managed browser enrollment.

What Chrome Does Not Protect

Chrome's DoH is browser-scoped, not machine-wide. DNS queries from system services, background apps, Chrome extensions that fall back to the OS resolver, and every other process on the machine still use plaintext DNS through the OS stack. Enabling Secure DNS in Chrome makes that browser's DNS private—it does not make your machine's DNS private.

Firefox DNS over HTTPS: Settings and Behavior

Where the Setting Lives

Navigate to about:preferences#privacy and scroll to the "DNS over HTTPS" section near the bottom of the page. Firefox presents four named modes:

1. Default protection: DoH enabled via Cloudflare. Falls back to system DNS if DoH fails or if the canary domain signals a network opt-out (explained below).
2. Increased protection: Prefers DoH, falls back to system DNS only on DoH failure. Canary domain still respected.
3. Max protection: DoH only. No fallback. If the DoH resolver cannot be reached, DNS fails and the page will not load.
4. Custom: Specify any DoH-compatible endpoint URL.

The Canary Domain: Firefox's Network Opt-Out Signal

At browser startup, Firefox queries use-application-dns.net. If this domain returns NXDOMAIN—a deliberate block that network operators configure to signal DoH opt-out—Firefox disables its DoH entirely and falls back to the system resolver. Enterprises, schools, and ISPs can add this NXDOMAIN block on their authoritative DNS to keep Firefox from bypassing their DNS infrastructure, without needing users to touch any setting.

From a user's perspective, this means Firefox can silently disable DoH on a corporate or school network even when "Default protection" is selected in Preferences. The canary check fires once at startup with no visible alert—Firefox just reverts to plaintext DNS. To force DoH regardless of network signals, open about:config and set:

Mode 3 disables the canary check entirely and forces all DNS through the configured DoH resolver. Any domain that cannot resolve via DoH will produce a connection error—no silent fallback, no DNS leak through plaintext.

The about:config network.trr Namespace

Firefox's complete DoH configuration lives in about:config under the network.trr.* key namespace. The most operationally important settings:

The network.trr.excluded-domains preference is essential for split-horizon DNS environments. Any TLD or hostname in this list resolves via the OS resolver instead of DoH, preventing NXDOMAIN failures for internal services while keeping all external DNS queries encrypted. This is user-configurable with no policy deployment required—a key advantage over Chrome for home lab and hybrid-work scenarios.

Firefox's Default Provider and the Mozilla Agreement

Firefox's default DoH endpoint is mozilla.cloudflare-dns.com/dns-query—not the generic Cloudflare endpoint. Mozilla operates this under a data-sharing agreement with Cloudflare that prohibits retaining personally identifiable query data. If you switch to a custom provider, verify the provider's privacy policy independently. NextDNS, Quad9, and AdGuard DNS all publish clear data-retention policies covering their DoH services and are reasonable alternatives.

Key Differences Between Chrome and Firefox

The practical differences matter most when something breaks or you need to audit your security posture:

• Default provider: Chrome auto-upgrades to your ISP's DoH endpoint if it appears on Google's list; Firefox defaults to Cloudflare under the Mozilla privacy agreement.
• Hard-block mode: Firefox has a UI toggle for "Max protection" with no plaintext fallback. Chrome requires Group Policy or MDM enrollment for equivalent enforcement.
• Canary domain: Firefox respects the use-application-dns.net NXDOMAIN signal as a network opt-out. Chrome has no equivalent canary mechanism.
• Per-domain exclusions: Firefox lets any user configure split-DNS exclusions in about:config in under a minute. Chrome requires DnsOverHttpsExcludedDomains via enterprise policy.
• Silent fallback: Both browsers can silently revert to plaintext DNS under specific conditions with no UI warning to the user.
• Debug page: Chrome uses chrome://net-internals/#dns; Firefox uses about:networking#dns.

CLI and In-Browser Verification

Browser Debug Pages

Chrome's chrome://net-internals/#dns shows real-time DNS resolution events with DoH status appended to each resolver entry. The "Clear host cache" button flushes all cached entries. Firefox's about:networking#dns shows the DNS cache and the current TRR mode, confirming what is actually active versus what is configured in Preferences—the two sometimes differ when the canary check has fired.

Testing the DoH Endpoint Directly

A JSON response containing an "Answer" array confirms the endpoint is reachable and resolving. A connection error or empty response means the DoH resolver is blocked at the firewall or the URL is incorrect.

dig and nslookup Baseline Comparison

If dig returns different results than your browser, your browser DoH is active and querying a different resolver than the OS. If both return identical results, either both resolvers agree on the answer, or your browser DoH is disabled and falling through to the OS resolver.

Cloudflare's One-Click Verification Page

Browse to https://one.one.one.one/help in the browser you want to test. Cloudflare's diagnostic page reports whether your connection used DNS over HTTPS, DNS over TLS, or plaintext DNS, and shows the resolver IP that serviced the query. This is the fastest human-readable confirmation method and requires no CLI access—it works identically on Windows, macOS, Linux, iOS, and Android.

Common Problems and Misdiagnoses

Internal Hostnames Return NXDOMAIN After Enabling DoH

A public DoH resolver has no records for your private hostnames. After enabling DoH, if hostname.corp or server.local suddenly returns NXDOMAIN, the browser is sending those queries to the public resolver rather than your internal DNS. Fix in Firefox: add the TLD to network.trr.excluded-domains (add .corp, .internal, .home.arpa, .local as comma-separated values in about:config). Fix in Chrome: disable Secure DNS for that profile, or deploy the DnsOverHttpsExcludedDomains policy listing each internal TLD.

VPN DNS Leaking Through Browser DoH

Corporate VPNs push a private DNS server via the OS resolver to ensure lookups route through the tunnel. Browser DoH bypasses this entirely—your browser resolves via the public DoH provider, outside the VPN. If your organization requires all DNS through the tunnel, disable browser DoH while the VPN is connected, or configure the browser's DoH URL to point to a DoH endpoint your VPN provider operates. Mullvad, ProtonVPN, and ExpressVPN each publish their own DoH endpoints for this scenario.

Firefox Canary Tripped by ISP NXDOMAIN Hijacking

Some ISPs intercept NXDOMAIN responses and return synthetic redirect pages—a practice called NXDOMAIN hijacking. Firefox's canary check expects a genuine NXDOMAIN for use-application-dns.net. If your ISP hijacks that response, Firefox incorrectly reads it as a network opt-out signal and silently disables DoH. Fix: change your OS-level DNS to 1.1.1.1 or 8.8.8.8 before launching Firefox, or set network.trr.mode = 3 in about:config to skip the canary check entirely and force DoH regardless of network signals.

Slow First Page Loads After Enabling DoH

DoH requires establishing an HTTPS connection to the resolver before the first DNS query proceeds. In Firefox, if network.trr.bootstrapAddr is unset, Firefox must first resolve the DoH resolver's hostname via DNS—but in forced mode that resolution also tries to go through DoH, creating a circular dependency that stalls for several seconds on the first request. Fix: set network.trr.bootstrapAddr to the actual IP of your DoH resolver (162.159.36.1 for Cloudflare, 8.8.8.8 for Google). Chrome handles this bootstrap automatically at startup.

"Secure DNS Is Not Available" Warning in Chrome

This warning appears in chrome://settings/security when Chrome's auto-upgrade mode cannot find a DoH endpoint for your current ISP. Browsing continues normally over plaintext DNS—Chrome is informing you, not blocking you. The fix: switch to "With a custom provider" mode and select Google, Cloudflare, or Quad9 from the dropdown.

2026 Updates: ECH, DNSSEC, and IPv6

DoH encrypts the DNS query but historically left one observable gap: the TLS SNI field in HTTPS handshakes still exposed the target hostname to network observers even after the DNS query was hidden. Encrypted Client Hello (ECH) closes this gap by encrypting the SNI field itself using parameters published in the domain's HTTPS DNS record. ECH is live in Firefox 121+ and Chrome 117+. Both browsers enable it automatically when the resolver and server support it—no user configuration is needed. As of mid-2026, Cloudflare-hosted domains and a growing list of major properties publish ECH parameters.

DNSSEC validation behavior varies by DoH provider. Cloudflare's resolver—Firefox's default—validates DNSSEC and returns SERVFAIL for domains with invalid or forged signatures, protecting against cache poisoning. Google Public DNS also validates. If you are using a lesser-known DoH provider, verify it performs full DNSSEC validation before treating it as a security control rather than just a privacy improvement. A non-validating DoH resolver encrypts your queries but does not protect against spoofed DNS responses.

IPv6 and DoH: Both browsers resolve AAAA records over DoH. If your DoH provider returns IPv6 addresses for a domain but your local network has broken IPv6 routing, connections will time out before falling back to IPv4—a failure mode that presents as a slow or intermittently broken site. Test with dig AAAA example.com @1.1.1.1 to confirm whether your DoH resolver is serving AAAA records, then check local IPv6 path health with ping6 cloudflare-dns.com on Linux or macOS. On Android 9+ and iOS 14+, the OS handles IPv6 happy-eyeballs fallback more aggressively than most desktop systems, so this issue surfaces more often on desktop clients.

Which Browser Gives You Stronger Secure DNS

For default-on protection with zero configuration: Firefox wins. It enables Cloudflare DoH under a privacy agreement in most regions without the user touching a single setting. Chrome's default mode only protects you if your ISP appears on Google's auto-upgrade list—which excludes the majority of smaller providers worldwide.

For per-domain split-DNS control without enterprise infrastructure: Firefox's network.trr.excluded-domains lets any user carve out internal DNS exceptions in about:config in under a minute. Chrome requires Group Policy or MDM enrollment to achieve the same result, which is impractical on personal or small-business machines.

For forced DoH with zero plaintext fallback: Firefox's "Max protection" achieves this in two clicks from about:preferences#privacy. Chrome requires a DnsOverHttpsMode Group Policy deployment set to "secure", which adds meaningful administrative overhead.

For enterprise Windows environments where IT centrally manages browser policy: Chrome's Group Policy integration is more mature and integrates directly with existing Windows management tooling. Firefox supports equivalent controls via policies.json or MDM, but Chrome remains the more common managed browser in enterprise Windows deployments.

On every platform—Windows, macOS, Linux, iOS, Android—the verification steps are the same: check the browser's built-in DNS debug page, run a curl test against the DoH endpoint directly, and load https://one.one.one.one/help for a human-readable confirmation. Those three steps take under a minute and will tell you definitively whether your Secure DNS configuration is running or silently bypassed.