In February 2026, Microsoft opened the public preview for DNS over HTTPS in Windows Server 2025. Let’s see if the rewards to be reaped from this are worth the hassle.

If you’re the TL;DR type of person, jump right here.

DISCLAIMER: This post is not about the intricacies of setting up DoH and especially of distributing it to clients. For the sake of this post, I assume that the reader is familiar with the general concepts. I may, at a later time, publish a step-by-step for DoH deployment in a typical Active Directory-based Windows environment.

DISCLAIMER: This post is written PRE RELEASE. Some of the restrictions mentioned here may be lifted before GA.

What is DoH?

DNS over HTTPS (DoH), regulated by RFC8484, encapsulates DNS queries and the ensuing replies in HTTPS traffic on a configurable TCP port, thus ensuring, first and foremost, the confidentiality but also, to some extent, the integrity of the DNS traffic. It is not the same as DNSSEC, which is governed by RFC9364 – it guarantees the authenticity of DNS replies, while both the query and the reply to it are transmitted in cleartext. DNSSEC has been available in Windows since Server 2012 but so far did not get that much traction in the field, as far as I have been able to determine. D0H is also not the same as DNS over TLS (DoT, RFC7858) which uses the fixed port 853.

The obvious benefits of this technology are:

• your clients can verify who they are talking to for DNS queries, like in any HTTPS scenario *
• someone listening on the wire will not be able to determine what your clients query DNS for and what replies they get
• your clients can verify the integrity of the responses they receive from the server („attacker-in-the-middle“ protection) *

* at least if certificate pinning is part of the implementation OR you are 100% certain no one can abuse your PKI

The equally obvious drawbacks are at least as important to keep in mind:

• only systems that actually support DoH can participate in it so you are probably stuck with a dual-stack DNS for the foreseeable future
• DoH endpoints usually include FQDNs that must be managed locally on the clients, unless you can make use of DDR (Discovery of Designated Resolvers, RFC9462). Keep in mind that those FQDNs do not, in fact, have to be resolvable at all, let alone to the DNS server’s IP address!
• DoH has a dependency on certificate validation (for the DoH endpoint), which usually includes connecting to CDP or OCSP, which requires resolving FQDNs, so you have to perform name resolution in order to decide whether you should trust this server for name resolution – dual-stack DNS forever is the best case here
• if done properly from the advantages‘ point of view (i.e. with cert pinning) it prevents firewalls and network-sniffing Intrusion Detection Systems from reviewing the DNS queries made by the clients and maybe even blocking the potentionally malicious ones (think of your trusty PiHole magically becoming useless)
• it becomes increasingly difficult to block rogue external name resolution as long as HTTPS is allowed out because any webserver out there can potentially double as a DNS server

And this is just assuming that the technology is already working as expected – to get to that point, you have to overcome several additional challenges:

• You cannot deploy DoH endpoints („templates“) using DHCP because Windows Server does not yet support the Designated Resolver Discovery (DDR) mechanism so, getting your clients to target the correct servers for DoH becomes a client management task rather than a network management one. There are tricks to solve this, but at this time, they are just that – tricks 🙂
• You need an internal PKI to provide server certificates for DNS  servers (or access to an external PKI, although those will only issue fairly short-lived certificates, and replacing a DNS server cert is not trivial, plus there is the burden of resolving the CDP name in order to validate the certificate)

The disadvantages being numerous, hard to ignore and hard to overcome, let’s try to threat model, always keeping in mind that this post is not about DoH in general but about DoH in Windows Server, so that we are probably looking at DNS resolution happening within the LAN, rather than on the public Internet.

Modelling the threats

Microsoft writes in the article linked above:

In today’s digital world, information is king and securing it is non-negotiable. With most data stored digitally and accessed remotely, network security is critical. At the heart of every network lies DNS, because everything depends on it.

However, the challenge is that DNS traditionally operates in the clear: queries and responses are exposed to anyone watching, giving attackers visibility into network details and user behavior, thereby creating opportunities for attacks.

In other words, the primary threat here is someone listening on the wire. Here, queries are probably of more interest to the attacker than replies.

Sniff, Sniff, Hurrah?

Contrary to the popular belief, packet sniffing in a modern business network isn’t a trivial task. It certainly used to be, back when coaxial cables and passive hubs were serving the majority of Ethernet networks, and in the early days of WiFi, when it was considered acceptable to run it unencrypted simply because it was „within the building“. Today, the situation is vastly different. Finding a „hot“ access port does not give one the ability to monitor the entire network or even a particular segment of it. If it’s not a certain node you’re after but a multitude of devices, the only reliable way to sniff their traffic is to gain enough access to the switching infrastructure as to configure a tapping port at the core of the network (AND to have a device the attacker controls physically attached to that port). Even if you manage to elevate undetected up to that point, the moment you start vacuuming up the entire network’s frames, all sorts of alarm bells will go off. (If you are deliberately only attacking one node AND manage to land on the same access switch and VLAN as that node, you might get away with ARP poisoning IF that access switch does not have ARP poisoning protection activated.)

