How to Configure Windows Server 2019 DNS Security

March 21, 2026
Tutorials
Comment off

Introduction to DNS Security on Windows Server 2019

DNS is foundational infrastructure — every name resolution request on your network passes through it. A misconfigured or compromised DNS server can redirect traffic, enable phishing attacks, or facilitate data exfiltration. Windows Server 2019 includes several built-in features to harden DNS, including DNSSEC, Response Rate Limiting (RRL), DNS Socket Pool, DNS Cache Locking, and detailed audit logging. This guide walks through each of these security layers in practical detail.

Prerequisites

You need a Windows Server 2019 system with the DNS Server role installed. Open all PowerShell commands in an elevated (Administrator) session. Confirm the DNS service is running before making changes:

Get-Service -Name DNS
Get-WindowsFeature -Name DNS

Enable DNS Socket Pool

The DNS Socket Pool randomises the source port used for outgoing DNS queries, making it significantly harder for attackers to perform cache poisoning via blind spoofing. By default the pool size is 2500 sockets; Microsoft recommends increasing this to the maximum of 10000 for high-security environments.

# Check current socket pool size
dnscmd /Info /SocketPoolSize

# Set to maximum (requires DNS service restart)
dnscmd /Config /SocketPoolSize 10000

# Restart DNS to apply
Restart-Service -Name DNS

After restarting, verify the change took effect by running dnscmd /Info /SocketPoolSize again. The socket pool is particularly important on servers that perform recursive resolution for internal clients.

Enable DNS Cache Locking

Cache Locking prevents DNS records cached from external responses from being overwritten during their TTL lifetime. Without cache locking, an attacker who can inject a response could overwrite a legitimate cached record mid-TTL. The value is expressed as a percentage of the TTL; setting it to 100 means a cached entry cannot be replaced for the full duration of its TTL.

# Check current cache lock value
dnscmd /Info /CacheLockingPercent

# Set cache locking to 100%
dnscmd /Config /CacheLockingPercent 100

Restart-Service -Name DNS

Configure DNS Response Rate Limiting (RRL)

RRL limits the rate at which the DNS server responds to queries from a single source IP address. This protects against DNS amplification attacks, where an attacker sends a flood of small queries using a spoofed source IP, causing the server to bombard the victim with large responses. Windows Server 2019 ships with RRL disabled by default.

# Enable RRL with default settings
Set-DnsServerResponseRateLimiting -Mode Enable

# View current RRL settings
Get-DnsServerResponseRateLimiting

# Customise thresholds (responses per second per source subnet)
Set-DnsServerResponseRateLimiting `
    -ResponsesPerSec 5 `
    -ErrorsPerSec 5 `
    -WindowInSec 5 `
    -LeakRate 3 `
    -TruncateRate 2 `
    -MaximumResponsesPerWindow 48 `
    -Mode Enable

The LeakRate parameter controls how many responses are allowed through even when the rate limit is exceeded — this prevents legitimate clients from being completely blocked. A value of 3 means one in every three rate-limited responses will still be sent. The TruncateRate sends a truncated UDP response instructing the client to retry over TCP, which most legitimate clients will do but attackers typically won’t.

Restrict Zone Transfers

Zone transfers (AXFR/IXFR) replicate the entire DNS zone database from a primary server to secondary servers. If unrestricted, any attacker on the network can enumerate every hostname and IP in your zone. Restrict zone transfers to authorised secondary DNS servers only.

# List zones
Get-DnsServerZone

# Restrict zone transfer for a specific zone to named servers only
Set-DnsServerPrimaryZone -Name "corp.example.com" `
    -SecureSecondaries TransferToSecureServers `
    -SecondaryServers "192.168.1.11","192.168.1.12"

# Verify
Get-DnsServerZone -Name "corp.example.com" | Select-Object ZoneName, SecureSecondaries, SecondaryServers

If you have no secondary DNS servers, set SecureSecondaries to NoTransfer to completely block zone transfers.

Restrict Recursive Queries

If your DNS server only serves internal clients and should not perform recursive resolution for external addresses, you can disable recursion entirely or restrict it to specific client subnets. Disabling unnecessary recursion reduces attack surface against cache poisoning and amplification.

# Disable recursion completely
Set-DnsServerRecursion -Enable $false

# Or enable recursion but restrict to internal subnets via DNS policy
Add-DnsServerClientSubnet -Name "InternalClients" -IPv4Subnet "192.168.0.0/16","10.0.0.0/8"

Add-DnsServerQueryResolutionPolicy `
    -Name "BlockExternalRecursion" `
    -Action DENY `
    -ClientSubnet "NE,InternalClients" `
    -PassThru

Block Malicious Domains with DNS Policies

You can use DNS Response Policies (DNS RPZ-like functionality) to block resolution of known malicious domains. When a client queries a blocked domain, the server returns NXDOMAIN or a custom sinkhole address, preventing the client from reaching the malicious destination.

# Create a policy zone to hold block list entries
Add-DnsServerZone -Name "BlockList" -ZoneFile "blocklist.dns" -DynamicUpdate None

# Add a blocked domain record (returns 0.0.0.0)
Add-DnsServerResourceRecord -ZoneName "BlockList" `
    -A -Name "malware.example.com" -IPv4Address "0.0.0.0"

