DoH Enabled vs Disabled: Which Approach Best Balances Privacy and Compatibility?

Short answer

Enabling DoH on Windows 11 does not guarantee seamless fallback to traditional DNS in every configuration. Fallback depends on the DoH mode you choose: a preferred (encryption-optional) mode allows the client to drop back to plaintext UDP/TCP 53 when the DoH endpoint fails, while a required (encryption-only) mode deliberately refuses to fall back — name resolution simply fails if the DoH server is unreachable. For most mixed environments, DoH in preferred mode is the best balance; for corporate machines dependent on internal DNS, disabling DoH (or enforcing it via policy) is usually the safer choice.

What is confirmed vs. what is assumed

Confirmed behavior: Windows 11's native DoH client is configured per network adapter (Settings → Network → adapter → DNS server assignment, or via netsh/PowerShell). It only uses DoH for resolvers it recognizes — either servers on Microsoft's known-template list or custom entries added with netsh dns add encryption or Add-DnsClientDohServerAddress. The mode attached to each entry (allow/prefer vs. require) controls fallback.

Likely but unverified: The exact timeout and retry count before the client gives up on DoH and tries plaintext are not documented by Microsoft and may vary between Windows 11 builds. Any specific numbers you see quoted should be treated as unconfirmed. The only reliable answer for your build is to observe it directly (see below).

A caution on the registry: the EnableSecureDns key is not the primary supported configuration surface on Windows 11, and its behavior has shifted across builds. Prefer the Settings UI, netsh, or the Add-DnsClientDohServerAddress cmdlet, and verify against the documentation for your specific release.

Answering your three key questions

1. Automatic retry: Yes in preferred mode, no in required mode. Timing and retry counts are undocumented — measure on your build rather than trusting a specification.
2. Disabling DoH: It restores the classic, synchronous UDP/TCP 53 behavior that legacy applications, VPN clients with split-tunnel DNS, NRPT rules, and local resolvers typically expect. The cost is cleartext queries visible to the network path. Note that some applications bypass the OS resolver entirely, so test the actual application, not just Resolve-DnsName.
3. Observability: Use netsh dns show encryption and Get-DnsClientDohServerAddress to confirm the server's template and mode; watch Event Viewer under Applications and Services Logs → Microsoft → Windows → DNS Client Events; and capture traffic to see whether queries leave on TCP 443 (DoH) or UDP/TCP 53 (plaintext).

Verifying fallback on your machine

A scoped test that answers the fallback question definitively for your build:

# Confirm DoH state and mode
netsh dns show encryption
Get-DnsClientDohServerAddress

# Baseline resolution
Resolve-DnsName example.com

Then temporarily block TCP 443 to the DoH resolver with a firewall rule, flush the cache (Clear-DnsClientCache), and run Resolve-DnsName again while capturing with pktmon or Wireshark. If queries shift to port 53 and resolution succeeds, fallback works in your current mode; if resolution fails, you are in required mode (or the mode is stricter than you assumed). Remove the test rule afterwards.

Recommendation

• General-purpose/privacy-focused machines: enable DoH in preferred mode against a resolver on Microsoft's known-template list. You get encryption when available and fallback when it is not.
• Corporate/legacy environments: either disable DoH or manage it centrally with the Group Policy "Configure DNS over HTTPS" setting. Unmanaged DoH can bypass internal conditional forwarders, split-tunnel VPN DNS, and DNS-based filtering — often a bigger compatibility and compliance problem than cleartext DNS on a trusted network.
• Avoid required mode unless you are certain the endpoint is highly available, since a DoH outage becomes a total resolution outage.

One missing detail that would change this advice: whether your legacy applications use the OS resolver or their own DNS stack — that determines whether the OS-level DoH setting affects them at all.