This is to say that the „black“ attackers in the below picture already have one hell of access. I would argue that someone who got to this point probably doesn’t need DNS anymore and can focus their sniffing activity on credentials and tokens. And for discovering external addresses, they can probably just use the local cache of compromised workstations (on Windows, this does not even require local admin rights).

Sniffing in public

There is definitely value in discovering what public FQDNs the private servers and clients are requesting. If everyone is using a certain SaaS application on a regular basis, spoofing it or maybe even exploiting a known vulnerability there can present a good ingress vector. If remote users connect to a VPN in order to get to company resources, DNS will reveal the address of the VPN concentrator. (Does anyone even use the term „concentrator“ anymore? Yes, I’m that old…) Getting the VPN portal address from a road warrior can be done on a public unencrypted WiFi – or even on an encrypted one, if the attacker happens to own the infrastructure. Getting the SaaS application name can also be done in public, unless DNS for everything work-related is routed through VPN.

What about Attacker-in-the-Middle?

This family of techniques does not get much focus in the Microsoft article, but for the sake of completeness, let’s look at how DoH potentially changes the playing field here:

• Any scenarios where the attacker can coerce the victim’s client to perform multicast name resolution, still apply.
• Any scenarios where the attacker manages to change local DNS resolution settings on a victim’s client, still apply.
• Traffic redirection by spoofing ARP would lead to certificate validation failure – UNLESS the attacker is in possession of another trusted certificate by the same name. If DoH is enforced, this causes name resolution to fail and ultimately offers protection. If DoH is not enforced, the client will fall back to unencrypted DNS and fall victim to the attack.

Traffic redirection by spoofing name resolution for the DoH endpoint does not apply because the name in the URI is not actually being resolved – it just gets passed in the SNI field of the TLS request and ensures that the client is talking to the correct host by validating the certificate’s SAN against the name in the DoH template. A clever trick that prevents one half of the bootstrapping problem!

What attack vectors will private DoH prevent?

At the time of writing, Windows DNS will not use DoH (even if configured on the server) to contact other DNS servers for recursive queries or zone transfers. So, listening on the wire in the backend would reveal external FQDNs queried by the clients even if those queries would be protected by DoH from an attacker listening on the client segment.

For a client on a public network, DoH to a public DNS server will protect against sniffing on an unencrypted (or attacker-owned) WiFi.

In short, DoH will prevent the following attack scenarios:

Attack vector	Private DoH	Public DoH
Sniffing out external FQDNs on a public network	no	yes
Sniffing out external FQDNs on a private network (global mirror)	no	no
Sniffing out external FQDNs on a private network (client segment)	yes	no
Sniffing out external FQDNs on a private network (server segment)	no	no
Sniffing out internal FQDNs on a private network (global mirror)	no	no
Sniffing out internal FQDNs on a private network (client segment)	yes	no
Sniffing out internal FQDNs on a private network (server segment)	no	no

It is not much, but if you ever talked to me about systems hardening, you know my position: any measure that doesn’t cost much, doesn’t break anything in production and prevents at least something, should be implemented, so that you don’t have to worry about those particular attack vectors down the road. Which brings us to the next and final part…

The operational cost of private DoH

Now that we determined that the security benefit of implementing private DoH is limited, what about the cost? The operational cost of a feature always has three components to it:

1. Money + effort required to set it up
2. Money + effort required to maintain it
3. Money and effort required to troubleshoot it, multiplied by the frequency of a troubleshooting event.

Let’s look at these three in more detail.

Setting up private DoH

If you have your PKI already set up and secured, all you need is a server certificate for each DoH endpoint. Before you decide on using one global name or individual names for your DoH endpoints, you need to know how you are going to distribute the configuration. Microsoft has implemented DDR in Windows DNS client some time ago. At the time of writing, Windows DNS Server does not automatically resolve the SVCB record _dns.resolver.arpa required for DDR to the name in its own certificate – or at all, for that matter. Therefore, if you plan on using DDR, a single name for all DoH-enabled DNS servers offers great simplification and improved reliability. If you distribute explicit DoH endpoints, having individual names allows your DNS servers to auto-enroll for certificates (which you still have to explicitly assign to DoH).

Depending on how you distribute the DoH templates, the effort of enabling DoH on your clients may be as low as rolling out two policy settings or as high as distributing a custom script to configure local DNS to use your private DoH endpoints. Whatever you do, the client side of the DoH enablement MUST be automated!

