DNS over HTTPS in Windows 11: encrypting resolution without blinding yourself

Domain Name System (DNS) resolution is the oldest unencrypted thing your fleet still does thousands of times a minute. Windows 11 can encrypt it. The client is already installed, the Group Policy setting already exists, and on most estates nobody has ever opened it. That is not a safe place to be, because "nobody opened it" is a default, not a decision. This post walks through exactly how the Windows 11 DNS client decides whether to encrypt a query, what that does to internal name resolution, and how to look at a real device and see what it is actually doing right now.

The problem: encryption you did not choose

Classic DNS sends your query in clear text. It travels over UDP or TCP on port 53. Anyone on the path can read it, log it, or rewrite the answer. Microsoft states this plainly: traditional DNS "exposes DNS traffic to passive monitoring, traffic analysis, and active manipulation by attackers".

DNS over HTTPS, almost always shortened to DoH, wraps that same DNS question and answer inside an ordinary HTTPS request. The transport changes. The DNS protocol itself does not. Your query now sits inside a Transport Layer Security (TLS) tunnel to the resolver, indistinguishable on the wire from any other web request.

For a laptop on hotel Wi-Fi that is straightforwardly good. For an enterprise it cuts two ways at once, and the two directions pull against each other.

The first direction is visibility. Many organisations treat DNS as a security control point. A recursive resolver that logs every query, blocks known-bad domains with a response policy zone, or sinkholes command-and-control lookups is cheap and effective telemetry. If the endpoint stops asking that resolver and starts asking a public resolver over HTTPS instead, that control point goes dark. Not degraded. Dark.

The second direction is correctness. Most enterprises run split-horizon DNS. The same name, say intranet.contoso.com, resolves to a private address from inside and either fails or resolves to something else from outside. That works only because the client asks the internal resolver. A public DoH resolver has never heard of your internal zones. Nor has it heard of your Active Directory service records, which is how a domain-joined device finds a domain controller in the first place.

So the problem is not "should we encrypt DNS". The problem is that Windows 11 ships a DoH client that a local administrator, or a user with rights on their own machine, can switch on per network adapter in the Settings app. Most estates have never expressed an opinion about it in policy. Whatever your devices are doing today, you inherited it.

Why it happens: how Windows decides to encrypt

To make a good decision you need the call chain. Here is what happens between an application asking for a name and a packet leaving the machine.

1. An application calls a resolver function in dnsapi.dll. Every normal name lookup on Windows goes through this library.
2. dnsapi.dll hands the query to the DNS Client service over a local remote procedure call. The service short name is Dnscache. It runs inside a shared svchost.exe host process as the NetworkService account.
3. Inside that host process the actual resolver logic lives in dnsrslvr.dll. This component owns the cache, the suffix search list, the Name Resolution Policy Table, and the choice of transport.
4. dnsrslvr.dll looks at the DNS servers configured on the interface the query is leaving through. For each server address it asks one question: do I already know a DoH template for this IP address?
5. If the answer is yes, and the entry is flagged for auto-upgrade, and policy allows it, the query goes out as HTTPS. If the answer is no, the query goes out in clear text on port 53.

Step four is the whole story, and it is the part that surprises people.

Windows will not resolve its way to a resolver

A DoH server is identified by a URI template, for example https://dns.quad9.net/dns-query. That template contains a hostname. To connect to it you would first have to resolve that hostname, and before DoH is running the only way to do that is a clear-text query. Microsoft rejected that design on purpose. Their words: supporting it "would mean that before a DoH connection could we established, we would have to first send a plain-text DNS query to bootstrap it", and a node on the path could tamper with that bootstrap query.

So Windows requires both halves in advance: the resolver's IP address and its DoH template, paired in a list the operating system already holds. If an IP address is not in that list, encryption is not on the table for that server, whatever policy says.

Windows ships three owners in that list out of the box. Cloudflare on 1.1.1.1 and 1.0.0.1, Google on 8.8.8.8 and 8.8.4.4, Quad9 on 9.9.9.9 and 149.112.112.112, each with two IPv6 addresses as well. That is the entire default list. Your internal resolvers are not in it and never will be unless you put them there.

Auto-upgrade, in the two places it lives

"Auto-upgrade" means silently switching a configured clear-text server to its encrypted equivalent. It exists at two levels.

Per server, each entry in the known list carries an AutoUpgrade flag and an AllowFallbackToUdp flag. Those two together are exactly what the per-adapter dropdown in the Settings app writes. Encrypted only means auto-upgrade on and fallback off. Encrypted preferred means auto-upgrade on and fallback on.

Globally, the netsh dns add global doh= switch takes three values. The help text built into netsh on Windows 11 is unambiguous about what each one does, so read it rather than guessing:

