Windows 11 DNS over HTTPS: Why Chrome, Edge and Apps Can Bypass System DoH

The headline exaggerates a bit, since Chrome didn't ignore the setting entirely. It read the DNS server address from Windows and then made its own encrypted connection. The practical point holds, though: system DoH protects lookups that go through the Windows DNS Client service. Every other path has to be checked separately.

The setup: what Windows 11 actually promises​

Mahmood set up a Windows 11 laptop to use Cloudflare's resolvers at 1.1.1.1 and 1.0.0.1. The path was Settings → Network & internet → Wi-Fi, then the network's properties, Edit next to DNS server assignment, and Manual. He set DNS over HTTPS to On (automatic template) for both servers, which made Windows fill in Cloudflare's template automatically. He also turned Fallback to plaintext off.

Microsoft's support documentation for Windows 10 and Windows 11 describes three DoH options:

The fallback switch has a narrow job. When it's on, a query that can't go over HTTPS is sent unencrypted. When it's off, that query isn't sent at all. Microsoft also says the DoH setting isn't available in Windows 10, so everything here applies to Windows 11 only.

Microsoft's Windows 11 security book frames the feature around the Windows DNS client. That client supports DoH and DNS over TLS, and its encryption works alongside the Name Resolution Policy Table (NRPT), the Hosts file and per-adapter resolvers. The documentation doesn't claim that every application's own DNS code will follow it.

Inside that scope, the feature worked. Mahmood ran Resolve-DnsName example.net in PowerShell while recording traffic with pktmon, the packet monitor built into Windows. No plaintext DNS left the laptop for that lookup.

In short: Windows 11 DoH did what Microsoft says it does, for queries that go through Windows.

Chrome: "OS default" isn't quite what it sounds like​

Chrome's secure DNS setting is under Settings → Privacy and security → Security → Use secure DNS. On Mahmood's laptop it was turned on, with the provider set to OS default (when available). Cloudflare's diagnostic page at 1.1.1.1/help reported DoH as active, which looked like Windows was doing the work.

The packet capture showed something else. Just before Chrome loaded a page, it looked up chrome.cloudflare-dns.com and then sent encrypted traffic to that server over HTTP/3. Mahmood reads this as Chrome taking the 1.1.1.1 address from Windows, recognizing it as Cloudflare, and opening its own DoH connection.

That fits how Chromium says the feature works. Chromium's developer documentation says the deployment model aims to keep the user experience the same by "auto-upgrading to the current DNS provider's DoH server." It also notes that managed deployments should be opted out automatically and that administrators can control the feature through policy.

On a home PC, the result is nearly the same: the lookups are still encrypted and still go to Cloudflare. The difference is control. Chrome's queries never pass through the Windows DoH stack, so Windows' fallback switch has no effect on them, and Windows gives no sign of this. Google's Chrome Help says automatic mode can fall back to unencrypted lookups if Chrome has trouble. Choosing a custom provider removes that unencrypted fallback. Google also says Chrome's secure DNS can't be used on a managed device or when parental controls are turned on.

In short: with the default setting, Chrome follows your DNS provider, not your Windows encryption and fallback rules.

Custom providers take Windows out of the picture​

The bypass is easiest to see when you choose a provider in the browser. Mahmood set Chrome's provider dropdown to Google (Public DNS) and left Windows on Cloudflare. Cloudflare's test page then showed No for "Connected to 1.1.1.1" and listed the AS name as Google LLC.

Edge did the same. Under Settings → Privacy, search, and services → Security, he chose a service provider, picked Google (Public DNS), and got the same result.

This is a separate issue from Chrome's automatic upgrade. A browser-level provider can be a different company from the one Windows uses. Microsoft's Edge policy documentation explains both behaviors:

• The DnsOverHttpsTemplates policy (Windows, Edge 83 and later) sets the browser's DoH resolver template. It can be set through Group Policy (MSEdge.admx) or the registry value DnsOverHttpsTemplates (REG_SZ) under SOFTWARE\Policies\Microsoft\Edge.
• If DnsOverHttpsMode is "automatic" and no template is set, Edge uses built-in mappings to try to upgrade your current resolver to a DoH resolver run by the same provider. That's the same idea as Chrome's.
• If the mode is "secure", a template is required.

In short: for admins who want browser DNS to match company resolvers, browser policy is the place to set it. The Windows network settings page isn't enough.

Firefox: follows Windows here, but defaults vary by region​

