Reports circulating in enthusiast communities have reignited a debate: does Windows 11 silently revert to unencrypted DNS when its encrypted DNS-over-HTTPS (DoH) fails? The answer isn't a simple yes or no—and understanding the nuances can mean the difference between genuine privacy and a false sense of security. While Microsoft has championed DoH as a built-in privacy shield, the operating system's default behavior often prioritizes connectivity over strict encryption, leaving many users unaware that their DNS queries might still travel in cleartext. This deep dive unpacks how Windows 11 handles DoH, when it falls back to plain DNS, and exactly which group policy knobs you must twist to lock it down.

The promise—and peril—of DNS-over-HTTPS

Every time you type a web address, your computer sends a DNS query to translate that name into an IP address. By default, these queries fly across the network in plaintext, readable by anyone snooping on your connection. DNS-over-HTTPS wraps those queries inside encrypted HTTPS traffic, blending them with your regular web browsing so that prying eyes can't tell which sites you're visiting or tamper with the responses.

Windows 11 was the first Microsoft OS to bake DoH directly into the network stack. Starting with build 22000, users could flip a switch in Settings to enable encryption for known providers like Cloudflare or Google, or add custom resolvers. The feature promised a set-and-forget privacy upgrade, but the fine print revealed a catch: resilience mechanisms that could silently downgrade to unencrypted DNS.

How Windows 11 decides whether to encrypt

The native DoH client works through a system service that intercepts DNS queries and, when conditions are right, wraps them in HTTPS. To enable it, you navigate to Settings > Network & Internet > Wi-Fi (or Ethernet) > Hardware properties, click Edit next to DNS server assignment, and choose one of the pre-listed encrypted providers or enter a custom IPv4/IPv6 address along with a DoH template. Once applied, the system registers that server as capable of encryption.

But registration alone doesn't force encryption. The critical hidden factor is a fallback timer: if the DoH server doesn't respond within a certain window (by default roughly 2.5 seconds), the DNS client gives up and sends the same query over classic UDP port 53. This design ensures that a momentarily sluggish DoH server doesn't kill your internet, but it also means that any intermittent network hiccup can leak the very queries you hoped to protect.

Microsoft documents this behavior openly. The group policy Configure DNS over HTTPS (DoH) name resolution (found under Computer Configuration > Administrative Templates > Network > DNS Client) offers three modes:

  • Allow DNS over HTTPS – The default. The client uses DoH if possible but will fall back to plaintext DNS whenever the encrypted server fails to respond promptly.
  • Require DNS over HTTPS – The client always encrypts. If the DoH server is unreachable, name resolution simply fails; no plaintext fallback occurs.
  • Disable DNS over HTTPS – Turns off encryption entirely, even if you've configured a DoH-capable server.

On a vanilla Windows 11 Pro or Enterprise machine, the policy is set to "Allow," meaning fallback is active. Home edition users lack the Group Policy Editor but can achieve the same effect by setting the registry key HKLM\\Software\\Policies\\Microsoft\\Windows NT\\DNSClient\\DoHPolicy to 2 (Require) or 3 (Allow, which is the default) via a .reg file.

When fallback actually happens—real-world scenarios

Fallback isn't theoretical. Network jitter, firewall rules that block HTTPS to port 443 on the DNS server, or carrier-grade NAT that interferes with TCP connections can all trigger a downgrade. In corporate environments, deep packet inspection appliances that can't inspect encrypted DNS often disrupt DoH, causing clients to fall back silently. VPN clients that override DNS settings may also inadvertently steer queries outside the encrypted tunnel, another vector for leakage.

A practical test: set up DNS resolution to dns.google with the DoH template https://dns.google/dns-query, then temporarily block outbound TCP 443 to that IP address. Within moments, name resolution continues—but a packet capture reveals cleartext A-record lookups hurtling toward 8.8.8.8 on port 53. Windows never warns you. The network icon doesn't change; the internet "just works." This is by design, but it undermines the privacy promise.

Why the debate keeps resurfacing

The community's concerns aren't new, but they spike whenever a fresh build rolls out or when a prominent security researcher publishes new findings. In May 2025, forum threads lit up again when a user posted a Wireshark trace showing plaintext DNS despite having DoH enabled in Settings. The confusion often stems from misunderstanding the "Allow" vs. "Require" dichotomy. Many assume that ticking the DoH checkbox in the Settings UI is enough to lock down DNS; they don't realize that Settings only configures which server to use, not whether fallback is permitted. The fallback behavior is controlled exclusively by the policy (or registry) setting.

Microsoft's documentation for the Settings UI is itself ambiguous. The page says "Preferred DNS encryption" but fails to mention that the encryption is best-effort unless further hardening is applied. This gap between consumer-facing UX and enterprise policy has led to countless false starts where users believed they were protected while their ISP or local network administrator could still log every domain they visited.

Hardening your DNS privacy: step by step

If privacy matters more than a potential few seconds of extra latency, switching from "Allow" to "Require" is the single most impactful change you can make. Here's how to do it on various editions:

On Windows 11 Pro, Enterprise, or Education

  1. Open gpedit.msc.
  2. Navigate to Computer Configuration > Administrative Templates > Network > DNS Client.
  3. Double-click Configure DNS over HTTPS (DoH) name resolution.
  4. Select Enabled, then choose Require DNS over HTTPS from the dropdown.
  5. Click OK and reboot or run gpupdate /force.