Maintaining private DoH

I trust you heeded the advice at the end of the previous paragraph. In this case, all maintenance happens on the server side, which involves:

• Certificate lifecycle monitoring and maintenance, including deployment to new DNS servers.
• Configuration deployment and state monitoring. DoH is a prime example of a facility where Desired State Configuration makes a lot of sense.

This is not a lot of work, and 100% of it can also be automated (unless you decided to make your PKI very secure and require admin approval for every template).

How often will it break?

First and foremost, DoH will break in all scenarios where your classic DNS on port 53 would also break – server down, wrong network profile, routing blues, zone corruption, the list is endless.

Then, an overzealous firewall admin might wonder why port 443 (or whatever port you choose to run DoH on) is enabled towards Domain Controllers and block it. If you enforce DoH, name resolution will break. If you simply allow it, DNS resolution will silently fall back to port 53.

Then, you will forget to renew the certificates or to re-register them with DoH. Or, you have automated this, and your automation fails silently. Then DoH will fail, and the above failback consideration will apply.

DoH being a brand-new feature in Windows, there is always a possibility that a subsequent Patch Tuesday will break it.

How hard is it to troubleshoot?

The DNS part is fairly OK to troubleshoot, and you can apply all the skills that you learned in your Windows DNS admin career. However, if your troubleshooting vehicle of choice is text-based DNS debug logging, you may be disappointed at first – at the time of writing at least, the logging options surfaced in the UI and in Set-DnsServerDiagnostics are limited to TCP and UDP so you will not find any traces of DoH queries and replies in the log. You can resort to Analytical Logging in the Event Log for this, or you just add 0x00010000 to the value of HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\DNS\Parameters\LogLevel after configuring the desired options in the GUI or in PowerShell.

Troubleshooting DDR, on the other hand, is not easy. I may write a post on that in the future once I figure it out. DDR and DoH in Windows DNS Client are not new, and the complete lack of information on troubleshooting this certainly comes as a surprise.

Should I implement private DoH?

By all means, even if it doesn’t advance your security posture all that much. If you choose to do it, however, do it right from the very beginning! DoH, like DNSSEC, is a great checkbox to tick off, but it only makes your network more secure if it doesn’t open up new spoofing vectors after closing down some of the existing ones. Here’s a checklist of things you need to figure out:

1. Certificate issuance: If you rely on ADCS for your certificate needs, I suggest you use Tame My Certs and restrict your DoH server template to the desired FQDNs of your DoH endpoints and, more importantly, restrict any other server template from using those FQDNs! The DoH template can be set to require operator confirmation, because the job of adding or replacing the certificate is a manual one anyway. Or, if your DNS is hosted on domain controllers, you can set those to enroll to that template.
2. Revocation checking: If non-member machines are expected to participate in DoH, LDAP CDP is obviously a no-go. I recommend that you use OCSP (and yes, it’s OK to use it in your private infra) and use the OCSP-Must-Staple extension with the DoH template. ADCS does not offer this EKU by default, so that you’ll have to add the OID 1.3.6.1.5.5.7.1.24 manually. The need for revocation checking should also, in my opinion, discourage you from using certificates signed by public CAs with DoH – but you do you…
3. Certificate lifecycle: Every time the DoH certificate changes, you have to explicitly replace it (i.e. delete old + add new) in the WinHTTP binding configuration and restart the DNS Server service after the change. This is totally automatable, and I would encourage you to automate it across your DNS server fleet. Use tiered renewal schedules together with load balancing to avoid multiple endpoints failing at the same time.
4. Endpoint resolution and load balancing: Remember, the FQDN in the endpoint URI is not actually being resolved but just supplied in the SNI to ensure validity by checking against the SAN of the bound certificate. Therefore, if you want several servers to listen to the same endpoint, just use a Layer 3 load balancer with a single IP – or maintain multiple DoH templates in your clients‘ DNS configuration.
5. Roaming clients and automatic template selection: The best you can do at this time, in Windows, is a. enable the policy „Configure Discovery of Designated Resolvers (DDR) protocol“ and b. set the policy „Configure Encrypted Name Resolution“ to „Require Encryption | Allow DoH | Allow DoT“ for your clients. This way, on public networks Windows will reach out to the DNS servers it received from DHCP and try to get the DoH template using the special use domain name „_dns.resolver.arpa“ with the service binding record type SVCB. Since the current implementation of DNS in Windows Server does not allow for SVCB records, you cannot make use of DDR internally without resorting to tricks. If you’re not up for that, add your DoH-enabled DNS servers to the local configuration using Add-DnsClientDohServerAddress and hope for the best.

Happy DoHing!

Image by Gerd Altmann from Pixabay