DNS Security I: DNSSEC in Windows Server

Part 6 – DNS Security I: DNSSEC in Windows Server
Part 6 – Lab

DNS Security I: DNSSEC in Windows Server

Digitally Sign Your Zones – The Gold Standard for DNS Integrity and Authenticity

1. Objective – Securing DNS with DNSSEC

Traditional DNS has a critical vulnerability: it has no built‑in security. Responses can be spoofed, cached poisoned, and queries intercepted. DNSSEC (Domain Name System Security Extensions) fixes this by adding cryptographic signatures to DNS data.

In this lab, you’ll learn:

  • What DNSSEC is and how the chain of trust works
  • The difference between Zone Signing Keys (ZSK) and Key Signing Keys (KSK)
  • How to sign a zone on Windows Server 2016/2019/2022
  • How to configure a trust anchor for validation
  • How to verify DNSSEC with PowerShell and external tools
  • How to roll over DNSSEC keys
📌 Prerequisite: A working Windows DNS server with an AD‑integrated zone (Parts 1–2). You’ll need DNS Admin and Domain Admin rights.

2. What is DNSSEC?

DNSSEC adds origin authentication and data integrity to DNS. It ensures that:

  • The response comes from the authoritative DNS server (not a spoofed source).
  • The response hasn’t been modified in transit (integrity).
  • If a record doesn’t exist, the “non‑existence” is also authenticated (NSEC/NSEC3).

2.1 The Chain of Trust

Root KSK .lab TLD KSK corp.lab ZSK Signed Records DS DS RRSIG Trust Anchor → DS → DNSKEY → RRSIG → Verified Record

The DNSSEC Chain of Trust – from Root to Record

Root KSK

The root Key Signing Key is hard‑coded into resolvers. It’s the ultimate trust anchor.

DS Record

Delegation Signer record – links a child zone to its parent’s key.

DNSKEY

Public keys used to verify signatures. ZSK signs records; KSK signs ZSK.

RRSIG

Resource Record Signature – the digital signature for a set of records.

3. ZSK vs. KSK – Understanding the Keys

3.1 Zone Signing Key (ZSK)

  • Used to sign individual records (A, AAAA, MX, etc.) in the zone.
  • Generates RRSIG records for each record set.
  • Can be rolled over frequently (e.g., every 30 days) without affecting the parent zone.
  • Smaller key size (1024–2048 bits) for performance.

3.2 Key Signing Key (KSK)

  • Used to sign the ZSK (creates a DNSKEY record for the ZSK).
  • Generates the DS record that is published in the parent zone.
  • Rolled over less frequently (e.g., every 1‑5 years).
  • Larger key size (2048–4096 bits) for stronger security.

3.3 Lab – Generate Keys

# Create a folder for DNSSEC keys
New-Item -ItemType Directory -Path "C:\DNSSEC-Keys"

# Generate a ZSK (Zone Signing Key)
Add-DnsServerZoneSigningKey -ZoneName "corp.lab" -KeyName "corp.lab-ZSK" -Type ZSK -CryptoAlgorithm "RSA" -KeyLength 2048

# Generate a KSK (Key Signing Key)
Add-DnsServerZoneSigningKey -ZoneName "corp.lab" -KeyName "corp.lab-KSK" -Type KSK -CryptoAlgorithm "RSA" -KeyLength 4096
PowerShell – Generating DNSSEC keys
Generate DNSSEC keys
🔍 Key Storage: Keys are stored in AD for AD‑integrated zones. For file‑based zones, they’re stored in the %windir%\system32\dns folder. Always back up your private keys!

4. Lab – Sign the Zone

4.1 Enable DNSSEC on the Zone

# Enable DNSSEC signing on the zone
Set-DnsServerZone -Name "corp.lab" -DnsSecEnable $true

4.2 Sign the Zone

# Sign the zone using the generated keys
Sign-DnsServerZone -ZoneName "corp.lab" -SigningKey "corp.lab-ZSK","corp.lab-KSK"

4.3 Verify Zone Signing

# List signing keys for the zone
Get-DnsServerZoneSigningKey -ZoneName "corp.lab"

