How to Configure DNSSEC on Windows Server 2012 R2
DNSSEC (Domain Name System Security Extensions) is a suite of Internet Engineering Task Force (IETF) specifications for securing DNS data using cryptographic signatures. Without DNSSEC, DNS responses can be forged, allowing attackers to redirect users to malicious servers through cache poisoning attacks. DNSSEC adds digital signatures to DNS records, allowing resolvers to verify that the data originated from the authoritative zone and has not been tampered with in transit. Windows Server 2012 R2 DNS Server fully supports DNSSEC for both hosting signed zones and for DNSSEC validation on recursive resolvers. This guide covers signing a DNS zone, configuring trust anchors, and enforcing DNSSEC validation.
Prerequisites
The DNS Server role must be installed on Windows Server 2012 R2. Administrative rights on the DNS server are required. For Active Directory-integrated zones, the zone must be stored in AD DS. DNSSEC for internally-hosted zones uses the DNS Server’s built-in key generation — no external CA is required. However, for public-facing zones, you must also add your DNSSEC key to your domain registrar’s DNSKEY records at the parent zone. This guide focuses on internal zone signing for lab and enterprise environments.
Installing and Verifying the DNS Server Role
# Install DNS Server if not already installed
Install-WindowsFeature DNS -IncludeManagementTools
# Verify DNS service status
Get-Service -Name DNS | Select-Object Status, StartType
# Check existing DNS zones
Get-DnsServerZone | Select-Object ZoneName, ZoneType, IsSigned | Format-Table
Understanding DNSSEC Components
DNSSEC involves several cryptographic record types that must be understood before signing:
- DNSKEY — Public key records published in the zone for signature verification
- RRSIG — Resource Record Signature, a digital signature for each set of DNS records
- NSEC/NSEC3 — Next Secure Record, provides authenticated denial of existence for non-existent records
- DS — Delegation Signer, links a child zone to its parent zone’s trust chain
- KSK — Key Signing Key, signs the DNSKEY record set
- ZSK — Zone Signing Key, signs all other record sets in the zone
Signing a DNS Zone Using the DNS Manager
The DNS Manager provides a wizard for signing zones. Right-click the zone in DNS Manager and select “DNSSEC > Sign the Zone.” The PowerShell approach is more precise for production:
# Sign a DNS zone using default settings (NSEC3, automatic key management)
$ZoneName = "contoso.com"
# Sign the zone with automatic key management
# This generates KSK and ZSK automatically
Invoke-DnsServerZoneSign -ZoneName $ZoneName `
-SignWithDefault $true
# Verify the zone is now signed
Get-DnsServerZone -Name $ZoneName | Select-Object ZoneName, IsSigned
For custom signing configuration with explicit key parameters:
# Create KSK (Key Signing Key) - 2048-bit RSA, used to sign the DNSKEY RRset
$KSKParameters = New-DnsServerSigningScope `
-ZoneName $ZoneName `
-SigningKeyType KSK
# Add Zone Signing Key
$ZSKParameters = New-DnsServerSigningScope `
-ZoneName $ZoneName `
-SigningKeyType ZSK
# Sign the zone with explicit parameters
$SigningParameters = @{
ZoneName = $ZoneName
KeyType = @("KSK", "ZSK")
CryptoAlgorithm = "RsaSha256"
KeyLength = 2048
DnsKeySignatureValidityPeriod = New-TimeSpan -Days 30
DSSignatureValidityPeriod = New-TimeSpan -Days 30
ZoneSignatureValidityPeriod = New-TimeSpan -Days 14
NSec3OptOut = $false
NSec3Iterations = 10
NSec3RandomSaltLength = 8
}
Invoke-DnsServerZoneSign @SigningParameters
Viewing DNSSEC Records After Signing
After signing, the zone will contain DNSKEY, RRSIG, and NSEC3 records:
# View DNSKEY records (public keys)
Get-DnsServerResourceRecord -ZoneName $ZoneName -RRType DNSKEY |
Select-Object HostName, RecordType, RecordData | Format-List
# View signing keys and their properties
Get-DnsServerZoneSigningMetadata -ZoneName $ZoneName
# View RRSIG records (signatures) - will be very numerous in a signed zone
Get-DnsServerResourceRecord -ZoneName $ZoneName -RRType RRSIG -Node "@" |
Format-List
Configuring DNSSEC Key Rollover
DNSSEC keys must be periodically rolled over (replaced) to maintain security. Windows Server 2012 R2 supports automatic key rollover:
# Configure automatic ZSK rollover (recommended every 30-90 days)
Set-DnsServerDnsSecZoneSetting -ZoneName $ZoneName `
-DnsSecEnabled $true `
-NSec3HashAlgorithm Sha1 `
-NSec3Iterations 10 `
-NSec3RandomSaltLength 8
# Check current key rollover settings
Get-DnsServerZoneSigningMetadata -ZoneName $ZoneName |
Select-Object KeyType, Algorithm, KeyLength, NextKeyGenerationTime | Format-Table
# Initiate a manual key rollover for the ZSK
# In DNS Manager: Zone > DNSSEC Properties > Key Management > Rollover
Configuring Trust Anchors for DNSSEC Validation
Trust anchors tell the DNS resolver which public keys to trust as the root of a signed zone’s chain of trust. For resolving clients to validate DNSSEC, they must have the correct trust anchor for your signed zone:
# Export the trust anchor from the signing DNS server
# The trust anchor is the DNSKEY record for the zone's KSK
$TrustAnchor = Get-DnsServerTrustAnchor -Name $ZoneName
$TrustAnchor | Format-List
# Export trust anchors to a file for distribution
Export-DnsServerTrustAnchor -ZoneName $ZoneName -Path "C:DNSSECTrustAnchor.xml"
# Import trust anchor on a resolver DNS server (for child zones or split DNS)
Import-DnsServerTrustAnchor -ZoneName $ZoneName `
-Path "C:DNSSECTrustAnchor.xml"
Configuring DNSSEC Validation on DNS Resolvers
DNS resolvers (the DNS servers that clients query) must be configured to validate DNSSEC signatures. Configure validation and enforce NRPT rules for clients:
# Enable DNSSEC validation on the DNS resolver
Set-DnsServerRecursion -Enable $true
Set-DnsServerGlobalQueryBlockList -Enable $false
# Add a Name Resolution Policy Table (NRPT) rule via Group Policy to enforce DNSSEC
# for the contoso.com namespace on client machines
# GPO Path: Computer Configuration > Windows Settings > Name Resolution Policy
# Add rule for suffix "contoso.com" > Enable DNSSEC validation
# Via PowerShell on the DNS client (Windows 8.1/Server 2012 R2):
Add-DnsClientNrptRule `
-Namespace ".contoso.com" `
-EnableDnssec $true `
-DnsSecValidationRequired $true `
-NameServers "192.168.1.10"
View existing NRPT rules on a client:
# View NRPT rules
Get-DnsClientNrptRule | Select-Object Namespace, EnableDnssec, DnsSecValidationRequired | Format-Table
# View NRPT rules applied via Group Policy (effective rules)
Get-DnsClientNrptGlobal
Testing DNSSEC Validation
Test that DNSSEC signatures are being created and validated correctly:
# Test DNSSEC using Resolve-DnsName
Resolve-DnsName -Name "contoso.com" -DnssecOk -Server 192.168.1.10
# Check if the AD bit (Authenticated Data) is set in the response
# Output should include: AD bit set, RRSIG records present
# Test a specific record type
Resolve-DnsName -Name "www.contoso.com" -Type A -DnssecOk -Server 192.168.1.10 |
Format-List
# Use nslookup to check DNSSEC records
nslookup -type=DNSKEY contoso.com 192.168.1.10
# Verify RRSIG records exist
nslookup -type=RRSIG contoso.com 192.168.1.10
Monitoring DNSSEC
# Monitor DNSSEC events in the DNS Server event log
Get-WinEvent -LogName "DNS Server" |
Where-Object {$_.Id -in @(5001, 5002, 5003, 5010)} |
Select-Object TimeCreated, Id, Message | Format-List
# Check DNS Server operational log for DNSSEC-related events
Get-WinEvent -LogName "Microsoft-Windows-DNSServer/Analytical" `
-MaxEvents 20 -ErrorAction SilentlyContinue |
Select-Object TimeCreated, Id, Message | Format-List
# View zone signing status
Get-DnsServerZone -Name $ZoneName |
Select-Object ZoneName, IsSigned, ZoneType | Format-Table
Summary
DNSSEC on Windows Server 2012 R2 protects DNS zones from cache poisoning and data tampering through cryptographic signing. The implementation requires: signing the authoritative zone using RSA-SHA256 keys, configuring automatic key rollover for KSK and ZSK, distributing trust anchors to all DNS resolvers, and configuring NRPT rules on clients to enforce DNSSEC validation. Monitor key expiry and rollover events in the DNS Server event log to prevent validation failures caused by expired signatures. For public internet zones, publish the DS record at your registrar to chain trust from the root zone.