How to Set Up Read-Only Domain Controllers on Windows Server 2022

Introduction to DNS Zones and Records on Windows Server 2022

Once your DNS Server role is installed and running, the day-to-day operational task is managing zones and resource records. DNS records are the entries that map names to addresses and define services available within your domain. Windows Server 2022 provides a rich PowerShell interface through the DnsServer module, allowing administrators to script, automate, and audit every aspect of zone and record management. This guide covers creating and managing DNS zones, adding all major record types, controlling TTL values, delegating zones, managing dynamic DNS updates, and exporting or importing zone data.

Creating a Primary Zone

A primary zone is the authoritative read/write copy of DNS data for a domain. In an Active Directory environment, primary zones are almost always AD-integrated, which stores the zone in the AD database and replicates it via AD replication rather than traditional zone transfers.

Create an AD-integrated primary forward lookup zone:

Add-DnsServerPrimaryZone -Name "corp.example.com" -ReplicationScope "Domain" -DynamicUpdate "Secure" -PassThru

The -DynamicUpdate parameter controls how clients can register DNS records automatically. Options are:

None — No dynamic updates allowed; all records must be created manually.

NonsecureAndSecure — Any client can register a record, including unauthenticated machines.

Secure — Only authenticated AD-joined machines can register records. This is the recommended setting for internal zones.

Create a file-backed (non-AD) primary zone:

Add-DnsServerPrimaryZone -Name "standalone.local" -ZoneFile "standalone.local.dns" -DynamicUpdate "None" -PassThru

File-backed zones store data in %SystemRoot%System32dns by default.

Creating Secondary and Stub Zones

A secondary zone receives a read-only copy of zone data from the primary via zone transfer. It is used for redundancy and to reduce query load on the primary.

Add-DnsServerSecondaryZone -Name "corp.example.com" -ZoneFile "corp.example.com.dns" -MasterServers "192.168.10.5" -PassThru

A stub zone contains only the NS and SOA records and the glue A records needed to contact the authoritative servers for a zone. Stub zones are lighter than secondary zones and help with delegation resolution:

Add-DnsServerStubZone -Name "branch.corp.example.com" -MasterServers "10.10.0.5" -ReplicationScope "Domain" -PassThru

Adding A and AAAA Records

An A record maps a hostname to an IPv4 address. An AAAA record maps a hostname to an IPv6 address. These are the most common records you will create.

# Add an A record
Add-DnsServerResourceRecordA -ZoneName "corp.example.com" -Name "web01" -IPv4Address "192.168.10.50" -TimeToLive 01:00:00 -PassThru

# Add an AAAA record
Add-DnsServerResourceRecordAAAA -ZoneName "corp.example.com" -Name "web01" -IPv6Address "2001:db8::50" -TimeToLive 01:00:00 -PassThru

The -TimeToLive parameter accepts a TimeSpan value in DD:HH:MM:SS format. In this example, 01:00:00 means one hour. For hosts that change IP addresses frequently, use shorter TTLs. For stable infrastructure like domain controllers or mail servers, longer TTLs (4 hours or more) reduce query load.

To add a corresponding PTR record in the reverse lookup zone at the same time:

Add-DnsServerResourceRecordA -ZoneName "corp.example.com" -Name "web01" -IPv4Address "192.168.10.50" -CreatePtr -PassThru

Adding MX Records

Mail Exchange (MX) records specify the mail server responsible for accepting email for a domain. Every mail-enabled domain needs at least one MX record.

Add-DnsServerResourceRecordMX -ZoneName "corp.example.com" -Name "@" -MailExchange "mail.corp.example.com" -Preference 10 -TimeToLive 01:00:00 -PassThru

The -Name "@" applies the MX record to the zone apex (the root of the domain, i.e., corp.example.com itself). The -Preference value (also called priority) determines which mail server is tried first when multiple MX records exist — lower numbers are preferred.

To add a backup mail server with a higher preference number (tried second):