Firefox behaved most predictably in this test. On Default protection, its about:networking#dns page showed every lookup with TRR (Mozilla's term for its trusted resolver) set to false. Mahmood took that to mean the requests went through Windows. When he switched to Custom and chose NextDNS, the Cloudflare test page showed No and named The Constant Company, LLC, which Mahmood identifies as the hosting network NextDNS runs on.

Mozilla's documentation explains why your results may differ. The Default protection automatically enables secure DNS in available regions and falls back to the default resolvers if there are issues. It also disables DoH when VPN, parental control or enterprise policies are active or when a network tells Firefox not to use secure DNS. Mozilla says it completed our rollout of DoH by default to all United States Firefox desktop users in 2019 and to all Canadian Firefox desktop users in 2021. A US user on Default could therefore see Firefox using its own resolver even though Mahmood's Firefox didn't.

For managed fleets, Mozilla's DNSOverHTTPS enterprise policy maps to the network.trr.mode preference. With Enabled and Fallback both true (mode 2), Firefox tries DNS over HTTPS first and falls back to the system resolver. With fallback disabled (mode 3), Firefox only uses DNS over HTTPS, and a failed lookup is an error. Mozilla also warns about the policy cost: DoH makes lookups harder for the network to see, but they no longer go through your DNS infrastructure unless you use a ProviderURL. Browser DoH is the same mechanism that lets users get around network-wide DNS filtering, which Mahmood also mentions.

The plaintext leaks, and how sure we can be about them​

The browsers were only part of the result. Mahmood opened the pktmon capture in Wireshark and filtered for udp.port == 53, the port plain DNS uses. With DoH on and fallback off, he expected no results. He found some:

• Lookups for slackb.com, a domain Slack uses, went out in plaintext to 1.1.1.1 and 1.0.0.1.
• The browsers' lookups for their own DoH servers, dns.google and chrome.cloudflare-dns.com, also went out in plaintext. A browser has to resolve those names before it can switch to encryption.
• Every leaked query was an A record query paired with an HTTPS record query. Mahmood says that pattern matches Chromium's built-in DNS client.

His explanation is that Chromium-based desktop apps such as Slack read the server address from Windows and send their own unencrypted queries straight to it. He says himself that he couldn't link each packet to a process, so this is an inference, not proof. It's a reasonable one. It doesn't show that Slack, or every Chromium-based app, always bypasses Windows DoH. Even so, someone watching the network could see some of the services you use despite Windows' fallback switch being off.

He suggests two fixes: point Windows at a router that does DoH upstream, or run a DNS provider's own Windows app that catches every lookup on the PC. These are suggestions, not tested fixes. A router that encrypts upstream still receives plaintext from your PC over the local network. It hides those queries from your ISP, not from anyone on your Wi-Fi.

A practical audit checklist for Windows 11​

This is a sequence for checking which path your DNS actually takes:

1. Check the Windows layer. In Settings, confirm your DNS servers, the DoH mode and the fallback setting for each adapter you use. Wi-Fi and Ethernet are configured separately.
2. Check what Windows knows about DoH. Microsoft's Windows Server documentation describes Get-DnsClientDohServerAddress, which lists the resolvers known to support DoH, and Add-DnsClientDohServerAddress, which adds a template with -AllowFallbackToUdp and -AutoUpgrade options. Cloudflare, Google and Quad9 are on the default list.
3. Test every browser. Load 1.1.1.1/help in each one. Mahmood's rule: if the results don't match your Windows settings, the browser's own secure DNS setting is in control.
4. Read Firefox's internals. about:networking#dns shows whether lookups are using TRR.
5. Capture traffic. Record with pktmon during normal app use, then filter for udp.port == 53 in Wireshark. Keep in mind that one short capture with no port-53 traffic doesn't prove much, because an app may have used cached results or not made a lookup at all.
6. For admins: set browser DoH through Chrome, Edge and Firefox policies. Microsoft's Server documentation names the Windows policy Configure DNS over HTTPS (DoH) name resolution under Computer Configuration\Policies\Administrative Templates\Network\DNS Client. It also warns against using Require DoH on domain-joined machines, because the Windows Server DNS Server service doesn't accept DoH queries.

The bottom line​

None of this means Windows 11's DoH is broken. It encrypts the traffic it handles, as documented. The problem is that the toggle in Settings suggests it protects the whole PC, when browsers and apps that run their own DNS code aren't covered by it.

Mahmood is keeping system DoH turned on, and it's still worth using. Just don't treat that one switch as protection for the whole PC: check each browser's setting and look at the traffic yourself.