Read auto carefully. It does not mean "figure it out". It means force every well-known DoH server to use only DoH. On a device that has just picked up 8.8.8.8 from a guest network, that is a hard commitment to encryption with no fallback.

Discovery of Designated Resolvers changes the arithmetic

Microsoft co-authored an Internet Engineering Task Force draft called Discovery of Designated Resolvers, or DDR, precisely to escape the chicken-and-egg problem above. With DDR, Windows starts out knowing only a clear-text resolver IP address. It sends a service binding query for the special name resolver.arpa. If the resolver answers, the answer carries a DoH template.

That answer arrived over clear text, so it cannot be trusted yet. Windows then opens a TLS connection to the advertised DoH server and checks whether the certificate can claim ownership of the original resolver IP address. Only if it can does the encrypted path get used. This is the mechanism that lets a resolver advertise its own encryption without you hand-maintaining an address-to-template table.

DDR is controlled globally with netsh dns add global ddr=yes and per interface with netsh dns add interface name="<interface-name>" ddr=yes ddrfallback=no. Per the netsh help text, fallback to unencrypted resolution is disabled by default when per-adapter DDR is enabled.

What this does to internal names and the suffix search list

Two mechanisms decide where an internal query goes, and neither of them knows anything about encryption.

The first is the DNS suffix search list. When a user types a short name, the resolver appends each configured suffix in turn and tries the resulting fully qualified name. That expansion happens inside dnsrslvr.dll before anything leaves the machine, and the resulting query still goes to whatever servers the interface has. Encryption is a transport decision taken afterwards. So the suffix list is not broken by DoH. It is made useless if the transport to those servers cannot be established at all.

The second is the Name Resolution Policy Table, usually just NRPT. It lets you say "queries for this namespace go to that server". Microsoft confirms that NRPT and DoH compose: if Windows knows the server named in an NRPT rule supports DoH, "the traffic affected by the NRPT rule will inherit the benefits of using DoH". That is your selective lever. You can encrypt public lookups and leave contoso.com pointed at an internal resolver in clear text, or the exact reverse.

That last sentence used to be impossible on a Microsoft DNS estate, because the Windows DNS Server service did not answer DoH at all. That has changed. As of the 2026-06 Security Update (KB5094125) for Windows Server 2025 you can enable DoH on the DNS Server service itself. Details are in the fix section below.

How to verify: reading the real posture

Everything in this section is read-only. Run it before you change anything, because the answer is frequently not what the policy report claims.

Step 1: the global switches

This command prints whether the DNS client is allowed to use encrypted transports at all. It is the outermost gate, and it takes one second to check.

Step 2: which addresses can even be upgraded

Next, list the resolver addresses Windows already has a template for. This is the list that decides whether encryption is possible.

The netsh equivalent is netsh dns show encryption, which prints the same list one server per block and also accepts netsh dns show encryption server=<IP address> for a single address.

Step 3: what each interface is actually pointed at

A device with four adapters can have four different postures. Enumerate them, then cross-reference each server address against the list from step 2. That cross-reference is exactly what the companion script automates.

The registry surface

There are two separate registry areas, and confusing them wastes hours. The first is the policy area, written by Group Policy or by whatever script you deploy. The second is the DNS client's own per-interface state under the service key.

Policy parent key, stated once:

Interface state parent key, stated once. The <interface GUID> segment matches the InterfaceGuid property of Get-NetAdapter:

Here is what the interface state looks like when you open it by hand.

The Event Viewer surface

This is the part almost nobody uses, and it is the only surface that tells you whether encryption is actually happening rather than merely permitted.

Channel, stated once:

The event identifiers below come from the provider manifest Windows itself carries, readable with wevtutil gp Microsoft-Windows-DNS-Client /ge:true /gm:true. The message column is the manifest's own template text, where %1, %2 and so on are the substituted fields.

Files, services and scheduled tasks

These are the binaries in the path. Naming them matters when you are reading a crash dump, an Autoruns list or a Defender detection and trying to work out whether DNS is involved.

On services and scheduled tasks:

• Service short name Dnscache, display name DNS Client. Expected state Running, start type Automatic. It depends on nsi (Network Store Interface) and Afd (Ancillary Function Driver for WinSock). If either of those is unhealthy, DoH failures are a symptom rather than a cause.
• Scheduled tasks: none apply. There is no task under \Microsoft\Windows\ that drives DNS client encryption. Enumerating scheduled tasks filtered on "dns" on the test device returned nothing. Configuration changes take effect when the DNS Client service picks them up, which is why Microsoft's own guidance for DDR says to try a reboot if behaviour does not change.
• Log files: there is no text log. The only on-disk artefact is the event channel file listed above. If you want packet-level evidence, Microsoft's own DoH testing guidance uses the in-box packet capture tool: pktmon filter remove, then pktmon filter add -p 53, then pktmon start --etw -m real-time. A device genuinely using DoH shows little to no port 53 traffic; a device you believed was using DoH but which is not will show a steady stream.