Add-DnsServerResourceRecordMX -ZoneName "corp.example.com" -Name "@" -MailExchange "mail2.corp.example.com" -Preference 20 -TimeToLive 01:00:00 -PassThru

Ensure that the mail server hostname referenced in the MX record has its own A record, or mail delivery will fail.

Adding CNAME Records

A CNAME (Canonical Name) record creates an alias that points to another hostname. This is useful when you want multiple names to resolve to the same server without duplicating A records.

Add-DnsServerResourceRecordCName -ZoneName "corp.example.com" -Name "intranet" -HostNameAlias "web01.corp.example.com" -TimeToLive 00:30:00 -PassThru

This creates an alias so that intranet.corp.example.com resolves to whatever web01.corp.example.com resolves to. If you later migrate the intranet to a different server, you only update the A record for web01 and the CNAME continues to work.

Important constraints: You cannot create a CNAME at the zone apex (the root of the domain), and you should not point MX or NS records at a CNAME — this violates RFC 2181 and can cause mail delivery failures.

Adding SRV Records

Service (SRV) records define the location of network services. Active Directory relies heavily on SRV records for clients to locate domain controllers, Kerberos servers, and LDAP services. You can also use SRV records for services like SIP, XMPP, or custom applications.

Add-DnsServerResourceRecordSrv `
    -ZoneName "corp.example.com" `
    -Name "_ldap._tcp" `
    -DomainName "dc01.corp.example.com" `
    -Port 389 `
    -Priority 0 `
    -Weight 100 `
    -TimeToLive 00:20:00 `
    -PassThru

The SRV record format follows the convention _service._protocol. Priority and weight control load distribution when multiple SRV records exist for the same service — lower priority values are preferred, and weight controls relative load share among records with equal priority.

AD automatically creates the required SRV records during domain controller promotion, but you may need to manually register them if they go missing. On the domain controller, run:

nltest /dsregdns

Or restart the Net Logon service, which re-registers all AD SRV records:

Restart-Service -Name Netlogon

TTL Management

Time-to-Live (TTL) controls how long a DNS resolver caches a record before querying the authoritative server again. Choosing appropriate TTL values balances caching efficiency against propagation speed for changes.

View the default TTL for a zone (the SOA minimum TTL):

Get-DnsServerResourceRecord -ZoneName "corp.example.com" -RRType "SOA"

Set the zone’s default TTL (applied to records without explicit TTL):

Set-DnsServerZone -Name "corp.example.com" -DnsSecSigned $false -PassThru

For planned maintenance, lower the TTL of affected records at least 24–48 hours in advance, perform the change, then raise the TTL back:

# Lower TTL before planned change
$rec = Get-DnsServerResourceRecord -ZoneName "corp.example.com" -Name "app01" -RRType "A"
$newrec = $rec.Clone()
$newrec.TimeToLive = [System.TimeSpan]::FromMinutes(5)
Set-DnsServerResourceRecord -ZoneName "corp.example.com" -OldInputObject $rec -NewInputObject $newrec -PassThru

Zone Delegation

Zone delegation allows you to hand authority for a subdomain off to different DNS servers. For example, if a branch office manages its own DNS for branch.corp.example.com, the parent zone at corp.example.com must have a delegation pointing to the branch DNS servers.