# Check signing status
Get-DnsServerZone -Name "corp.lab" | Select-Object Name, DnsSecEnable, DnsSecSigned
DNS Manager – Signed zone with DNSSEC records
Signed zone

After signing, your zone will contain new record types:

  • DNSKEY – Contains the public keys (ZSK and KSK).
  • RRSIG – Signatures for each record set.
  • NSEC – Authenticated denial of existence (or NSEC3 if configured).
  • DS – Delegation Signer (for parent zone).

5. Lab – Publish the DS Record to the Parent Zone

To complete the chain of trust, the parent zone must contain a DS (Delegation Signer) record for your zone. This tells resolvers to trust your zone.

5.1 Export the DS Record

# Export the DS record for the parent zone
Get-DnsServerZoneDelegation -ZoneName "corp.lab" -Name "." | Select-Object -ExpandProperty DSRecord

5.2 Add DS Record to Parent (PowerShell)

# Assuming the parent zone is also on this server (for lab)
# In production, you'd provide this to your domain registrar
$dsRecord = Get-DnsServerZoneDelegation -ZoneName "corp.lab" -Name "." | Select-Object -ExpandProperty DSRecord
Add-DnsServerResourceRecordDS -ZoneName "corp.lab" -Name "." -DSRecord $dsRecord
🌐 Production Note: For a real domain, you’d submit the DS record to your domain registrar. They’ll publish it in the TLD zone (e.g., .com, .lab). For internal domains, you’d add it to the parent DNS zone if you have one.

6. Lab – Configure a Trust Anchor for Validation

For a resolver to validate DNSSEC, it needs a trust anchor – a trusted DNSKEY for the root or a specific zone.

6.1 Get the KSK DNSKEY

# Get the KSK public key (DNSKEY record)
$ksk = Get-DnsServerResourceRecord -ZoneName "corp.lab" -RRType DNSKEY | Where-Object { $_.RecordData.KeyType -eq "ZoneSigningKey" }
$ksk.PrettyFormatString

6.2 Add Trust Anchor to a Client/Resolver

# On a Windows client/resolver, add the trust anchor
Add-DnsServerTrustAnchor -Name "corp.lab" -PublicKey $ksk.RecordData

6.3 Test Validation

# Test DNSSEC validation (from the client)
Resolve-DnsName -Name www.corp.lab -DnsSec
Resolve-DnsName – DNSSEC validation successful
DNSSEC validation
⚠️ Important: Trust anchors must be configured on each validating resolver (clients, DNS servers, WAP proxies). In AD environments, you can use Group Policy to deploy trust anchors.

7. Lab – Key Rollover (ZSK Rollover)

DNSSEC keys must be rolled over periodically. ZSKs are rolled more frequently (e.g., every 30 days) to limit the impact of a compromised key.

7.1 Generate New ZSK

# Generate a new ZSK (with a new name)
Add-DnsServerZoneSigningKey -ZoneName "corp.lab" -KeyName "corp.lab-ZSK-v2" -Type ZSK -CryptoAlgorithm "RSA" -KeyLength 2048

7.2 Perform the Rollover

# Initiate the rollover (this keeps both keys active during the transition)
Invoke-DnsServerZoneSigningKeyRollover -ZoneName "corp.lab" -KeyName "corp.lab-ZSK"

7.3 Complete the Rollover

# After the old key's signatures have expired (default: 7 days), remove the old key
Remove-DnsServerZoneSigningKey -ZoneName "corp.lab" -KeyName "corp.lab-ZSK" -Force
💡 Pro Tip: Always use the double‑signing rollover method. Both old and new keys sign the zone during the transition, ensuring no downtime. After the TTL + signature validity period, remove the old key.

8. Lab – Configure NSEC3 for Zone Walking Prevention

NSEC3 (Next Secure 3) prevents zone walking – an attacker enumerating all records in a signed zone by following NSEC records.

8.1 Enable NSEC3

# Configure NSEC3 with a salt (hash) and iterations
Set-DnsServerZone -Name "corp.lab" -DnsSecNSEC3Salt "ABCDEF123456" -DnsSecNSEC3Iterations 10 -DnsSecNSEC3OptOut $true

8.2 Verify NSEC3

