DNS over HTTPS Goes GA on Windows Server 2025: What It Means for Your On-Premises DNS Strategy

Microsoft has declared DNS over HTTPS (DoH) generally available for the Windows DNS Server role on Windows Server 2025, covering client-to-server DNS traffic. The capability arrived in public preview months ago, but GA is the signal most enterprises actually wait for: it means production support, stability commitments, and deployment guidance solid enough to put in front of a change advisory board. The announcement from the Windows Core Networking team frames this as a Zero Trust upgrade to a piece of infrastructure most organizations have run unencrypted for decades.

What changed

Until now, if you wanted encrypted DNS resolution between clients and a resolver you controlled, your realistic options on-premises were limited. You either bolted a separate DoH-capable resolver in front of Windows DNS, pointed clients at a public encrypted resolver like Cloudflare or Google (and accepted that your internal query data left the building), or simply left DNS in cleartext and compensated elsewhere. None of those were clean.

With this release, the Windows DNS Server role itself terminates DoH. DNS queries and responses are encapsulated inside HTTPS and encrypted with TLS, following RFC 8484, the IETF standard for DNS over HTTPS. Clients authenticate the server using its TLS certificate, which closes off a class of spoofing and impersonation attacks that plain UDP-based DNS has always been vulnerable to. Critically, no separate resolver is required. The encryption happens inside the role you already run, and existing resolution behavior is unchanged.

Microsoft has been deliberate about backward compatibility. Traditional unencrypted DNS continues to work alongside DoH, so you can adopt this incrementally rather than flipping a switch across the estate. Server-to-server DNS communication still uses unencrypted DNS for now; encrypted upstream resolution between Windows DNS Server and the resolvers it forwards to is on the roadmap but not in this release. That distinction matters for anyone scoping a compliance project, because it means the encrypted path currently covers the client-to-resolver leg only.

Getting started requires Windows Server 2025 running the June 9, 2026 update or newer. The recommended flow is short: configure a trusted TLS certificate, enable DoH in the DNS Server service, then point supported clients at the secure endpoint. Microsoft's documentation on enabling DNS over HTTPS in DNS Server walks through the specifics.

How this compares to the alternatives

The strategic question for most teams isn't whether to encrypt DNS, it's where the resolver lives and who sees the queries. That's where the provider comparison gets interesting.

Public DoH resolvers (Cloudflare's 1.1.1.1, Google's 8.8.8.8, Quad9) are free, mature, and trivially easy to enable on clients. The trade-off is data residency and control. Your internal hostname lookups, your Active Directory queries, your private DNS zones all need split-horizon handling, and any query that escapes to the public resolver is visibility you've handed to a third party. For a regulated enterprise, that's frequently a non-starter for internal traffic.

Cloud-native private resolvers like Amazon Route 53 Resolver, Azure DNS Private Resolver, and Google Cloud DNS keep resolution inside your cloud tenancy and integrate cleanly with VPC and VNet networking. They're excellent if your workloads already live in that cloud. But they assume a cloud-centric topology. If your authoritative data and the bulk of your endpoints are on-premises, routing client DNS through a cloud resolver introduces latency, egress considerations, and a dependency on connectivity to the provider.

Windows DNS Server with DoH now occupies the slot those options left open: encrypted, authenticated resolution that stays entirely on-premises, inside infrastructure you already license and operate. You don't pay per-query, you don't move internal query data off-site, and you don't redesign your name resolution topology. For Active Directory-integrated environments, where Windows DNS is already the de facto resolver, this is the lowest-friction path to encrypted client-to-resolver DNS available.

The cost comparison is straightforward but easy to underweight. Public resolvers are free but carry governance cost. Cloud private resolvers bill per endpoint and per query, which is modest individually but compounds across a large fleet, and they presume you're already paying for the surrounding cloud networking. The Windows DNS approach has effectively zero incremental licensing cost if you're already running Server 2025, with the real expenditure being certificate lifecycle management and the operational work of staged client configuration.

Business impact and migration considerations

The most concrete driver here is compliance. Microsoft explicitly positions this release against U.S. federal guidance, including OMB M-22-09 and the NIST Secure DNS Deployment Guide, both of which push encrypted DNS between clients and resolvers as part of Zero Trust mandates. For federal agencies and the contractors who inherit their requirements, having a standards-based encrypted path inside Windows DNS Server removes a meaningful architectural obstacle. You can satisfy the client-to-resolver encryption requirement without standing up new resolver infrastructure or sending internal queries to an external service.

For migration planning, the incremental adoption model is the headline. Because unencrypted and encrypted DNS coexist, you can pilot DoH with a subset of clients, validate certificate handling and client behavior, and expand at your own pace. There's no forced cutover. The main operational additions to plan for are certificate management, which becomes a hard dependency the moment you enable DoH, and the realization that mature client-side configuration and monitoring matter as much as the server change.

The honest caveat is the upstream gap. This release encrypts the client-to-resolver hop, not the resolver-to-upstream hop. If your compliance objective is a fully encrypted resolution path end to end, you're covering one leg now and waiting on a future update for the other. For teams whose mandate specifically targets client-to-resolver traffic, that's sufficient today. For teams chasing fully encrypted forwarding, scope the project as phased and set expectations accordingly.

The broader pattern worth recognizing is that DNS encryption is converging across every tier of infrastructure. Browsers ship DoH on by default, operating systems support encrypted DNS natively, cloud providers offer private encrypted resolvers, and now the on-premises Windows resolver closes the loop. The organizations that benefit most are the AD-heavy enterprises that have run Windows DNS for years and previously had no native way to encrypt that traffic without leaving their own infrastructure. For them, this is less a new product to evaluate and more an upgrade to one already in production, and the migration cost is low enough that the only real question is sequencing, not whether to do it at all.