Enable DNS-over-HTTPS (DoH) on Windows Server 2025 DNS Server

On a Windows 11 test client, install Wireshark, or use the built-in Pktmon tool if you prefer not to install third-party software. Start a capture on the network interface that talks to the DNS server.

Apply the display filter dns to isolate DNS traffic, or narrow it further to a specific server with dns && ip.addr == <dns-server-ip>. While the capture is running, generate a query from PowerShell with Resolve-DnsName -Name www.example.com -Type A.

In Wireshark, select the query packet and expand the Domain Name System section. The queried hostname appears in plain text. This is exactly the information DoH will hide once enabled.

Keep this capture or a screenshot of it for comparison against the encrypted capture taken later in this tutorial.

Run Get-HotFix -Id KB5094125 on the DNS server to confirm the June 9, 2026 cumulative update, or a later one, is installed. Without it, the EnableDoh parameter used later is not exposed by the DNS server cmdlets.

Confirm access to a trusted certification authority capable of issuing a Server Authentication certificate, such as an AD CS enterprise CA integrated with Active Directory.

Open the inbound port DoH will use, TCP 443 by default, with:

1New-NetFirewallRule `
2    -DisplayName "DNS over HTTPS" `
3    -Direction Inbound `
4    -Protocol TCP `
5    -LocalPort 443 `
6    -Action Allow

Verify the rule was created with Get-NetFirewallRule -DisplayName "DNS over HTTPS". Remember to also open this port on any hardware firewall positioned between clients and the server.

If TCP 443 is already used by another service on the server, choose a different port and adjust the certificate binding and URI template accordingly in later steps.

DoH relies on TLS, so the DNS server needs a certificate with the Server Authentication extended key usage (1.3.6.1.5.5.7.3.1) and a Subject Alternative Name matching the FQDN or IP address clients will use in their DoH URI template.

On the certification authority, open certtmpl.msc and duplicate the built-in Web Server template. On the General tab, give it a clear display name and a validity period appropriate for your policy. On Request Handling, keep Signature and Encryption, leave private key export disabled so the key stays on the server, and do not enable strong private key protection, since it is incompatible with DoH and will cause the certificate binding to fail.

On the Subject Name tab, choose to build the subject from Active Directory information, using Common Name format, and include the DNS name as a subject alternative name so the SAN is populated automatically. On Security, grant the group containing your DNS servers, such as Domain Controllers, read and enroll permissions.

Save the template, then publish it on the CA: in certsrv.msc, right-click Certificate Templates, select New, then Certificate Template to Issue, and choose the template you created.

Disabling private key export keeps the key non-portable, which is appropriate when each DNS server requests its own certificate directly, as covered in the next step.

On each DNS server, open the local computer certificate store with certlm.msc, right-click Personal > Certificates, choose All Tasks, then Request New Certificate, and select the template created earlier. Since the subject is built from Active Directory, no manual input is required.

Alternatively, run the following in an elevated PowerShell session on each server, using the template's internal name without spaces:

1Get-Certificate `
2    -Template "DNSoverHTTPS" `
3    -CertStoreLocation "Cert:\LocalMachine\My"

This places the certificate and its private key directly in Cert:\LocalMachine\My. Each server will use its own FQDN in its DoH URI template.

If multiple DNS servers need to share one name, for example behind a load balancer, a shared certificate with an exportable key would be required instead, at the cost of slightly weaker key protection.

Generate a GUID to identify the application owning the binding with $guid = New-Guid. Then list the candidate certificates on the server to identify the correct one, since a domain controller can have several certificates whose subject matches its hostname:

1Get-ChildItem Cert:\LocalMachine\My |
2    Where-Object { $_.Subject -match "<server-hostname>" } |
3    Format-List Subject, Thumbprint, NotAfter, EnhancedKeyUsageList

Copy the correct certificate's thumbprint and retrieve it into a variable, then confirm it resolves to exactly one certificate with $cert.Count, which should return 1:

1$cert = Get-Item -Path "Cert:\LocalMachine\My\<certificate-thumbprint>"

Bind the certificate to port 443 for all IP addresses on the server:

1netsh http add sslcert ipport=0.0.0.0:443 certhash=$($cert.Thumbprint) appid="{$guid}"

Confirm the binding with netsh http show sslcert and check that the certificate hash in the output matches the thumbprint you copied.

Replace 0.0.0.0 with a specific IP address if the server hosts multiple addresses and DoH should only respond on one of them. That address must match the name or IP in the certificate's SAN.

Enable DoH with the Set-DnsServerEncryptionProtocol cmdlet, specifying the URI template clients will use to reach the service. The template follows the form https://<host>:<port>/dns-query, where the host matches the certificate's SAN and the port matches the binding created in the previous step, per Microsoft's documentation on enabling DoH.

1Set-DnsServerEncryptionProtocol `
2    -EnableDoh $true `
3    -UriTemplate "https://srv-dns-01.contoso.local:443/dns-query"

Restart the DNS Server service to apply the configuration:

1Restart-Service -Name DNS

The server now answers DoH traffic on port 443 while continuing to listen for classic DNS on port 53, which allows a gradual client migration without any service interruption.

If the UriTemplate parameter is omitted, the server automatically generates a template based on its own FQDN with the /dns-query path.

On Windows 11, configure the DoH server address in PowerShell, declaring the server's IP address and a URI template identical to the server's:

1Add-DnsClientDohServerAddress `
2    -ServerAddress "192.168.10.201" `
3    -DohTemplate "https://srv-dns-01.contoso.local:443/dns-query" `
4    -AllowFallbackToUdp $false `
5    -AutoUpgrade $true

Setting -AllowFallbackToUdp $false forces encrypted resolution and prevents the client from falling back to plaintext DNS if DoH fails, so apply it carefully since a misconfiguration can break local DNS resolution.

The same setting is available from Settings under Network & internet > Ethernet > DNS server assignment > Edit, where you specify the DNS server's IP address, the DoH URI template, and whether to allow fallback to plaintext.

Re-run Resolve-DnsName -Name www.example.com -Type A and start a new Wireshark capture filtered with tcp.port == 443 && ip.addr == <dns-server-ip>. Queries no longer leave in plaintext on port 53. Instead, a TLS session establishes to the server on port 443, and the DNS query content is no longer readable.

Get-DnsClientDohServerAddress on the client lists which servers are currently configured for encrypted resolution, which is useful for auditing multiple machines.