Windows 11 supports DNS over HTTPS (DoH), a technology that encrypts DNS requests to help protect browsing-related information from network monitoring and manipulation. However, manually entering DNS servers such as Cloudflare or Quad9 does not necessarily mean those requests are encrypted. Windows can use a privacy-focused DNS provider while still sending ordinary, unencrypted DNS queries. Understanding the difference between selecting a DNS server and enabling DNS encryption is essential for configuring Windows 11 correctly. This guide explains how DoH works, how to enable it, how to manage fallback behavior, and how to check whether your computer is actually using encrypted DNS.
Why Changing DNS Servers Does Not Automatically Enable Encryption
The Domain Name System translates domain names into IP addresses that computers can use to establish network connections. When someone enters a website address in a browser, a DNS lookup may be required before the connection begins. Traditional DNS commonly uses UDP or TCP on port 53, and those requests are generally transmitted without encryption.
Windows allows users to replace the DNS servers supplied automatically by their router or internet service provider. Popular alternatives include Cloudflare, Quad9, and other public DNS services. Changing this setting determines which resolver receives applicable DNS queries, but it does not automatically establish an encrypted connection.
For example, a computer configured to use Cloudflare at 1.1.1.1 might still send plaintext DNS requests unless its encryption settings are configured appropriately. The selected provider could therefore be correct while the expected privacy protection is missing.
Windows 11 maintains DNS server addresses and encryption configurations as related but distinct settings. Older network configuration interfaces may allow users to enter preferred DNS addresses without clearly displaying whether DNS over HTTPS is active.
A recognized DNS provider address is not proof of encrypted DNS communication. The relevant question is whether the operating system actually transports DNS requests through an authenticated, encrypted connection.
This distinction matters when reviewing an existing configuration. A system might have used a trusted public resolver for months without ever encrypting its DNS traffic.
What DNS Over HTTPS Protects and What It Cannot Hide
DNS over HTTPS transports DNS messages through HTTPS connections protected by Transport Layer Security. Instead of exposing the requested domain name in an ordinary DNS packet, the client sends the DNS query inside an encrypted HTTPS exchange with its selected resolver.
This can reduce the ability of intermediaries, including network operators and observers on shared Wi-Fi, to read or modify DNS requests while they travel between the device and the resolver.
However, DoH is not equivalent to a VPN or a complete internet anonymity system. Its protection applies primarily to DNS communication rather than every aspect of a network connection.
| Information or Activity | Protection With DoH | Important Limitation |
|---|---|---|
| DNS queries | Encrypted between the client and the DoH resolver | The selected DNS provider can still process the queries |
| DNS responses | Protected against modification in transit | Encryption does not guarantee that every DNS answer is trustworthy |
| Destination IP addresses | Not hidden by DoH | Network operators can still observe connection destinations |
| Website hostnames | DNS requests are encrypted | Other connection metadata may still expose hostnames |
| Website content | Not encrypted by DoH itself | HTTPS provides separate protection for web content |
| Application activity | Depends on the application's DNS behavior | Applications may use their own resolvers or bypass Windows DNS settings |
One frequently misunderstood limitation concerns Server Name Indication, or SNI. When a TLS connection is established, the requested hostname may be visible in the handshake unless an additional protection such as Encrypted Client Hello is supported and successfully negotiated.
Importantly, this does not mean that the domain requested inside a DoH query becomes visible as plaintext. The encrypted DNS request and the hostname information potentially exposed by a subsequent website connection are different parts of the communication process.
DoH therefore addresses a specific privacy weakness: exposed DNS traffic. It should be evaluated as one part of a broader security configuration rather than a guarantee that an internet service provider cannot infer which online services are being accessed.
How to Enable DNS Over HTTPS in Windows 11
Windows 11 provides native DNS over HTTPS settings through the modern network configuration interface. The precise wording and placement of some controls can vary with Windows releases, but the underlying configuration process remains similar.
- Open Windows Settings.
- Select Network & internet.
- Open the active Wi-Fi or Ethernet connection.
- Locate DNS server assignment and select Edit.
- Change the DNS assignment mode from Automatic (DHCP) to Manual.
- Enable IPv4 and enter the preferred and alternate DNS server addresses.
- Choose an encrypted DNS option for each supported server, preferably the encrypted-only option when strict encryption is required.
- If using IPv6, configure appropriate IPv6 DNS addresses and their encryption settings as well.
- Save the configuration and inspect the resulting DNS settings.
Some Windows 11 interfaces describe the secure setting as Encrypted only (DNS over HTTPS). Others expose controls such as On (automatic template), On (manual template), or Fallback to plaintext.
For a recognized DNS provider, Windows may already know the appropriate DoH endpoint. When a provider is not recognized automatically, its documented HTTPS template may need to be entered manually.
The template identifies the HTTPS endpoint used for DNS requests. For example, the standard Cloudflare resolver uses https://cloudflare-dns.com/dns-query, while Quad9 offers https://dns.quad9.net/dns-query.
IPv4 and IPv6 deserve separate attention. A computer with working IPv6 connectivity may have IPv6 DNS servers configured independently of IPv4. Configuring encrypted IPv4 DNS while leaving another active DNS path unprotected can create a configuration that does not match the user's expectations.
Likewise, changing the DNS configuration for a Wi-Fi adapter does not necessarily modify Ethernet, VPN, virtual network, or other interfaces. Each relevant connection should be reviewed separately.
Microsoft provides additional technical details in its documentation about Windows DNS over HTTPS client support.
Comparing Cloudflare, Quad9, and Encrypted DNS Options
Several public DNS providers support encrypted resolution. Their differences extend beyond DNS performance and include filtering policies, privacy practices, threat protection, and available service endpoints.
The following examples illustrate commonly used configurations. The IPv6 addresses shown are primary addresses, and additional alternatives may be available from each provider.
| DNS Service | IPv4 Addresses | Example IPv6 Address | DoH Endpoint |
|---|---|---|---|
| Cloudflare Standard | 1.1.1.1 1.0.0.1 |
2606:4700:4700::1111 | https://cloudflare-dns.com/dns-query |
| Cloudflare Malware Blocking | 1.1.1.2 1.0.0.2 |
2606:4700:4700::1112 | https://security.cloudflare-dns.com/dns-query |
| Quad9 Secure | 9.9.9.9 149.112.112.112 |
2620:fe::fe | https://dns.quad9.net/dns-query |
Cloudflare's standard DNS service provides general-purpose resolution without the malware-blocking policy associated with its family-oriented resolver variants. Its malware-filtering service uses a separate set of DNS addresses and a corresponding encrypted endpoint.
Quad9's secure resolver combines encrypted DNS support with blocking of domains identified as malicious through its threat intelligence systems. Its standard secure IPv4 addresses are 9.9.9.9 and 149.112.112.112, while its IPv6 options include 2620:fe::fe and 2620:fe::9.
Filtering services can sometimes block a legitimate domain incorrectly. They also cannot guarantee protection from every malicious website, phishing campaign, or harmful download.
Provider selection should consider reliability, privacy documentation, filtering requirements, and compatibility with the applications and networks being used.
Configuration details for Quad9 are available in its Windows 11 encrypted DNS setup guide.
Encrypted DNS Fallback: Privacy Versus Reliability
Fallback behavior determines what happens when the configured encrypted DNS service cannot be reached or used successfully. It is one of the most consequential settings in a DoH configuration because it determines whether ordinary DNS can be used when encryption fails.
Windows supports different behaviors depending on its configuration and the selected DNS server.
| Configuration | Expected Behavior | Trade-Off |
|---|---|---|
| Encrypted only | Uses encrypted DNS for the configured resolver without falling back to plaintext | DNS resolution may fail if DoH is unavailable |
| Encrypted preferred with fallback | Attempts encrypted DNS but permits ordinary DNS if necessary | Improves compatibility while allowing some queries to be unencrypted |
| Unencrypted only | Uses traditional DNS transport | Does not provide DoH protection |
Disabling fallback can be appropriate when preventing plaintext DNS is more important than maintaining connectivity under every possible network condition. However, it can also create problems on networks that block encrypted DNS endpoints or require preliminary DNS resolution for authentication.
Public Wi-Fi networks with captive portals are a common example. A device may need to access a local login page before normal internet access is permitted, and strict encrypted DNS settings can sometimes interfere with that process.
Some home routers can encounter a related issue after losing their system clock. If the router's time is incorrect, certificate validation for the encrypted DNS connection may fail. If the router then needs DNS to locate its time synchronization service, a dependency problem can develop.
Disabling plaintext fallback offers a stronger preference for encrypted DNS, but it does not eliminate all possible DNS leaks or guarantee uninterrupted connectivity. The appropriate choice depends on the network environment and the consequences of DNS resolution failures.
For a stationary desktop connected to a predictable home network, an encrypted-only configuration may be practical. For a laptop regularly using hotels, airports, workplaces, and public hotspots, compatibility considerations may be more significant.
Checking and Managing DNS Encryption With PowerShell
PowerShell offers more detailed visibility into Windows DNS settings than the graphical interface alone. It can display registered DoH servers, assigned DNS addresses, encryption templates, and fallback configurations.
To inspect the DNS over HTTPS servers recognized by Windows, open PowerShell and run:
Get-DnsClientDohServerAddress
This command lists configured DoH server definitions and their associated properties. Relevant fields include the server address, HTTPS template, automatic upgrade setting, and plaintext fallback permission.
To review the DNS servers actually assigned to network interfaces, use:
Get-DnsClientServerAddress
These commands answer different questions. The first reports registered encryption configurations, while the second identifies the DNS addresses assigned to network interfaces.
A server appearing in the DoH configuration list does not automatically mean that the active network adapter is using it. Both the resolver assignment and its encryption behavior need to be checked.
For an existing Quad9 DoH server definition, the following PowerShell command can enable automatic encrypted resolution and disable fallback to ordinary DNS:
Set-DnsClientDohServerAddress -ServerAddress '9.9.9.9' -AllowFallbackToUdp $False -AutoUpgrade $True
The corresponding command for Quad9's primary IPv6 address is:
Set-DnsClientDohServerAddress -ServerAddress '2620:fe::fe' -AllowFallbackToUdp $False -AutoUpgrade $True
The AutoUpgrade setting tells Windows to use the registered encrypted DNS configuration when the corresponding server is selected for name resolution. AllowFallbackToUdp set to False prevents fallback to plaintext DNS for that configuration when automatic upgrading is enabled.
These commands modify existing DoH definitions. If a server has not yet been registered, it must first be added with a valid HTTPS template rather than assuming the modification command will create it.
For example, an unregistered Quad9 IPv4 DoH definition can be added with:
Add-DnsClientDohServerAddress -ServerAddress '9.9.9.9' -DohTemplate 'https://dns.quad9.net/dns-query' -AllowFallbackToUdp $False -AutoUpgrade $True
Run configuration-changing commands in an elevated PowerShell session when administrative permissions are required. Before modifying network settings, record the existing values so they can be restored if necessary.
Windows also supports inspecting registered DNS encryption settings through:
netsh dns show encryption
Depending on the Windows version and supported command syntax, the related netsh dnsclient command context can expose additional settings.
PowerShell and netsh are useful for inspecting configuration, but their output alone does not prove that every DNS query generated by every application is encrypted.
Do You Really Need Three DNS Servers?
A common networking recommendation is to configure three DNS servers so that another resolver remains available if one or two stop responding. However, there is no universal rule requiring three DNS servers on a Windows computer.
For many home networks, two reliable DNS server addresses are sufficient. Adding more servers does not automatically provide additional privacy, faster browsing, or more reliable resolution.
It is also important to distinguish between multiple IP addresses and independent service providers. Cloudflare's 1.1.1.1 and 1.0.0.1 are separate resolver addresses, but they belong to the same provider.
If a problem affects that provider's broader infrastructure or network reachability, using another address from the same provider might not solve it. A resolver operated by an unrelated organization may offer a different kind of redundancy.
Nevertheless, mixing DNS providers introduces considerations of its own.
- Different providers may return different DNS answers because of filtering policies or service configuration.
- DNS queries may be distributed across more than one organization, expanding the number of parties that process them.
- Applications and operating systems do not necessarily query resolvers in a simple fixed primary-secondary-tertiary sequence.
- Encrypted DNS must be configured appropriately for every resolver that may actually be used.
- Additional DNS addresses do not correct problems caused by incorrect network routing, firewall rules, or blocked encrypted connections.
Windows can maintain multiple DNS server addresses through its underlying network configuration mechanisms, even when a graphical settings panel prominently displays only preferred and alternate fields.
However, adding a third server through an older Control Panel interface does not guarantee that Windows will automatically encrypt requests sent to it. The server's assignment, DoH registration, and fallback settings still require verification.
For ordinary desktop use, a straightforward two-address configuration is often easier to inspect and troubleshoot. More complex arrangements may be appropriate when users have specific redundancy or filtering requirements.
How to Verify DNS Encryption and Investigate DNS Leaks
After enabling DoH, verification should go beyond checking whether the expected DNS provider appears in Windows settings. A system can contain correct-looking configuration values while some DNS requests still use a different route.
The first useful check is to compare the registered DoH configurations with the addresses assigned to active interfaces. Get-DnsClientDohServerAddress and Get-DnsClientServerAddress provide a starting point for that comparison.
Next, a DNS leak testing service can help identify which public resolvers appear to be handling DNS queries. If an unexpected internet service provider resolver appears, further investigation may be justified.
However, these tests have limitations. A browser-based DNS leak test generally reflects the resolution behavior exercised by that browser and the test itself, rather than proving how every application on the computer resolves names.
Different results can occur because of browser-specific encrypted DNS settings, VPN software, network policies, multiple active interfaces, cached results, or differences in how the testing service identifies resolvers.
For a more detailed investigation, packet capture tools can help identify whether conventional DNS traffic is leaving a particular network interface. Traffic using UDP or TCP port 53 may indicate unencrypted DNS communication, although not every packet on that port necessarily represents a public internet DNS lookup.
Encrypted DNS over HTTPS usually uses HTTPS transport, commonly on port 443. Depending on the implementation, this may involve TCP or QUIC-based communication. Observing encrypted HTTPS traffic to a resolver supports the investigation, but additional context is needed to establish which application generated it.
A practical verification process can include the following checks:
- Confirm the intended DNS addresses are assigned to the active Windows network interface.
- Confirm each intended resolver has the correct DoH template and encryption configuration.
- Review whether plaintext fallback is enabled or disabled.
- Check both IPv4 and IPv6 configurations where applicable.
- Examine browser-specific DNS settings and active VPN connections.
- Use DNS leak tests to look for unexpected public resolvers.
- Investigate unexpected plaintext DNS traffic with network diagnostic tools when necessary.
For Quad9 users, the provider also documents a DNS-based method of inspecting its service protocol through a lookup of proto.on.quad9.net. This can provide additional information about the connection used for that particular lookup.
No single diagnostic command or website should be treated as conclusive evidence that all DNS requests from every application are encrypted at all times.
Router-Level DNS, Browser Settings, and Network-Wide Protection
Encrypted DNS can be configured in several places, and each approach affects a different part of the network. Windows-level DoH is only one possible arrangement.
A router that supports DNS over HTTPS or DNS over TLS can forward DNS requests through an encrypted upstream connection. This allows compatible devices to use the router as a local DNS resolver without requiring every device to maintain a separate encrypted upstream configuration.
However, this arrangement does not necessarily encrypt DNS traffic between individual devices and the router. Devices may still communicate with the router using ordinary DNS over the local network, while the router encrypts requests sent to its upstream provider.
Some routers also support DNS caching, filtering, and local hostname resolution. These features can be useful when many devices share the same network, although caching benefits depend on workload and configuration.
Router-level protection also has geographic limitations. A laptop that leaves the home network no longer benefits from that router's upstream DNS configuration unless a separate connection mechanism, such as an appropriately configured VPN, routes its DNS traffic through the home network.
Browsers introduce another layer of complexity. Modern browsers may provide their own Secure DNS settings and can sometimes use a different encrypted resolver from the one configured in Windows.
| Configuration Location | Typical Coverage | Main Consideration |
|---|---|---|
| Windows 11 DoH | Applications using the Windows DNS client | Applications with independent DNS implementations may bypass it |
| Browser Secure DNS | DNS lookups handled by that browser | Other applications may continue using different DNS settings |
| Router DoH or DoT | Devices using the router's DNS forwarding service | Devices can bypass the router or use another network |
| Local DNS proxy | Devices and applications directed to the proxy | Requires appropriate forwarding, security, and maintenance |
| VPN with DNS protection | Traffic covered by the VPN configuration | DNS routing and leak protection depend on the VPN implementation |
For users who require local control, software such as Technitium DNS Server, Unbound, Blocky, and dnscrypt-proxy offers different approaches to DNS caching, forwarding, filtering, and encrypted upstream communication.
These tools are not interchangeable in every respect. Some are full DNS servers, while others are primarily forwarding proxies or recursive resolvers. They also vary in complexity and the amount of ongoing maintenance required.
There is no single arrangement that is automatically best for every household. A laptop that regularly changes networks may benefit from device-level encryption, while a fixed collection of home devices may be easier to manage through centralized DNS infrastructure.
Common DNS Over HTTPS Problems and Troubleshooting
Encrypted DNS can fail for reasons unrelated to the chosen provider's general reliability. Problems may arise from configuration errors, network restrictions, outdated software, or conflicts between different DNS management layers.
DNS server configured but encryption remains disabled. This can happen when the DNS address was entered through an interface that changes resolver selection without setting up the DoH template. Review the modern Windows network settings and registered DoH configuration.
Websites stop resolving after disabling fallback. The network may block the selected DoH endpoint, or the endpoint may be temporarily unreachable. Confirm connectivity and resolver settings before deciding whether strict encrypted-only operation is suitable.
IPv4 configuration looks correct but unexpected resolvers appear. Inspect active IPv6 DNS addresses and other interfaces. A computer may have more than one viable DNS resolution path.
Windows settings and browser results disagree. A browser may be configured to use its own secure resolver. Check the browser's DNS settings before treating the discrepancy as a Windows encryption failure.
Public Wi-Fi authentication does not work. Captive portals sometimes require access to local or network-provided DNS services. Temporarily restoring a compatible network configuration may be necessary to complete authentication.
DNS settings change after reconnecting. Network management software, VPN clients, organizational policies, or adapter configuration changes may influence the effective resolver configuration. Identify which component manages the connection before repeatedly modifying the same settings.
Router-based encrypted DNS stops working after a restart. Check whether the router has valid system time, working certificate validation, and a functioning method of reaching its time synchronization servers.
A third DNS server appears in the legacy interface but not the modern settings view. Inspect the actual adapter DNS address list rather than assuming that the modern interface displays every configured value. Confirm separately whether an encrypted configuration exists for that address.
Network troubleshooting should focus on identifying the active resolution path instead of assuming that one registry change or command-line setting controls every DNS-related component.
Windows may combine system resolver settings with per-interface configuration, domain-specific resolution policies, encrypted resolver discovery, and behavior introduced by applications or network management tools.
As a result, a configuration that works on one computer may behave differently on another system with a different Windows build, VPN client, browser, or network environment.
Choosing an Encrypted DNS Configuration That Fits Your Network
DNS over HTTPS can reduce exposure of DNS requests to intermediaries, but its practical value depends on correct configuration and realistic expectations. Simply entering a public DNS server address does not establish that encryption is active.
For many Windows 11 users, the most manageable arrangement involves selecting a trustworthy resolver, enabling encrypted DNS on the relevant network interface, reviewing IPv4 and IPv6 settings, and checking whether plaintext fallback matches their privacy requirements.
Users with advanced networking needs may prefer router-level encryption, a local DNS proxy, or additional DNS filtering. Others may find that Windows' built-in controls provide an adequate balance of convenience and visibility.
Adding a third DNS server should be considered in terms of actual redundancy rather than as a general requirement. Similarly, disabling fallback should be evaluated against the possibility of connectivity failures on restrictive networks.
Most importantly, DNS encryption should not be confused with complete anonymity. Destination addresses, connection metadata, browser behavior, and the selected resolver's own data-handling practices remain relevant.
The useful distinction is between having encrypted DNS configured and having sufficient evidence that the intended connections are actually using it. Understanding that distinction allows Windows users to make informed decisions about privacy, reliability, and network management without assuming that any single setting solves every problem.
Tags
Windows 11 DNS over HTTPS, Windows 11 encrypted DNS, DoH configuration, DNS privacy, Cloudflare DNS, Quad9 DNS, PowerShell DNS settings, DNS leak prevention, DNS encryption verification, Windows 11 network security
Post a Comment