On Windows 11 Home

Since the Group Policy Editor isn't officially available, you can deploy the equivalent registry setting:
1. Open regedit.
2. Navigate to HKEY_LOCAL_MACHINE\\Software\\Policies\\Microsoft\\Windows NT\\DNSClient (create the DNSClient key if it doesn't exist).
3. Create a new DWORD value named DoHPolicy and set it to 2.
4. Reboot.

For even stricter control, consider deploying a DoH-only firewall rule that blocks outbound UDP 53 system-wide, essentially creating a network-level failsafe that prevents any application from using plaintext DNS. Advanced users can also monitor DNS traffic with tools like Wireshark or pktmon (built into Windows) to verify that only TCP 443 streams carry DNS payloads.

Testing your configuration

After locking down, validate your setup:
- Visit a site like https://1.1.1.1/help (Cloudflare) or https://dnsleaktest.com. These pages check whether your browser is using encrypted DNS, but they test the browser's own DoH, not the system resolver. For system-level verification, you need a network capture.
- Use pktmon: open an elevated Command Prompt and run pktmon filter add -p 53 followed by pktmon start --capture --comp nics. Generate DNS traffic (e.g., nslookup microsoft.com), stop the capture, and convert it to text with pktmon stop; pktmon format PktMon.etl -o capture.txt. Inspect the output for any UDP 53 traffic. If you see none, your system is clean.
- Alternatively, run Wireshark with a capture filter port 53. If you're in "Require" mode, you should see zero DNS packets on port 53 when performing a manual query.

Beyond group policy: MDM and enterprise controls

Organizations managing fleets can push DoH settings via MDM (Mobile Device Management) or Intune. The policy CSP ./Device/Vendor/MSFT/Policy/Config/DnsClient/ mirrors the group policy options. Setting DoHPolicy to 2 in a custom device configuration profile ensures every managed device refuses unencrypted DNS. Combined with firewall rules that block outbound UDP 53 at the edge, this creates a strong defense against DNS leaks.

Enterprises running Windows Server with DNS forwarding can also set up their own internal DoH resolvers. The server-side DnsClientDoHServerAddress policy lets you point clients to an internal gateway that performs encrypted forwarding to a public DoH provider, keeping all DNS traffic within the corporate boundary until the last hop.

Common pitfalls and misunderstandings

Mixing browser and system DoH: Browsers like Edge, Chrome, and Firefox each have their own DoH implementation. When the browser's DoH is active, it bypasses the system DNS client entirely, so Windows' fallback behavior doesn't apply—the browser's own fallback logic takes over. However, non-browser applications (email clients, command-line tools, telemetry) still use the system resolver. Relying solely on browser DoH leaves those apps exposed.

Third-party antivirus or firewall interference: Some security software intercepts DNS traffic to inspect it, effectively acting as a local DNS proxy. Even if Windows is configured to require DoH, the proxy may forward queries unencrypted to the upstream server. Check your antivirus documentation or temporarily disable real-time scanning during testing to isolate the issue.

IPv6 misconfiguration: If your network has broken IPv6 connectivity, Windows might try to reach the DoH server over IPv6, time out, and fall back to plain IPv4 DNS. Enforcing an IPv4-only DoH server in Settings can mitigate this.

The bigger picture: DoH and Windows telemetry

Privacy purists often raise another concern: even if all DNS is encrypted, Windows telemetry and diagnostic data might leak hostnames through direct IP connections or SNI (Server Name Indication) in TLS handshakes. While DoH protects the name-to-IP mapping, SNI reveals which domain you're connecting to unless you're using Encrypted Client Hello (ECH). Windows 11 24H2 has improved support for ECH when browsing with Edge, but system-wide ECH is still evolving. So DNS encryption should be seen as one layer of a broader privacy stack.

What Microsoft's documentation says—and doesn't say

Microsoft's official stance, detailed in the article DNS-over-HTTPS (DoH) client support on Windows, explains the fallback as a deliberate choice to maintain connectivity. The documentation notes that "Allow" mode "will fall back to plaintext DNS" and that "Require" mode "will not fall back to plaintext DNS." There's no ambiguity there, but the information is buried in enterprise-focused docs that the typical consumer never reads. The consumer-facing blog posts from the Windows Insider era often emphasized the ease of enabling DoH without highlighting the fallback caveat.

Is "Require" mode right for everyone?

For most users, the default "Allow" mode strikes a reasonable balance: it adds privacy when possible without risking connectivity loss. But for those in high-risk environments—journalists, activists, or anyone on untrusted networks like public Wi-Fi—the small chance of a DoH server outage pales in comparison to the certainty of ISP surveillance when fallback occurs. If you have a reliable DoH provider (Cloudflare, Quad9, NextDNS), the uptime risk is negligible. Switching to "Require" adds a fail-closed safety net that guarantees no plaintext DNS ever leaves your machine.

The road ahead

Microsoft continues to refine DoH integration. Build 22631 (the 23H2 update) streamlined the Settings UI and improved compatibility with third-party antivirus tools. Future updates are expected to surface the fallback option directly in Settings, reducing the reliance on group policy for this crucial privacy toggle. Until then, the fix is simple but not obvious: one policy key, one registry edit, or one MDM profile stands between your DNS queries and the open air. Know the difference, and choose what's right for your threat model.