# Check NSEC3 records in the zone
Get-DnsServerResourceRecord -ZoneName "corp.lab" -RRType NSEC3 | Select-Object RecordName, RecordData
DNS Manager – NSEC3 records in signed zone
NSEC3 records
🔍 NSEC vs. NSEC3: NSEC returns the “next” domain name, allowing zone walking. NSEC3 hashes the domain names, making enumeration much harder. Use NSEC3 for public zones.

9. Lab – Verify DNSSEC with External Tools

9.1 Using DNSViz (Online)

Go to dnsviz.net and enter your domain. It will show the entire DNSSEC chain of trust with visual diagrams.

DNSViz – Visual DNSSEC validation
DNSViz

9.2 Using dig (Linux/Windows with BIND tools)

# Query with DNSSEC flags
dig +dnssec www.corp.lab

# Show the chain of trust
dig +dnssec +sigchase www.corp.lab

9.3 Using Verisign DNSSEC Analyzer

Visit dnssec-analyzer.verisignlabs.com and enter your domain.

10. Troubleshooting DNSSEC Issues

10.1 Common Issues

Zone Signing Fails

  • Symptom: Sign-DnsServerZone returns an error.
  • Fix: Ensure the zone has at least one ZSK and KSK. Check DNS event logs for detailed errors.

Validation Fails (SERVFAIL)

  • Symptom: Resolve-DnsName -DnsSec returns SERVFAIL.
  • Fix: Check that the trust anchor is correctly configured. Verify the DS record matches the KSK’s key fingerprint.

NSEC3 Salt Mismatch

  • Symptom: Validation fails with NSEC3 errors.
  • Fix: Ensure the salt and iterations match across all authoritative servers.

10.2 Diagnostic Commands

# Check signing status
Get-DnsServerZone -Name "corp.lab" | Select-Object Name, DnsSecEnable, DnsSecSigned

# Check DNSKEY records
Get-DnsServerResourceRecord -ZoneName "corp.lab" -RRType DNSKEY

# Check RRSIG records
Get-DnsServerResourceRecord -ZoneName "corp.lab" -RRType RRSIG

# Test validation from the server
Resolve-DnsName -Name www.corp.lab -DnsSec -Server 10.10.10.96

11. Emergency Rollback

11.1 Disable DNSSEC

# Disable DNSSEC signing on the zone
Set-DnsServerZone -Name "corp.lab" -DnsSecEnable $false

11.2 Remove DNSSEC Records

# Remove all DNSSEC-related records
Get-DnsServerResourceRecord -ZoneName "corp.lab" | Where-Object { $_.RecordType -in "DNSKEY","RRSIG","NSEC","NSEC3","DS" } | Remove-DnsServerResourceRecord -Force -ZoneName "corp.lab"

11.3 Remove Trust Anchors

# Remove the trust anchor
Remove-DnsServerTrustAnchor -Name "corp.lab" -Force
⚠️ Caution: Removing DNSSEC will break validation for clients that have trust anchors configured. Ensure you remove trust anchors from all resolvers before disabling DNSSEC.

12. Key Takeaways

  • DNSSEC adds integrity and authentication to DNS – preventing spoofing and cache poisoning.
  • ZSK signs records; KSK signs the ZSK and creates the DS record for the parent zone.
  • The chain of trust goes from Root → TLD → Parent Zone → Your Zone.
  • NSEC3 prevents zone walking and is recommended for public zones.
  • Key rollover is essential for long‑term security – ZSKs should be rolled frequently.
  • Trust anchors must be deployed to all validating resolvers.
  • Tools like DNSViz and dig help verify DNSSEC configuration.

🛡️ Next Steps – DNS Security II: Policies, Analytics & Encryption

Your zone is now cryptographically secure. Next, we’ll explore additional security layers: DNS policies, logging, threat intelligence, and encrypted DNS.

👉 Part 7 – DNS Security II: Policies, Analytics & Encryption
We’ll implement DNS response rate limiting, query filtering, set up analytics with SIEM, and explore DoH/DoT for encrypted DNS.

Start Part 7 Now

DNS Mastery Series – Part 6: DNSSEC in Windows Server

All content for educational purposes.

Leave a Reply

Your email address will not be published. Required fields are marked *