# Alternatively use PowerShell to manage a Response Policy Zone
# First, check if RPZ is supported in your build
Get-Command -Module DnsServer | Where-Object Name -like "*Policy*"

Audit DNS Server Events

Windows Server 2019 DNS Server generates events in the Windows Event Log under Applications and Services Logs > Microsoft > Windows > DNSServer. Enable diagnostic logging to capture query details for security investigation.

# Enable all DNS debug logging categories
Set-DnsServerDiagnostics -All $true

# Confirm
Get-DnsServerDiagnostics

# Query DNS event log
Get-WinEvent -LogName "Microsoft-Windows-DNS-Server/Audit" -MaxEvents 50 |
    Select-Object TimeCreated, Id, Message | Format-List

Firewall Rules for DNS

Restrict DNS traffic to only the expected sources using Windows Firewall. DNS uses UDP and TCP port 53. Zone transfers use TCP 53. On servers that should only receive DNS queries from internal clients, block DNS from external ranges.

# Allow DNS queries only from internal subnet
New-NetFirewallRule -DisplayName "Allow DNS from Internal" `
    -Direction Inbound -Protocol UDP -LocalPort 53 `
    -RemoteAddress "192.168.0.0/16","10.0.0.0/8" `
    -Action Allow

New-NetFirewallRule -DisplayName "Allow DNS TCP from Internal" `
    -Direction Inbound -Protocol TCP -LocalPort 53 `
    -RemoteAddress "192.168.0.0/16","10.0.0.0/8" `
    -Action Allow

# Block DNS from all other sources
New-NetFirewallRule -DisplayName "Block DNS External" `
    -Direction Inbound -Protocol UDP -LocalPort 53 `
    -Action Block

Verify and Monitor Security Posture

After applying all security settings, run a verification pass to confirm each control is active:

# Summary check script
$dns = Get-DnsServerSetting
Write-Host "RRL:" (Get-DnsServerResponseRateLimiting).Mode
Write-Host "Cache Lock:" (dnscmd /Info /CacheLockingPercent)
Write-Host "Socket Pool:" (dnscmd /Info /SocketPoolSize)
Write-Host "Recursion:" (Get-DnsServerRecursion).Enable
Get-DnsServerZone | Select-Object ZoneName, SecureSecondaries | Format-Table

Schedule this script to run weekly and alert on any deviation. Consider integrating DNS logs with a SIEM such as Microsoft Sentinel or Elastic SIEM for ongoing threat detection. DNS anomalies — sudden spikes in NXDOMAIN responses, unusually long domain names, or high volumes of TXT record queries — are common indicators of malware or data exfiltration activity.

Summary

Securing Windows Server 2019 DNS requires a layered approach: randomise source ports with Socket Pool, prevent cache poisoning with Cache Locking, mitigate amplification with RRL, restrict zone transfers to authorised secondaries, limit recursion to internal clients, block malicious domains with policy zones, and monitor all activity through audit logging and firewall rules. Together these controls significantly reduce the DNS attack surface without impacting legitimate resolution performance.