Add-DnsServerZoneDelegation `
    -Name "corp.example.com" `
    -ChildZoneName "branch" `
    -IPAddress "10.10.0.5" `
    -NameServer "ns1.branch.corp.example.com" `
    -PassThru

This creates an NS record for branch.corp.example.com pointing to ns1.branch.corp.example.com at 10.10.0.5, along with a glue A record. Glue records are necessary when the name server for the delegated zone is within the zone being delegated, to prevent a circular dependency.

DNS Aging and Scavenging for Records

Dynamic DNS allows clients to register their own A and PTR records. Over time, when machines leave the network without deregistering, stale records accumulate. DNS aging assigns a timestamp to dynamically registered records, and scavenging removes them once they exceed the no-refresh plus refresh interval.

Check the timestamp on an existing record:

Get-DnsServerResourceRecord -ZoneName "corp.example.com" -Name "laptop01" -RRType "A" | Select-Object -ExpandProperty RecordData

Records with a timestamp of zero were created statically and are exempt from scavenging. Records with a real timestamp are dynamic and eligible once the aging interval expires.

To reset the timestamp on a record (force it to be treated as freshly registered):

$rec = Get-DnsServerResourceRecord -ZoneName "corp.example.com" -Name "laptop01" -RRType "A"
$newrec = $rec.Clone()
$newrec.TimeToLive = [System.TimeSpan]::FromHours(1)
Set-DnsServerResourceRecord -ZoneName "corp.example.com" -OldInputObject $rec -NewInputObject $newrec

Dynamic DNS Updates

Dynamic DNS (DDNS) allows DNS clients and DHCP servers to automatically register and update DNS records. In a Windows environment, the DHCP server can register records on behalf of older clients that do not support DDNS natively.

View the dynamic update setting for a zone:

Get-DnsServerZone -Name "corp.example.com" | Select-Object ZoneName, DynamicUpdate

Change the dynamic update mode:

Set-DnsServerPrimaryZone -Name "corp.example.com" -DynamicUpdate "Secure" -PassThru

For secure dynamic updates, the machine account in AD must have permission to update its own record. This is granted automatically when machines join the domain.

Force a Windows client to re-register its DNS record:

ipconfig /registerdns

Importing and Exporting Zone Files

You can export DNS zone data to a standard BIND-format zone file for backup or migration purposes. For AD-integrated zones, first convert to a file-backed zone, export, then convert back:

# Export all records from a zone to a file
Get-DnsServerResourceRecord -ZoneName "corp.example.com" | Export-Csv -Path "C:DNScorp_export.csv" -NoTypeInformation

To get a raw BIND-format file, convert the AD-integrated zone to a standard primary zone temporarily. This creates a zone file in C:WindowsSystem32dns:

ConvertTo-DnsServerPrimaryZone -Name "corp.example.com" -ZoneFile "corp.example.com.dns" -Force -PassThru

To import records from a BIND zone file into an existing zone:

Import-DnsServerResourceRecordFile -ZoneName "corp.example.com" -ZoneFile "C:DNSimport.dns"

Querying DNS Records with PowerShell

The Get-DnsServerResourceRecord cmdlet lets you query all records in a zone or filter by type:

# Get all A records in a zone
Get-DnsServerResourceRecord -ZoneName "corp.example.com" -RRType "A" | Format-Table HostName, RecordData, TimeToLive

# Get all MX records
Get-DnsServerResourceRecord -ZoneName "corp.example.com" -RRType "MX"

# Get a specific record by name
Get-DnsServerResourceRecord -ZoneName "corp.example.com" -Name "web01"

# Count all records in a zone
(Get-DnsServerResourceRecord -ZoneName "corp.example.com").Count

For client-side testing, use Resolve-DnsName to verify records resolve correctly:

Resolve-DnsName -Name "web01.corp.example.com" -Type A -Server "192.168.10.5"
Resolve-DnsName -Name "corp.example.com" -Type MX -Server "192.168.10.5"
Resolve-DnsName -Name "192.168.10.50" -Type PTR -Server "192.168.10.5"

Conclusion

Effective DNS zone and record management on Windows Server 2022 requires familiarity with both the graphical DNS Manager console and the DnsServer PowerShell module. By creating zones with appropriate replication scopes and dynamic update policies, maintaining clean records through aging and scavenging, carefully managing TTL values, and using delegation correctly for subdomain authority, administrators can build a DNS infrastructure that is accurate, performant, and maintainable at scale. Scripting record creation and auditing with PowerShell ensures consistency across environments and simplifies disaster recovery procedures.