The companion script

Doing all of the above by hand on one device is fine. Doing it on a fleet is not. Get-DohPosture.ps1 in the Windows-11-Scripts repository performs every read in this section and prints one verdict: how many configured DNS server entries this device has, and how many of them can actually be upgraded to encryption. It is strictly read-only and changes no DNS setting.

The fix: making the decision on purpose

There is no single correct setting. There are three defensible postures, and one of them is almost always wrong for a domain-joined fleet. Pick from this table first, then configure.

Group Policy, the console walkthrough

The setting lives in the Administrative Template DnsClient.admx, which ships with Windows. Its category is DNS Client under Network, and its supported-on marker in the template is Windows 10 version 20H2 and Windows Server 20H2 and later.

1. Open the Group Policy Management Console on a management workstation, or gpedit.msc for a local test.
2. Create or edit a Group Policy Object scoped to a small pilot group of machines. Do not start with the whole estate.
3. Navigate to Computer Configuration > Administrative Templates > Network > DNS Client.
4. Double-click Configure encrypted name resolution. Older documentation calls this Configure DNS over HTTPS (DoH) name resolution; see the amber callout below.
5. Select Enabled. Three dropdowns appear, labelled Configure encryption options, Configure DoH specific options and Configure DoT specific options.
6. In Configure encryption options choose Prohibit encryption, Allow encryption or Require encryption per the table above.
7. In Configure DoH specific options choose Allow DoH or Block DoH. In Configure DoT specific options choose Allow DoT or Block DoT. The template's own help text gives the reason these exist: "in order to force DoT name resolution only, a combination of Require encryption and Block DoH would be needed (vice versa to force DoH)".
8. Click OK, then run gpupdate /target:computer /force on a pilot device.
9. Confirm the result by reading the registry value, not the policy report. It should appear as DoHPolicy under the DNSClient policy key documented above.

Adding your own resolver to the known list

If you want encryption to an internal resolver, Windows has to be told the address-to-template pairing in advance. Two interchangeable ways to do it. First netsh, whose syntax on Windows 11 also covers DoT:

Second, the PowerShell equivalent, which is what you would put in a deployment script. Add-DnsClientDohServerAddress creates a new entry and Set-DnsClientDohServerAddress edits an existing one.

Setting -AllowFallbackToUdp $False is the strict option: if the encrypted query fails, the query fails. Setting it to $True keeps resolution working but gives you, in Microsoft's own words, no notification when queries are switched from DoH to plain text. That silence is the reason the event channel matters.

Making the internal resolver capable in the first place

Adding a template for a server that does not serve DoH just moves the failure. If your resolvers are Windows DNS, this is now possible natively. On Windows Server 2025 with the 2026-06 Security Update (KB5094125) or later, you bind a certificate and enable the protocol:

1. Obtain a certificate whose Enhanced Key Usage includes Server Authentication (1.3.6.1.5.5.7.3.1) and whose Subject Alternative Name matches the hostname or IP address in the DoH URI template you intend to publish. The private key must be in the Local Computer store without strong private key protection.
2. Import it with Import-PfxCertificate -FilePath "<pfxpath>" -CertStoreLocation "Cert:\LocalMachine\My".
3. Bind it to the listening port with netsh http add sslcert ipport=0.0.0.0:443 certhash=<thumbprint> appid="{aaaaaaaa-0b0b-1c1c-2d2d-333333333333}", using a GUID you generate.
4. Allow inbound TCP 443 on the host firewall and on any network device in front of it.
5. Enable the protocol with Set-DnsServerEncryptionProtocol -EnableDoh $true -UriTemplate "https://dns.contoso.com:443/dns-query", then restart the DNS service.
6. Confirm with Get-DnsServerEncryptionProtocol, and check for event ID 822 in the DNS Server log, which Microsoft documents as indicating the DoH service started successfully.

Intune: there is no setting for this

So for a cloud-managed estate the practical routes are a platform script or a remediation. Here is the Intune walkthrough for the remediation route, which has the advantage of a detection script you can report on.

1. Sign in to the Microsoft Intune admin center at intune.microsoft.com.
2. Go to Devices > Manage devices > Scripts and remediations.
3. On the Remediations tab select Create script package.
4. Give it a name such as DNS - encrypted name resolution posture and a description that records which of the three postures you chose and why. Future you will need that.
5. Upload a detection script that reads DoHPolicy from the DNSClient policy key and exits non-zero when it does not match your intended value. The companion script in this post is a read-only reporter, not a detection script, so keep them separate.
6. Upload a remediation script that writes the intended DoHPolicy value, and if you are adding an internal resolver, calls Add-DnsClientDohServerAddress for it.
7. Set Run this script using the logged-on credentials to No. This is a machine setting under HKEY_LOCAL_MACHINE and needs SYSTEM.
8. Set Enforce script signature check according to your own signing standard, and Run script in 64-bit PowerShell to Yes.
9. Assign to a pilot group of no more than a handful of devices, with a daily schedule.
10. Wait a full cycle, then run the posture script on a pilot device and compare what the policy says with what the device is doing.

