How to Configure DNS Zones and Records on Windows Server 2025
Once the DNS Server role is installed on Windows Server 2025, the next critical task is structuring your DNS namespace through zones and populating those zones with resource records. DNS zones are authoritative containers for a portion of the DNS namespace, and resource records are the individual entries that answer name resolution queries. Getting zone architecture and record configuration right from the start prevents difficult-to-diagnose problems with Active Directory replication, email delivery, and application connectivity. This guide covers zone types, creating the most important resource record types via PowerShell, configuring zone transfers for redundancy, signing zones with DNSSEC, and testing your configuration with Resolve-DnsName.
Prerequisites
- Windows Server 2025 with the DNS Server role installed (see the DNS installation guide)
- At least one primary zone created
- PowerShell running as Administrator
- For DNSSEC: the zone must be a primary zone (AD-integrated or file-backed)
- For secondary zones: a second DNS server reachable over the network
Step 1: Understanding DNS Zone Types
Windows Server 2025 supports four zone types, each suited to different scenarios. Choosing the right zone type is a design decision that affects data storage, replication, update behavior, and fault tolerance.
- Primary zone: The read-write master copy of zone data. Hosted on a single server (or multiple servers if AD-integrated). All record changes are made here.
- Secondary zone: A read-only copy of zone data transferred from the primary. Provides redundancy and distributes query load. Data is transferred via zone transfers (AXFR/IXFR).
- Stub zone: Contains only the NS records and SOA for another zone. Used to keep track of authoritative name servers for a delegated zone without hosting all records.
- AD-integrated zone: A primary zone whose data is stored in Active Directory, replicated automatically to all DCs with the DNS role, and protected by AD security. This is the recommended type for internal corporate domains.
# List all zones and their types
Get-DnsServerZone | Select-Object ZoneName, ZoneType, IsADIntegrated, ReplicationScope
# Create a secondary zone pointing to the primary server
Add-DnsServerSecondaryZone `
-Name "corp.example.com" `
-ZoneFile "corp.example.com.dns" `
-MasterServers "192.168.10.10" `
-PassThru
# Create a stub zone
Add-DnsServerStubZone `
-Name "branch.corp.example.com" `
-ZoneFile "branch.corp.example.com.dns" `
-MasterServers "10.20.1.10" `
-PassThru
Step 2: Creating A and AAAA Records
Address records are the most common record type, mapping hostnames to IP addresses. A records map to IPv4 addresses; AAAA records map to IPv6 addresses. Use Add-DnsServerResourceRecordA and Add-DnsServerResourceRecordAAAA respectively.
# Add an A record for a web server
Add-DnsServerResourceRecordA `
-Name "webserver01" `
-ZoneName "corp.example.com" `
-IPv4Address "192.168.10.50" `
-TimeToLive "01:00:00" `
-PassThru
# Add multiple A records at once (DNS round-robin load balancing)
@("192.168.10.51", "192.168.10.52", "192.168.10.53") | ForEach-Object {
Add-DnsServerResourceRecordA `
-Name "webapp" `
-ZoneName "corp.example.com" `
-IPv4Address $_ `
-TimeToLive "00:05:00" `
-PassThru
}
# Add an AAAA record for IPv6
Add-DnsServerResourceRecordAAAA `
-Name "webserver01" `
-ZoneName "corp.example.com" `
-IPv6Address "2001:db8:10::50" `
-TimeToLive "01:00:00" `
-PassThru
# List all A records in a zone
Get-DnsServerResourceRecord -ZoneName "corp.example.com" -RRType "A" |
Select-Object HostName, TimeToLive, @{N="IP";E={$_.RecordData.IPv4Address}}
Step 3: Creating CNAME Records
Canonical Name (CNAME) records create aliases that point to another hostname rather than directly to an IP address. They are commonly used to create friendly names for servers (mail pointing to exchange01) and to allow one server to be referenced by multiple names without duplicating A records.
# Create a CNAME alias
Add-DnsServerResourceRecordCName `
-Name "mail" `
-ZoneName "corp.example.com" `
-HostNameAlias "exchange01.corp.example.com." `
-TimeToLive "01:00:00" `
-PassThru
# Create multiple CNAMEs pointing to the same target
$aliases = @("intranet", "sharepoint", "collab")
foreach ($alias in $aliases) {
Add-DnsServerResourceRecordCName `
-Name $alias `
-ZoneName "corp.example.com" `
-HostNameAlias "spserver01.corp.example.com." `
-PassThru
}
# List all CNAME records
Get-DnsServerResourceRecord -ZoneName "corp.example.com" -RRType "CNAME" |
Select-Object HostName, @{N="Target";E={$_.RecordData.HostNameAlias}}
Step 4: Creating MX Records for Email
Mail Exchanger (MX) records are required for email delivery. They specify the mail servers responsible for accepting email for the domain. Multiple MX records with different preference values provide fallback delivery — lower preference values have higher priority.
# Add a primary MX record (lower preference = higher priority)
Add-DnsServerResourceRecordMX `
-Name "@" `
-ZoneName "corp.example.com" `
-MailExchange "mail01.corp.example.com." `
-Preference 10 `
-TimeToLive "01:00:00" `
-PassThru
# Add a backup MX record
Add-DnsServerResourceRecordMX `
-Name "@" `
-ZoneName "corp.example.com" `
-MailExchange "mail02.corp.example.com." `
-Preference 20 `
-TimeToLive "01:00:00" `
-PassThru
# Verify MX records
Get-DnsServerResourceRecord -ZoneName "corp.example.com" -RRType "MX" |
Select-Object HostName, @{N="Priority";E={$_.RecordData.Preference}},
@{N="MailServer";E={$_.RecordData.MailExchange}}
Step 5: Creating TXT Records (SPF and DMARC)
TXT records store arbitrary text strings and are used for many purposes including domain ownership verification, email authentication (SPF, DKIM, DMARC), and service discovery. SPF and DMARC records are essential for modern email deliverability and protecting your domain from spoofing.
# Add an SPF record to authorize specific mail servers
Add-DnsServerResourceRecord `
-ZoneName "corp.example.com" `
-Txt `
-Name "@" `
-DescriptiveText "v=spf1 ip4:192.168.10.0/24 include:spf.protection.outlook.com -all" `
-TimeToLive "01:00:00" `
-PassThru
# Add a DMARC record
Add-DnsServerResourceRecord `
-ZoneName "corp.example.com" `
-Txt `
-Name "_dmarc" `
-DescriptiveText "v=DMARC1; p=quarantine; rua=mailto:[email protected]; pct=100" `
-TimeToLive "01:00:00" `
-PassThru
# Add a DKIM TXT record (replace with your actual DKIM public key)
Add-DnsServerResourceRecord `
-ZoneName "corp.example.com" `
-Txt `
-Name "selector1._domainkey" `
-DescriptiveText "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ..." `
-TimeToLive "01:00:00" `
-PassThru
# List all TXT records
Get-DnsServerResourceRecord -ZoneName "corp.example.com" -RRType "TXT" |
Select-Object HostName, @{N="Value";E={$_.RecordData.DescriptiveText}}
Step 6: Creating SRV Records
Service (SRV) records advertise the location of services within a domain. Active Directory relies heavily on SRV records — clients discover domain controllers, Kerberos servers, and LDAP endpoints through SRV records automatically registered by dcpromo. You may also need to create SRV records manually for applications such as SIP/VoIP, Minecraft, or custom services.
# Add an SRV record for a custom HTTPS service
Add-DnsServerResourceRecordSrv `
-Name "_https._tcp" `
-ZoneName "corp.example.com" `
-DomainName "webserver01.corp.example.com." `
-Priority 10 `
-Weight 20 `
-Port 443 `
-TimeToLive "01:00:00" `
-PassThru
# Add SRV record for a SIP proxy
Add-DnsServerResourceRecordSrv `
-Name "_sip._tls" `
-ZoneName "corp.example.com" `
-DomainName "sipproxy.corp.example.com." `
-Priority 10 `
-Weight 10 `
-Port 5061 `
-PassThru
# View all SRV records
Get-DnsServerResourceRecord -ZoneName "corp.example.com" -RRType "SRV" |
Select-Object HostName, @{N="Target";E={$_.RecordData.DomainName}},
@{N="Port";E={$_.RecordData.Port}}, @{N="Priority";E={$_.RecordData.Priority}}
Step 7: Testing Resolution with Resolve-DnsName
The Resolve-DnsName cmdlet is the PowerShell equivalent of nslookup and is the preferred tool for testing DNS resolution on Windows Server 2025. It supports querying specific record types, specifying alternative DNS servers, and testing both forward and reverse lookups.
# Test A record resolution
Resolve-DnsName -Name "webserver01.corp.example.com" -Type A -Server "192.168.10.10"
# Test MX records
Resolve-DnsName -Name "corp.example.com" -Type MX -Server "192.168.10.10"
# Test TXT/SPF records
Resolve-DnsName -Name "corp.example.com" -Type TXT
# Perform a reverse lookup
Resolve-DnsName -Name "192.168.10.50" -Type PTR
# Test SRV record for AD Kerberos
Resolve-DnsName -Name "_kerberos._tcp.corp.example.com" -Type SRV
# Trace full resolution path (useful for debugging delegation chains)
Resolve-DnsName -Name "corp.example.com" -Type NS -DnsOnly
Step 8: Configure Zone Transfers
Zone transfers replicate zone data from a primary DNS server to secondary servers. Without proper zone transfer configuration, secondary servers cannot receive updates. You can configure which servers are allowed to initiate transfers and enable NOTIFY so the primary proactively alerts secondaries when data changes.
# Restrict zone transfers to specific secondary servers only
Set-DnsServerPrimaryZone `
-Name "corp.example.com" `
-SecureSecondaries "TransferToZoneNameServer" `
-PassThru
# Allow zone transfer to a specific server IP
Set-DnsServerPrimaryZone `
-Name "corp.example.com" `
-SecureSecondaries "TransferToSecureServers" `
-SecondaryServers "192.168.10.11", "192.168.10.12" `
-PassThru
# Enable NOTIFY so primary alerts secondaries of changes immediately
Set-DnsServerPrimaryZone `
-Name "corp.example.com" `
-Notify "NotifyServers" `
-NotifyServers "192.168.10.11", "192.168.10.12" `
-PassThru
# Trigger an immediate zone transfer on the secondary
Start-DnsServerZoneTransfer -Name "corp.example.com" -FullTransfer
Step 9: Signing Zones with DNSSEC
DNSSEC (DNS Security Extensions) adds cryptographic signatures to DNS records, allowing resolvers to verify that responses are authentic and have not been tampered with. On Windows Server 2025, you sign a zone using Invoke-DnsServerZoneSign, which generates Key Signing Keys (KSK) and Zone Signing Keys (ZSK) automatically.
# Sign a zone with DNSSEC using default settings (KSK + ZSK auto-generated)
Invoke-DnsServerZoneSign `
-ZoneName "corp.example.com" `
-SignWithDefault `
-Force `
-PassThru
# View DNSSEC signing properties
Get-DnsServerZoneDnsSecSettings -ZoneName "corp.example.com"
# List DNSSEC signing keys
Get-DnsServerSigningKey -ZoneName "corp.example.com" |
Select-Object KeyType, SigningAlgorithm, KeyLength, NextRolloverAction
# Add a Trust Anchor on a resolving server to validate the signed zone
Add-DnsServerTrustAnchor -ZoneName "corp.example.com" -ComputerName "resolver01"
# Unsign a zone if needed
Invoke-DnsServerZoneUnsign -ZoneName "corp.example.com" -Force
Step 10: Configuring Negative Caching via SOA Record TTLs
The Start of Authority (SOA) record controls how long negative responses (NXDOMAIN — a name that does not exist) are cached by resolvers. Tuning the negative TTL avoids excessive queries for non-existent names while ensuring that newly created records propagate quickly after an incorrect NXDOMAIN was cached.
# View the current SOA record settings
Get-DnsServerZone -Name "corp.example.com" | Select-Object -ExpandProperty NegativeAnswerTtl
# Modify the SOA record to set a 5-minute negative TTL
$soaRecord = Get-DnsServerResourceRecord -ZoneName "corp.example.com" -Name "@" -RRType "SOA"
$newSoaRecord = $soaRecord.Clone()
$newSoaRecord.RecordData.ExpireLimit = [System.TimeSpan]::FromDays(7)
$newSoaRecord.RecordData.MinimumTimeToLive = [System.TimeSpan]::FromMinutes(5)
$newSoaRecord.RecordData.RefreshInterval = [System.TimeSpan]::FromHours(1)
$newSoaRecord.RecordData.RetryDelay = [System.TimeSpan]::FromMinutes(15)
Set-DnsServerResourceRecord `
-ZoneName "corp.example.com" `
-OldInputObject $soaRecord `
-NewInputObject $newSoaRecord `
-PassThru
Conclusion
Properly structured DNS zones and accurate resource records are the backbone of a healthy Windows Server 2025 environment. From the fundamental A and MX records that enable basic connectivity and email, to the SRV records that Active Directory depends on, to the TXT records that protect your domain’s email reputation — every record type serves a specific purpose. Combining zone transfers for redundancy, DNSSEC signing for integrity verification, and well-tuned SOA TTLs for negative caching creates a DNS infrastructure that is resilient, secure, and easy to validate using the built-in Resolve-DnsName cmdlet. Invest time in getting these configurations right, and your DNS layer will serve as a solid foundation for every other service in your environment.