For completeness, the per-user, per-adapter path that your users can reach without you is worth knowing, because it is where an unmanaged posture comes from:

That dropdown is only enabled when the address entered is in the known-template list, which is why a user cannot accidentally encrypt to your internal resolver. It offers Encrypted only, Encrypted preferred with unencrypted allowed, and Unencrypted only, and Microsoft notes that the middle option gives no notification when queries drop back to clear text.

Defender: what DoH does and does not blind

This is the claim most worth checking before you repeat it, because the popular version of it is wrong.

Microsoft Defender for Endpoint network protection does not depend on DNS. The documentation is specific: in non-Microsoft Edge processes, "Network Protection determines the fully qualified domain name for each HTTPS connection by examining the content of the TLS handshake that occurs after a TCP/IP handshake". The name comes from the TLS handshake, not from a DNS query. Encrypting DNS therefore does not blind network protection, web content filtering or custom domain indicators.

What does blind them is a different pair of technologies with confusingly similar names. The same documentation states that "blocking FQDNs in non-Microsoft browsers requires that QUIC and Encrypted Client Hello be disabled in those browsers", and adds that "Encrypted Client Hello and the QUIC protocol are not supported with network protection functionality". If you are worried about endpoint web filtering being bypassed, QUIC and Encrypted Client Hello are your problem, not DoH.

What DoH genuinely blinds is everything that watched DNS on the network: resolver query logs, response policy zones, DNS sinkholes, DNS-layer threat feeds, and any detection built on the port 53 stream. Those are real losses and they are the reason many enterprises choose Prohibit encryption. But be precise about which control you are protecting, because "DoH will break Defender" is not true and will cost you credibility in the change advisory board.

Proof it worked: real output from a real device

Below is a genuine run of the companion script on a Windows 11 Enterprise build 26200 device, elevated. The computer name, adapter GUIDs and internal suffixes have been replaced or suppressed; every other value is exactly what the script printed. Note that the script deliberately does not print the suffix search list contents.

Read the verdict lines together rather than separately. That is the whole point of the script. Three separate surfaces all said something encouraging, and the cross-reference said nothing is encrypted. A policy report would have shown the first three and stopped.

To turn a run like this into evidence of encryption actually working, enable the operational channel, reproduce a lookup, and re-run:

Two caveats on that block. Clear-DnsClientCache flushes the resolver cache, which is a transient operation rather than a configuration change, but it is still a change, so it does not appear in the read-only posture script. And enabling an event channel is itself a configuration change, which is why the posture script reports the channel state and refuses to enable it for you.

References

• Secure DNS Client over HTTPS (DoH) on Windows Server 2022 - the client-side reference: known-server list, the Group Policy node, the Settings app dropdown values, the domain-joined warning, and NRPT with DoH.
• DNS Encryption using DNS over HTTPS in Windows and Windows Server - how DoH works, the DNSSEC comparison, and the list of things server-side DoH does not encrypt.
• Enable DNS over HTTPS in DNS Server on Windows Server - certificate requirements, netsh http add sslcert, Set-DnsServerEncryptionProtocol, and DNS Server event 822.
• KB5094125 - the 2026-06 Security Update for Windows Server 2025 that brings DoH to the DNS Server service.
• Get-DnsClientDohServerAddress - cmdlet reference for reading the known DoH server configuration.
• Policy CSP - ADMX_DnsClient - the complete published policy list for the DNS client area. Read it to confirm for yourself that no DoH policy is exposed to MDM.
• Windows Insiders gain new DNS over HTTPS controls - the Windows networking team on the Group Policy options, the netsh and PowerShell surfaces, NRPT inheritance, and why a DoH template alone is not enough.
• Making DoH Discoverable: Introducing DDR - the resolver.arpa service binding query, the certificate ownership check, and the DDR netsh commands.
• Windows Insiders can now test DNS over HTTPS - the original test-build post, including the pktmon port 53 verification steps and the statement that registry configuration of DoH would not be supported in general release builds.
• Use network protection to help prevent connections to malicious or suspicious sites - the TLS handshake mechanism, and the QUIC and Encrypted Client Hello limitations that are often misattributed to DoH.
• Companion script: github.com/Imran76Awan/Windows-11-Scripts, folder dns-over-https-windows-11-configuration, file Get-DohPosture.ps1. Read-only, no module required, runs on Windows PowerShell 5.1 and PowerShell 7.