Deploy redundant AD-integrated DNS on Windows Server 2025
Build a secure two-server Microsoft DNS service for Active Directory with replicated forward/reverse zones, controlled recursion, authenticated updates, staged scavenging, concrete failover tests, and supported recovery evidence.
Make name resolution an observable, redundant identity dependency whose authority, update ownership, recursive paths, record lifecycle, privacy, and recovery are explicit before clients rely on it.
- Windows Server 2025
- DNS Server 2025
- Active Directory Domain Services 2025
- Windows PowerShell 5.1
- Healthy controller pair Two accepted writable Windows Server 2025 domain controllers with healthy AD, DNS role, SYSVOL, time, sites, and replication.
- Namespace authority Approved forward/reverse zones, delegations, private/public split, partner namespaces, and authoritative owners.
- Network and recursion Client subnets, firewall paths, approved upstream resolvers, privacy requirements, and explicit protection against public recursion.
- Update ownership A documented decision for client versus DHCP A/PTR updates, dedicated DHCP credentials where used, and managed static exceptions.
- Lifecycle evidence Record/timestamp inventory, lease and refresh cadence, aging observation window, auditing, monitoring, and tested system-state recovery.
OneLiners never runs these steps or stores secrets. Review placeholders, versions, current state, and change-control requirements before using a command.
Full guide
What you will build
- Two authoritative Microsoft DNS servers on the accepted writable domain controllers, hosting redundant AD-integrated forward and reverse zones with secure dynamic updates.
- A controlled recursion design using approved forwarders, optional AD-replicated conditional forwarders, client/DHCP resolver settings, and explicit protection against an open resolver.
- A staged aging and scavenging policy with record, zone, server, replication, audit, and recovery checks that prevent premature deletion.
- Each DNS server independently answers AD SOA, NS, A/AAAA, PTR, and service-location queries and continues to serve clients during single-server maintenance.
- Domain members use only internal DNS, external lookups follow the monitored forwarding path, and dynamic records are authenticated and have a known owner.
- Operators can prove zone replication, query health, update behavior, scavenging timelines, monitoring, and supported recovery without relying on generic example output.
Architecture
How the parts fit together
DC01 and DC02 host Microsoft DNS and writable replicas of the forest and domain DNS application partitions. Clients query both internal addresses; DNS recursion forwards only through approved resolvers. AD DS replication carries zone changes, while DHCP or authenticated clients create secure records. One designated server performs scavenging after a staged observation period. Network controls keep recursion private and monitoring observes both service and data correctness.
- A client sends a query to one of the two internal DNS servers configured on its adapter.
- The server answers authoritative internal data from its AD-integrated replica or recursively forwards an allowed external query.
- A domain client or DHCP server authenticates a secure dynamic update; the resulting DNS object replicates through AD.
- A designated scavenger considers only timestamped records after the full no-refresh, refresh, and scavenging safety timeline.
Assumptions
- The Windows Server 2025 forest and both controllers from the preceding guide pass replication, DNS service, time, SYSVOL, and security acceptance.
- This guide covers private AD DNS. Public authoritative DNS should remain in a separately secured service and delegation model.
- Network and security teams have approved client subnets, recursive access, upstream forwarders, partner conditional zones, reverse networks, logging, and data retention.
- A DHCP design identifies who owns A/PTR updates. If DHCP performs updates, both failover peers use the same dedicated least-privilege credential.
- Aging/scavenging begins with inventory and observation. It is not enabled globally on day one and does not delete manually created static records as a cleanup substitute.
Key concepts
- AD-integrated zone
- A DNS zone stored as directory objects and replicated through AD DS, enabling multimaster writable service and secure dynamic updates.
- Replication scope
- The DNS application partition boundary determining which DNS-capable controllers receive a zone, commonly Domain or Forest.
- Secure dynamic update
- An authenticated DNS update whose directory ACL and record ownership restrict who can modify the name.
- Forwarder
- An upstream resolver that receives recursive queries the local server cannot answer authoritatively.
- Conditional forwarder
- A forwarding rule for one namespace, represented internally as a zone and optionally replicated in AD.
- No-refresh interval
- The period after a timestamp update during which identical refreshes do not rewrite the record, reducing AD replication load.
- Refresh interval
- The following period in which the owner can refresh the timestamp before a dynamic record becomes eligible for scavenging.
- Scavenging
- Server-side deletion of stale timestamped records after zone, record, server, replication, and time safety conditions are satisfied.
Before you copy
Values used in this guide
{{adDomainFqdn}}Existing AD DNS namespace hosted by the controller pair.
Example: corp.example.com{{dcOneFqdn}}First accepted DNS-capable controller.
Example: dc01.corp.example.com{{dcTwoFqdn}}Second accepted DNS-capable controller.
Example: dc02.corp.example.com{{dcOneIp}}Fixed IPv4 address of DC01.
Example: 10.20.0.10{{dcTwoIp}}Fixed IPv4 address of DC02.
Example: 10.20.0.11{{dnsCanaryFqdn}}Actual FQDN of the dedicated domain-joined client used for authenticated registration tests.
Example: dns-canary.corp.example.com{{dnsCanaryIp}}Current approved IPv4 address of the DNS registration canary.
Example: 10.20.0.50{{reverseNetwork}}IPv4 network identifier used by Add-DnsServerPrimaryZone to derive the reverse zone.
Example: 10.20.0.0/24{{forwarderOne}}First approved upstream recursive resolver address.
Example: 192.0.2.53{{forwarderTwo}}Second approved upstream recursive resolver address.
Example: 192.0.2.54{{partnerZone}}Optional private partner namespace to forward conditionally.
Example: partner.example.net{{partnerDnsIp}}Approved authoritative/recursive master for the partner zone.
Example: 198.51.100.53Security and production boundaries
- Never configure public resolvers on a domain controller or member adapter. Internal servers must answer AD records and may forward approved external queries.
- Allow secure dynamic updates on AD-integrated zones; nonsecure updates allow unauthenticated record manipulation and are not a convenience setting.
- Limit DNS reachability and recursion to approved networks. Domain-controller DNS should not become an internet-facing open resolver.
- Query and analytical logs can reveal users, hosts, applications, domains, and investigation activity. Collect the minimum needed, protect access, and enforce short purposeful retention.
- DNS administrators can redirect identity and application traffic. Use Tier-0 administration, reviewed changes, audit events, and independent verification.
Stop before continuing if
- Stop if either controller has unresolved AD replication, DNS, time, SYSVOL, or event-log failures.
- Stop client rollout if any adapter or DHCP option includes a public/nonauthoritative resolver or only one reachable internal server.
- Stop secure-update changes if record ownership, DHCP credentials, or A/PTR responsibility is unclear.
- Stop scavenging if timestamps, intervals, lease/registration cadence, static exclusions, audit events, or recovery are not understood.
- Stop any recovery plan that proposes deleting the AD-integrated zone, importing a text file over live directory data, or disabling security to regain name resolution.
verification
Inventory authoritative zones, partitions, interfaces, and dependencies
Capture zone type, replication scope, dynamic-update mode, directory partition membership, server addresses, DNS client settings, forwarders, root hints, listening interfaces, recursion exposure, and baseline diagnostics on both controllers before changing anything. Reserve an actual noncritical canary FQDN and address for the later authenticated registration test.
Why this step matters
DNS changes are safe only when current authority, replication, client dependencies, and recursive paths are known. An inventory also exposes accidental public resolvers and zones stored outside the intended partitions.
What to understand
Run equivalent queries against both servers rather than assuming AD replication made configuration identical.
The _msdcs forest zone contains locator data used beyond a single domain; the domain zone usually belongs in DomainDnsZones.
Capture interface/listener and network ACL policy separately because PowerShell zone output does not prove the service is unreachable from untrusted networks.
System changes
- The commands read DNS server, directory partition, and adapter state. Store the internal topology output in the restricted change record.
Syntax explained
Get-DnsServerZone- Lists authoritative/forwarder zones and their AD integration, replication, and update properties.
Get-DnsServerDirectoryPartition- Shows application partition enrollment used for AD-integrated DNS replication.
Get-DnsClientServerAddress- Reveals adapter resolver dependencies that can create circular or external lookup failures.
Values stay on this page and are never sent or saved.
'{{dnsCanaryFqdn}}','{{dnsCanaryIp}}' | ForEach-Object { $_ }; Get-DnsServerZone -ComputerName '{{dcOneFqdn}}' | Select-Object ZoneName,ZoneType,IsDsIntegrated,ReplicationScope,DynamicUpdate; Get-DnsServerZone -ComputerName '{{dcTwoFqdn}}' | Select-Object ZoneName,ZoneType,IsDsIntegrated,ReplicationScope,DynamicUpdate; Get-DnsServerDirectoryPartition -ComputerName '{{dcOneFqdn}}'; Get-DnsClientServerAddress -AddressFamily IPv4; Get-DnsServerForwarder -ComputerName '{{dcOneFqdn}}'ZoneName ZoneType IsDsIntegrated ReplicationScope DynamicUpdate corp.example.com Primary True Domain Secure _msdcs.corp.example.com Primary True Forest Secure 0.20.10.in-addr.arpa Primary True Forest Secure Directory partitions: DomainDnsZones.corp.example.com Enlisted ForestDnsZones.corp.example.com Enlisted DC01 adapter DNS: 10.20.0.11, 10.20.0.10 DC02 adapter DNS: 10.20.0.10, 10.20.0.11 Forwarders: 192.0.2.53, 192.0.2.54
Checkpoint: Verify this layer before continuing
Continue whenBoth servers show the expected AD-integrated zones and partitions, adapters use the internal pair, and recursion/forwarder/network ownership is documented.
Stop whenStop if zone type/scope differs, a partition is absent, public DNS appears on an adapter, or an untrusted network can reach recursion.
If this step fails
DC02 does not list the domain zone.
Likely causeIt is not enlisted in the application partition or AD replication has not converged.
Inspect Get-DnsServerDirectoryPartition and repadmin /showrepl on DC02.Review Directory Service and DNS Server events for application-partition replication.
ResolutionRepair AD replication or supported partition enrollment before creating records or changing client preference.
Security notes
- DNS inventory reveals internal namespaces, addresses, and partners; do not publish it.
Alternatives
- Use DNS Manager for a peer-reviewed visual inventory, retaining PowerShell evidence for repeatability.
Stop conditions
- Stop if zone type/scope differs, a partition is absent, public DNS appears on an adapter, or an untrusted network can reach recursion.
config
Normalize the forward zones for secure AD replication
Confirm the forest and domain zones are AD-integrated, use the intended replication scope, and allow only secure dynamic updates. This example normalizes the domain zone; change _msdcs separately only after confirming its forest scope.
Why this step matters
Secure multimaster DNS depends on the zone being stored in the right directory partition and accepting authenticated updates only. Replication scope should match who must answer authoritatively.
What to understand
Domain scope replicates to DNS-capable controllers in the domain; Forest scope is appropriate for forest-wide zones such as _msdcs and selected shared reverse zones.
Secure updates rely on AD authentication and record ACLs. Nonsecure and secure mode weakens ownership guarantees and is not a transitional default.
Make the change on one healthy server and observe it on the other through AD replication rather than issuing divergent commands everywhere.
System changes
- Updates zone properties in AD and replicates them to eligible DNS servers. It can change who receives the zone and who may submit dynamic updates.
Syntax explained
Set-DnsServerPrimaryZone- Changes properties of the existing primary zone.
-ReplicationScope Domain- Stores/replicates the zone through the domain DNS application partition.
-DynamicUpdate Secure- Accepts only authenticated dynamic updates to the AD-integrated zone.
Values stay on this page and are never sent or saved.
Set-DnsServerPrimaryZone -ComputerName '{{dcOneFqdn}}' -Name '{{adDomainFqdn}}' -ReplicationScope Domain -DynamicUpdate Secure; Get-DnsServerZone -ComputerName '{{dcTwoFqdn}}' -Name '{{adDomainFqdn}}' | Select-Object ZoneName,IsDsIntegrated,ReplicationScope,DynamicUpdateZoneName : corp.example.com IsDsIntegrated : True ReplicationScope : Domain DynamicUpdate : Secure Observed on DC02 after AD replication: True
Checkpoint: Verify this layer before continuing
Continue whenThe domain zone is AD-integrated, Domain-scoped, Secure, visible on both servers, and dcdiag dynamic-update tests pass.
Stop whenStop if the zone is file-backed unexpectedly, scope change would remove required servers, replication is unhealthy, or applications rely on nonsecure updates.
If this step fails
A legacy appliance can no longer register its name.
Likely causeIt does not support authenticated dynamic update and previously depended on insecure zone-wide access.
Confirm the appliance's supported DNS behavior and authoritative name owner.Inspect its previous record owner and update/audit events.
ResolutionCreate a reviewed static record or use DHCP/source-of-truth automation for that device; do not reopen the whole zone to nonsecure updates.
Security notes
- Zone ACL changes are Tier-0 changes because DNS can redirect identity services.
Alternatives
- Use controlled static records for systems that cannot perform secure updates.
Stop conditions
- Stop if the zone is file-backed unexpectedly, scope change would remove required servers, replication is unhealthy, or applications rely on nonsecure updates.
command
Create a secure AD-integrated reverse zone
Create the reverse lookup zone once with the approved network identifier, forest replication when both controllers must serve it, and secure dynamic updates. Confirm the derived in-addr.arpa name and delegation ownership before adding PTR data.
Why this step matters
Reverse DNS supports diagnostics, logging, certificate and access workflows that map addresses back to managed names. Creating the zone before DHCP deployment gives PTR updates an authoritative secure target.
What to understand
Use the actual CIDR boundary; classless delegation may require parent-side RFC 2317 design beyond a simple Add-DnsServerPrimaryZone network ID.
Forest replication is appropriate only when all forest DNS servers should host the reverse zone; otherwise choose Domain or a custom partition deliberately.
A PTR record does not prove host identity. Treat it as managed naming data, not authentication.
System changes
- Creates a new AD-integrated reverse zone and replicates it in ForestDnsZones. The empty zone becomes authoritative for the selected reverse namespace.
Syntax explained
-NetworkId- Accepts the IPv4 CIDR and derives the reverse-zone name.
-ReplicationScope Forest- Replicates the zone to DNS-capable controllers across the forest.
-DynamicUpdate Secure- Requires authenticated creation and refresh of PTR records.
Values stay on this page and are never sent or saved.
Add-DnsServerPrimaryZone -ComputerName '{{dcOneFqdn}}' -NetworkId '{{reverseNetwork}}' -ReplicationScope Forest -DynamicUpdate Secure; Get-DnsServerZone -ComputerName '{{dcTwoFqdn}}' | Where-Object ZoneName -like '*.in-addr.arpa' | Select-Object ZoneName,ReplicationScope,DynamicUpdateZoneName ReplicationScope DynamicUpdate 0.20.10.in-addr.arpa Forest Secure SOA primary server: dc01.corp.example.com NS records: dc01.corp.example.com, dc02.corp.example.com
Checkpoint: Verify this layer before continuing
Continue whenThe derived zone matches the authoritative network, appears on both servers after replication, has secure updates, and parent delegation is documented where needed.
Stop whenStop if the network overlaps another reverse authority, the parent cannot delegate, or Forest scope exposes data beyond policy.
If this step fails
The cmdlet says the zone already exists.
Likely causeThe network is already authoritative locally or a differently named classless zone covers it.
List reverse zones and inspect SOA/NS authority.Query the parent reverse hierarchy and compare the IPAM record.
ResolutionUse the existing authoritative zone if correct, or resolve ownership/delegation before any replacement; never create overlapping authorities.
Security notes
- PTR names can disclose asset roles; restrict zone transfer and enumeration paths.
Alternatives
- Create a narrower delegated reverse zone with a reviewed custom design for classless networks.
Stop conditions
- Stop if the network overlaps another reverse authority, the parent cannot delegate, or Forest scope exposes data beyond policy.
config
Configure monitored recursive forwarders on both replicas
Set the same approved upstream recursive resolvers on both DNS servers and decide explicitly whether root hints may be used when every forwarder is unavailable. Verify external resolution, timeout behavior, DNSSEC expectations, and egress policy from each server.
Why this step matters
Domain clients need external resolution without bypassing internal AD authority. Identical monitored forwarders provide a deliberate recursion chain and central policy point.
What to understand
Use at least two independently available approved upstreams when policy permits; test both success and failure instead of accepting a single happy query.
UseRootHint false makes forwarder failure behavior explicit and prevents unexpected direct internet DNS egress. Set true only with reviewed outbound access and monitoring.
Apply the configuration to both servers because server-level forwarders do not automatically become zone data replicated in AD.
System changes
- Changes server-level recursion targets and fallback behavior on both DNS services. External query availability and data path change immediately.
Syntax explained
Set-DnsServerForwarder- Defines recursive upstream addresses for a DNS server.
-IPAddress- Ordered approved forwarder list, not client adapter DNS addresses.
-UseRootHint $false- Prevents fallback to direct root-hint recursion when all forwarders fail.
Values stay on this page and are never sent or saved.
Set-DnsServerForwarder -ComputerName '{{dcOneFqdn}}' -IPAddress '{{forwarderOne}}','{{forwarderTwo}}' -UseRootHint $false; Set-DnsServerForwarder -ComputerName '{{dcTwoFqdn}}' -IPAddress '{{forwarderOne}}','{{forwarderTwo}}' -UseRootHint $false; Get-DnsServerForwarder -ComputerName '{{dcOneFqdn}}'; Resolve-DnsName -Server '{{dcOneIp}}' -Name www.microsoft.comIPAddress : {192.0.2.53, 192.0.2.54}
UseRootHint : False
Timeout(s) : 3
Name : www.microsoft.com
QueryType : A
IPAddress : 203.0.113.40
Server tested : 10.20.0.10
Response time : 34 msCheckpoint: Verify this layer before continuing
Continue whenBoth servers list identical approved forwarders, resolve internal data locally and external canaries through the expected path, and fail predictably when upstreams are unavailable.
Stop whenStop if upstream ownership, privacy, DNSSEC behavior, redundancy, egress ACLs, or monitoring is unknown.
If this step fails
External queries time out on DC02 only.
Likely causeIts firewall route, forwarder configuration, interface binding, or upstream ACL differs from DC01.
Compare Get-DnsServerForwarder and approved network paths on both servers.Test the two forwarder addresses separately from DC02 without changing clients.
ResolutionCorrect the node-specific configuration or ACL and repeat direct plus client queries before considering the pair redundant.
Security notes
- Forwarders can observe requested external domains. Select providers and retention according to privacy policy.
Alternatives
- Use controlled root-hint recursion when organizational policy intentionally avoids forwarding providers and supports the required egress/monitoring.
Stop conditions
- Stop if upstream ownership, privacy, DNSSEC behavior, redundancy, egress ACLs, or monitoring is unknown.
command
Add an AD-replicated conditional forwarder only for an owned partner path
When a private partner namespace is required, confirm authority and reachability, then create one Forest-scoped conditional forwarder. Do not use a conditional forwarder as an undocumented workaround for overlapping namespaces or broken delegation.
Why this step matters
A conditional forwarder confines one private namespace to its approved resolver and can replicate consistently through AD. It is useful for partner, trust, and segmented management domains when authority is explicit.
What to understand
Confirm the master returns authoritative or expected recursive data and that both sides understand split-horizon behavior.
Forest scope shares the object broadly. Use Domain or Custom scope when the namespace should not reach every DNS-capable controller.
Monitor the partner path separately from general internet forwarders because failure affects trusts or applications selectively.
System changes
- Creates a forwarder-zone object in AD and replicates it to the chosen scope. Queries under the namespace are sent to the configured master.
Syntax explained
Add-DnsServerConditionalForwarderZone- Creates a namespace-specific forwarding rule represented as a DNS zone.
-MasterServers- Lists the approved servers that can resolve the partner namespace.
-ReplicationScope Forest- Replicates the forwarder object to forest DNS servers.
Values stay on this page and are never sent or saved.
Add-DnsServerConditionalForwarderZone -ComputerName '{{dcOneFqdn}}' -Name '{{partnerZone}}' -MasterServers '{{partnerDnsIp}}' -ReplicationScope Forest; Get-DnsServerZone -ComputerName '{{dcTwoFqdn}}' -Name '{{partnerZone}}'; Resolve-DnsName -Server '{{dcTwoIp}}' -Name health.{{partnerZone}}ZoneName : partner.example.net ZoneType : Forwarder IsDsIntegrated : True ReplicationScope : Forest MasterServers : 198.51.100.53 health.partner.example.net A 198.51.100.80 Answer source: conditional forwarder on DC02
Checkpoint: Verify this layer before continuing
Continue whenThe forwarder appears on DC02 through AD replication and a named canary resolves through the partner path with bounded latency.
Stop whenStop if the zone overlaps local authority, partner identity is unverified, network route is untrusted, or scope exposes it beyond policy.
If this step fails
The conditional zone exists with different master servers.
Likely causeA prior integration or stale configuration already owns the namespace.
Inspect the existing zone, replication scope, change history, and successful queries.Confirm partner resolver addresses through the approved integration record.
ResolutionUpdate the existing object through its owner after reconciliation; do not create duplicate or more-specific forwarding rules to bypass conflict.
Security notes
- A private partner resolver becomes part of the authentication/name-resolution trust path; restrict and monitor it.
Alternatives
- Use a delegated authoritative zone, stub zone, or secondary zone when the data ownership and transfer model requires it.
Stop conditions
- Stop if the zone overlaps local authority, partner identity is unverified, network route is untrusted, or scope exposes it beyond policy.
config
Configure controller and client resolver order without public fallbacks
After both servers pass direct tests, configure each controller to prefer its partner and use itself as alternate according to the approved operational pattern. Publish both addresses to domain members through DHCP or configuration management, then validate from each important subnet.
Why this step matters
Redundant servers do not help clients that receive only one address or bypass internal authority. Controller resolver order must also avoid making each node isolated on its own stale view.
What to understand
Adapter DNS selection behavior is not a simple primary-then-secondary transaction for every query; every configured address must be authoritative and healthy.
Use DHCP options for managed dynamic clients and configuration policy for fixed servers, appliances, and infrastructure; keep a source of truth.
Pilot one subnet and perform planned single-server maintenance to prove clients continue discovering domain services.
System changes
- Changes resolver addresses on the selected adapter. Equivalent managed changes update DHCP options and member-server configuration, affecting all name resolution and domain discovery.
Syntax explained
Set-DnsClientServerAddress- Replaces adapter DNS addresses with the approved internal pair.
-InterfaceAlias- Targets one reviewed interface rather than every adapter blindly.
-ServerAddresses- Sets the ordered internal resolver list; neither value is a public fallback.
Values stay on this page and are never sent or saved.
Invoke-Command -ComputerName '{{dcOneFqdn}}' -ScriptBlock { Set-DnsClientServerAddress -InterfaceAlias 'Ethernet' -ServerAddresses '{{dcTwoIp}}','{{dcOneIp}}'; ipconfig /flushdns; ipconfig /registerdns; Get-DnsClientServerAddress -InterfaceAlias 'Ethernet' -AddressFamily IPv4 }; Invoke-Command -ComputerName '{{dcTwoFqdn}}' -ScriptBlock { Set-DnsClientServerAddress -InterfaceAlias 'Ethernet' -ServerAddresses '{{dcOneIp}}','{{dcTwoIp}}'; ipconfig /flushdns; ipconfig /registerdns; Get-DnsClientServerAddress -InterfaceAlias 'Ethernet' -AddressFamily IPv4 }; Resolve-DnsName -Server '{{dcTwoIp}}' -Type SRV _kerberos._tcp.{{adDomainFqdn}}InterfaceAlias ServerAddresses
Ethernet {10.20.0.11, 10.20.0.10}
_kerberos._tcp.corp.example.com SRV 0 100 88 dc01.corp.example.com
_kerberos._tcp.corp.example.com SRV 0 100 88 dc02.corp.example.com
Client pilot: 20/20 internal and external canaries passed
Single-DNS maintenance test: passedCheckpoint: Verify this layer before continuing
Continue whenControllers and pilot clients list only the two internal servers, resolve AD and external canaries, select the correct site, and survive one-server maintenance.
Stop whenStop broad rollout if any subnet cannot reach both servers, a device requires different authority, or discovery changes unexpectedly.
If this step fails
A pilot client still shows the old resolver after lease renewal.
Likely causeDHCP options, static adapter settings, VPN policy, or configuration management override the intended addresses.
Inspect ipconfig /all, lease source, adapter configuration, NRPT, VPN, and policy result.Compare the effective setting with DHCP scope/server option ownership.
ResolutionCorrect the authoritative configuration layer and retest; do not patch individual clients if policy will overwrite them.
Security notes
- Resolver configuration is a traffic-control security setting. Protect DHCP, VPN, and endpoint policy from unauthorized edits.
Alternatives
- Use site-local additional DNS replicas when WAN dependency cannot meet availability objectives.
Stop conditions
- Stop broad rollout if any subnet cannot reach both servers, a device requires different authority, or discovery changes unexpectedly.
verification
Prove secure A and PTR lifecycle with one controlled identity
Run the registration portion on the dedicated domain-joined canary whose actual FQDN and address are entered below; do not invent a DNS name that the client does not own. According to the chosen ownership model, let that client or DHCP register the PTR record. Then query both replicas and verify owner, timestamp, replication, renewal, and deletion behavior without enumerating production names.
Why this step matters
A real authenticated lifecycle proves more than zone properties: the client or DHCP identity must create, own, refresh, replicate, and eventually remove matching forward and reverse data.
What to understand
Use a dedicated canary with approved address and name. Record ownership should match the designed updater, not a personal Domain Admin.
Query each server directly to separate replication from client caching.
If DHCP owns updates, repeat the same test after DHCP deployment using its dedicated shared credential and the actual lease lifecycle.
System changes
- Initiates dynamic registration for the test client and may create or refresh A/PTR records and timestamps. It does not modify unrelated records.
Syntax explained
ipconfig /registerdns- Requests immediate client registration rather than waiting for the normal refresh interval.
Resolve-DnsName -Server- Queries one authoritative replica directly, bypassing resolver selection ambiguity.
/DnsDynamicUpdate- Tests authenticated dynamic-update behavior in dcdiag.
Values stay on this page and are never sent or saved.
ipconfig /registerdns; Resolve-DnsName -Server '{{dcOneIp}}' -Name '{{dnsCanaryFqdn}}'; Resolve-DnsName -Server '{{dcTwoIp}}' -Name '{{dnsCanaryFqdn}}'; Resolve-DnsName -Server '{{dcOneIp}}' -Type PTR '{{dnsCanaryIp}}'; Resolve-DnsName -Server '{{dcTwoIp}}' -Type PTR '{{dnsCanaryIp}}'; dcdiag /test:dns /DnsDynamicUpdate /DnsRecordRegistration /e /vRegistration of DNS resource records initiated. dns-canary.corp.example.com A 10.20.0.50 50.0.20.10.in-addr.arpa PTR dns-canary.corp.example.com Answers identical on DC01 and DC02: True Record timestamp: 2026-07-28 18:00 Record owner: CORPdns-canary$ DnsDynamicUpdate: passed DnsRecordRegistration: passed
Checkpoint: Verify this layer before continuing
Continue whenThe canary creates matching A/PTR data with the expected owner/timestamp, both replicas answer identically, refresh succeeds, and focused dcdiag tests pass.
Stop whenStop if the owner is privileged/unexpected, updates require nonsecure mode, records diverge, or deletion removes another asset's data.
If this step fails
A record is created but PTR is absent.
Likely causeThe client does not own reverse updates, DHCP is expected to create PTR, or reverse authority/delegation is incomplete.
Inspect client registration policy, DHCP DNS settings, reverse zone authority, and DNS audit events.Check the expected updater credential/owner without revealing its secret.
ResolutionAssign PTR ownership to the documented client or DHCP workflow, correct the reverse zone, and repeat the canary lease/registration lifecycle.
Security notes
- Do not use production host names or addresses in public test evidence.
Alternatives
- Use source-of-truth automation to manage static A/PTR pairs for infrastructure that should not dynamically register.
Stop conditions
- Stop if the owner is privileged/unexpected, updates require nonsecure mode, records diverge, or deletion removes another asset's data.
decision
Model aging from real refresh and lease intervals before enabling deletion
Inventory record timestamps and owners, classify static exceptions, measure client and DHCP refresh behavior, select no-refresh/refresh values, and calculate the earliest possible deletion. Run this as an observation exercise for at least one full lifecycle before changing zone/server scavenging.
Why this step matters
Scavenging deletes records. Its safe intervals depend on actual lease and registration cadence, replication, outages, and static exceptions, so observation must precede enablement.
What to understand
A record with timestamp zero is static and normally not scavenged. A timestamped infrastructure record may be deleted if its owner stops refreshing.
No-refresh reduces directory writes; refresh allows timestamp renewal. Deletion occurs only after both intervals and an eligible server cycle, not exactly at a simple deadline.
Review mobile, intermittently connected, long-lease, VPN, cluster, appliance, Azure, and disaster-recovery assets separately.
System changes
- The commands read record timestamp distribution and current aging/scavenging configuration. They may reveal names if expanded, so aggregate evidence is preferred.
Syntax explained
Get-DnsServerResourceRecord- Provides timestamp/record inventory used to identify dynamic and static populations.
Get-DnsServerZoneAging- Shows zone no-refresh/refresh settings and scavenging state.
Get-DnsServerScavenging- Shows server-level automatic scavenging configuration.
Values stay on this page and are never sent or saved.
Get-DnsServerResourceRecord -ComputerName '{{dcOneFqdn}}' -ZoneName '{{adDomainFqdn}}' | Group-Object Timestamp | Select-Object Count,Name; Get-DnsServerZoneAging -ComputerName '{{dcOneFqdn}}' -Name '{{adDomainFqdn}}'; Get-DnsServerScavenging -ComputerName '{{dcOneFqdn}}'Record inventory: Static timestamp 0: 84 Timestamped dynamic: 326 Unowned/unknown: 0 Proposed no-refresh: 7 days Proposed refresh: 7 days Server scavenging interval: 7 days Earliest deletion after fresh timestamp: later than 14 days plus next eligible scavenging cycle Observation window completed: 21 days Critical static exception list approved: 18 records
Checkpoint: Verify this layer before continuing
Continue whenEvery record class has an owner/lifecycle, intervals exceed valid refresh behavior, static exceptions are approved, and a full observation window produced no unexplained stale/active classification.
Stop whenStop if unknown owners/timestamps exist, intervals are shorter than any supported registration cadence, or replication/audit/recovery is incomplete.
If this step fails
Many server records are timestamped although administrators considered them static.
Likely causeHosts dynamically register even with fixed addresses, or records were converted/created through a dynamic workflow.
Inspect owner and registration events for a small representative sample.Compare Windows DNS client refresh policy and service lifecycle with the proposed intervals.
ResolutionClassify the records correctly and fix their authoritative registration/ownership; do not bulk-zero timestamps without a maintained source of truth.
Security notes
- Record inventories contain asset intelligence. Aggregate and restrict the evidence.
Alternatives
- Keep scavenging disabled and manage records declaratively when lifecycle evidence cannot make automated deletion safe.
Stop conditions
- Stop if unknown owners/timestamps exist, intervals are shorter than any supported registration cadence, or replication/audit/recovery is incomplete.
config
Enable zone aging and one designated scavenging server in stages
After the observation gate, enable aging on the intended dynamic zones with reviewed intervals, designate DC01 as the only automatic scavenger, and wait through the documented safety start time. Monitor DNS audit events and candidate records; do not immediately force a manual scavenge.
Why this step matters
Staged zone aging plus one designated scavenger removes genuinely stale dynamic data while preserving a clear deletion authority and the built-in waiting safeguards.
What to understand
Zone aging replicates through AD; server automatic scavenging is configured only on the designated node.
ApplyOnAllZones false prevents accidental activation on zones with different lifecycle or static authority.
The first eligible time is delayed. Observe events and timestamps; forcing early cycles defeats the safety model and makes incident attribution harder.
System changes
- Enables timestamps/aging rules for the selected zone and schedules automatic stale-record deletion on DC01. Eligible records may be deleted after the configured timeline.
Syntax explained
Set-DnsServerZoneAging- Enables zone aging and sets no-refresh, refresh, and allowed scavenging server values.
-ScavengeServers- Restricts which server may scavenge this zone.
Set-DnsServerScavenging- Enables the automatic cycle on the designated DNS server.
-ApplyOnAllZones:$false- Avoids applying the server defaults indiscriminately to every zone.
Values stay on this page and are never sent or saved.
Set-DnsServerZoneAging -ComputerName '{{dcOneFqdn}}' -Name '{{adDomainFqdn}}' -Aging $true -NoRefreshInterval 7.00:00:00 -RefreshInterval 7.00:00:00 -ScavengeServers '{{dcOneIp}}'; Set-DnsServerScavenging -ComputerName '{{dcOneFqdn}}' -ScavengingState $true -ScavengingInterval 7.00:00:00 -ApplyOnAllZones:$false; Get-DnsServerZoneAging -ComputerName '{{dcTwoFqdn}}' -Name '{{adDomainFqdn}}'; Get-DnsServerScavenging -ComputerName '{{dcOneFqdn}}'Zone: corp.example.com AgingEnabled: True NoRefreshInterval: 7.00:00:00 RefreshInterval: 7.00:00:00 ScavengeServers: 10.20.0.10 Observed on DC02: True Automatic scavenging server: DC01 Scavenging interval: 7.00:00:00 Apply on all zones: False Zone can be scavenged after: 2026-08-04 18:00
Checkpoint: Verify this layer before continuing
Continue whenZone settings replicate, only DC01 is scheduled, the safety date is recorded, candidate review/audit monitoring is active, and no critical record is unexpectedly eligible.
Stop whenStop and disable the narrow new scavenging setting if a valid record becomes stale, replication is unhealthy, audit events are unavailable, or intervals do not match observed registration.
If this step fails
No records are deleted after the first expected date.
Likely causeThe record, zone, or server level is incomplete, the zone start time/cycle has not elapsed, or replication safety prevents scavenging.
Inspect record timestamps, zone can-be-scavenged-after time, server next cycle, and DNS audit events.Confirm DC01 replicated the partition after service start and is listed as scavenging server.
ResolutionCorrect the missing level or replication issue and wait through the recalculated safety timeline; do not repeatedly force deletion.
Security notes
- Scavenging is destructive. Preserve zone settings, critical records, event forwarding, and current system-state backup before enabling it.
Alternatives
- Run report-only lifecycle analysis and retain manual approval if automatic deletion risk remains unacceptable.
Stop conditions
- Stop and disable the narrow new scavenging setting if a valid record becomes stale, replication is unhealthy, audit events are unavailable, or intervals do not match observed registration.
verification
Exercise failover, recursion boundaries, monitoring, and recovery evidence
From representative networks, query each server directly, then remove one from the test client's reachable path and prove internal/external resolution continues. Test that an untrusted source cannot recurse, inspect latency/failure counters and audit events, and confirm current AD system-state recovery evidence.
Why this step matters
Acceptance must prove client-visible redundancy, not only server configuration. It must also prove that recursion is unavailable to untrusted networks and that operators can detect data or service failure.
What to understand
Perform a controlled network/service maintenance test rather than powering off a controller unexpectedly.
Monitor authoritative SOA/SRV/A/PTR correctness separately from generic DNS process liveness and external recursion.
AD-integrated DNS recovery follows directory recovery. Keep supplemental exports as evidence only and maintain tested system-state backups.
System changes
- Diagnostics are read-only. The controlled failover temporarily removes one resolver path for synthetic clients and may create monitoring/audit events.
Syntax explained
Resolve-DnsName -Server- Tests each replica independently for an exact record type.
dcdiag /test:dns /e /v- Runs detailed DNS checks across every controller.
Get-DnsServerStatistics- Provides query, response, recursion, and failure counters for operational baselines.
wbadmin get versions- Confirms the current supported AD system-state recovery catalog.
Values stay on this page and are never sent or saved.
Resolve-DnsName -Server '{{dcOneIp}}' -Type SOA '{{adDomainFqdn}}'; Resolve-DnsName -Server '{{dcTwoIp}}' -Type SRV _ldap._tcp.dc._msdcs.{{adDomainFqdn}}; dcdiag /test:dns /e /v; Get-DnsServerStatistics -ComputerName '{{dcOneFqdn}}'; wbadmin get versionsDC01 SOA corp.example.com: authoritative, 7 ms DC02 forest SRV answer: dc01, dc02, authoritative, 9 ms Pilot with DC01 unavailable: 50/50 internal and external canaries passed through DC02 Untrusted recursion test: refused/blocked dcdiag DNS: passed on 2/2 controllers Server failure rate: 0.00% System State version: 07/28/2026-15:00 recoverable Alert delivery test: passed
Checkpoint: Verify this layer before continuing
Continue whenEither server alone serves all required canaries, untrusted recursion is blocked, diagnostics and alerts pass, metrics are baselined, and supported recovery evidence is current.
Stop whenStop production acceptance if single-server operation, any subnet, authoritative data, recursion boundary, monitoring, or backup test fails.
If this step fails
The service is reachable but queries hang during single-server maintenance.
Likely causeClients cannot reach the alternate server, the relay/VPN/firewall path is asymmetric, or cached adapter configuration lists only the removed server.
Collect effective resolver settings and Test-NetConnection/packet evidence from one affected test client.Query the surviving server directly from each network and inspect ACLs.
ResolutionFix the path or configuration source, refresh the controlled client state, and repeat the full maintenance test before acceptance.
Security notes
- Use synthetic names and restrict logs; DNS evidence can expose browsing and infrastructure behavior.
Alternatives
- Add site-local replicas and anycast/policy only after this simple pair is healthy and the complexity has an explicit availability benefit.
Stop conditions
- Stop production acceptance if single-server operation, any subnet, authoritative data, recursion boundary, monitoring, or backup test fails.
Finish line
Verification checklist
Get-DnsServerZone -ComputerName '{{dcOneFqdn}}'; Get-DnsServerZone -ComputerName '{{dcTwoFqdn}}'Both servers host the same intended AD-integrated zones with correct partition scopes and Secure dynamic updates.Resolve-DnsName -Server '{{dcOneIp}}' -Type SRV _ldap._tcp.dc._msdcs.{{adDomainFqdn}}; Resolve-DnsName -Server '{{dcTwoIp}}' -Type SRV _kerberos._tcp.{{adDomainFqdn}}Both authoritative replicas return the accepted controller set and bounded latency.Resolve-DnsName -Server '{{dcOneIp}}' dns-canary.{{adDomainFqdn}}; Resolve-DnsName -Server '{{dcTwoIp}}' -Type PTR 10.20.0.50A and PTR canaries match, have the designed owner/timestamp, and are consistent on both replicas.dcdiag /test:dns /e /vBasic, delegation, forwarder, dynamic-update, registration, and external-resolution checks have no unresolved failures.Resolve-DnsName -Server '{{dcTwoIp}}' -Type SOA '{{adDomainFqdn}}'Synthetic clients continue internal and external resolution through one server while the other is deliberately unavailable, and untrusted recursion remains blocked.Recovery guidance
Common problems and safe checks
A domain member intermittently reports that the domain is unavailable.
Likely causeIts adapter uses a public resolver, only one internal server, an unreachable DNS server, or a stale address supplied by DHCP.
Collect ipconfig /all and Get-DnsClientServerAddress from the affected member and compare each configured resolver with the approved pair.Query the domain SOA and _ldap._tcp.dc._msdcs SRV records explicitly against each configured address.
ResolutionCorrect the adapter or DHCP options so the client uses only the accepted internal DNS pair, renew policy in a controlled window, flush only the affected client cache, and repeat site/controller discovery.
DC01 resolves a record that DC02 does not, or vice versa.
Likely causeAD replication of the DNS application partition is delayed or failed, one server does not host the partition, or the query hit a cached answer.
Compare Get-DnsServerZone on both servers, repadmin /showrepl, Get-ADReplicationPartnerMetadata, and a direct no-recursion query for the record.Inspect DNS Server and Directory Service events for DomainDnsZones and ForestDnsZones replication.
ResolutionRepair the directory replication or partition enrollment and verify the authoritative data converges. Do not create duplicate manual records on the lagging server.
Secure dynamic updates fail for domain clients.
Likely causeThe zone allows no updates, record ownership belongs to a retired principal, the client cannot authenticate, DHCP credentials differ, or replication/DNS time is unhealthy.
Inspect zone DynamicUpdate mode, the record owner through the DNS console, client DNS Client events, Kerberos/time, and DHCP DNS credential configuration without exposing the credential.Use ipconfig /registerdns on one controlled test client and capture server audit events.
ResolutionRestore secure update configuration and the correct authenticated owner path. Coordinate DHCP credential changes across failover partners and avoid enabling nonsecure updates.
External names fail while internal AD names resolve.
Likely causeForwarders are unreachable, recursion is disabled for clients that require it, root-hint egress is blocked, or DNSSEC validation/upstream behavior fails.
Use Resolve-DnsName against each internal server for an approved external test name, inspect Get-DnsServerForwarder, server statistics, and DNS events.Test TCP/UDP 53 only from the DNS servers to the approved forwarders and compare direct authoritative evidence where permitted.
ResolutionRepair the approved forwarding path or its monitored upstreams. Do not place public resolvers directly on domain-member adapters as a workaround.
A conditional forwarder returns SERVFAIL or times out.
Likely causeMaster server addresses are stale, routing or firewall policy blocks them, the partner does not answer the forwarded zone, or AD replication has not delivered the conditional-forwarder object.
Inspect Get-DnsServerZone and Get-DnsServerConditionalForwarderZone on both servers and query the partner master explicitly for the zone SOA.Validate the approved network path and compare the conditional-forwarder replication scope.
ResolutionCorrect the partner masters or controlled network path, confirm authoritative answers, and allow AD replication to converge before retesting clients.
Reverse lookup does not return PTR records for DHCP clients.
Likely causeThe reverse zone uses the wrong network ID, DHCP is not configured to update PTR records, credentials cannot own/update records, or delegation for a subnet is missing.
Inspect the reverse zone name and scope, DHCP DNS settings/audit events, and Resolve-DnsName -Type PTR against each server.Compare one lease address, its expected PTR owner, and the corresponding forward record without enumerating the entire client population.
ResolutionCorrect the reverse zone/delegation and secure DHCP update identity, then renew one controlled lease and verify matching A/PTR lifecycle.
Scavenging does not remove known stale dynamic records.
Likely causeAging is missing at the record, zone, or server level; timestamps are zero; the safety start time has not elapsed; or the selected scavenging server has not replicated.
Inspect zone aging, server scavenging, record timestamps, next cycle, DNS audit events, and replication health.Calculate the no-refresh plus refresh plus scavenging-cycle timeline instead of repeatedly forcing deletion.
ResolutionComplete the three-level configuration on one approved scavenging server, allow the safety intervals and replication to elapse, and observe audit events before considering a manual cycle.
Scavenging deletes a still-required host or service record.
Likely causeA dynamic timestamp was assigned to an infrastructure record, intervals are shorter than its registration cadence, DHCP ownership is inconsistent, or a server stopped refreshing.
Preserve DNS audit events and record history, inspect timestamp/owner and the host registration schedule, and compare no-refresh plus refresh with lease/refresh behavior.Confirm the current service address through the authoritative system of record before recreating anything.
ResolutionRestore the record through its authoritative registration process, correct ownership/timestamp or interval design, and pause scavenging expansion until representative lifecycles pass.
dcdiag /test:dns reports delegation or dynamic-update failures.
Likely causeThe parent delegation is absent or stale, secure update registration is blocked, the _msdcs zone is inconsistent, or a controller uses the wrong resolver.
Run the focused /DnsDelegation, /DnsDynamicUpdate, /DnsRecordRegistration, and /DnsBasic tests per controller and inspect their detailed sections.Query parent/child SOA, NS, glue, and forest SRV records directly against authoritative servers.
ResolutionRepair the exact delegation, registration, or adapter dependency and rerun the same focused test. Do not dismiss a warning merely because ordinary A-record lookup works.
DNS query logging or analytics causes high CPU, disk use, or sensitive-data exposure.
Likely causeVerbose analytical logging was enabled without a bounded collection window, event forwarding is backlogged, or raw query names are retained broadly.
Measure DNS process CPU, event-log size/rate, forwarding queue, and retention, then inspect who can access query data.Compare monitoring goals with existing counters, audit events, and sampled diagnostics before collecting every query.
ResolutionDisable or narrow high-volume logging, preserve only necessary incident evidence, enforce access/retention, and prefer metrics plus targeted diagnostic windows.
A DNS server answers recursive queries from an untrusted network.
Likely causeFirewall boundaries are too broad, interfaces/listeners are exposed, or recursion policy was designed only for internal clients but not enforced.
From an authorized external test point, query an unrelated name and inspect DNS/firewall logs without performing broad scanning.Review listening interfaces, recursion policy, client subnets, and network ACLs on both servers.
ResolutionRestrict DNS service reachability and recursion to approved clients, preserve authoritative service needed by AD, and retest from trusted and untrusted paths.
A planned DNS rollback would remove an AD-integrated zone or overwrite it from a text export.
Likely causeThe team is treating directory-replicated DNS as an independent file service and has not separated configuration rollback from data recovery.
Identify the directory partition, replication health, dependent records, change scope, and most recent supported system-state backup.Compare current zone objects with the last reviewed export only as evidence, not as an automatic restore source.
ResolutionRoll back the narrow forwarder, option, or aging setting first. Recover directory-integrated data only through supported AD/DNS recovery with identity owners; never replace the live directory partition by guessed file copy.
Reference
Frequently asked questions
Why can I not list a public resolver as the third DNS server?
Clients can select any configured resolver. A public resolver cannot answer private AD SRV records, producing intermittent domain discovery and authentication failures. Internal DNS should forward approved external queries.
Should both servers scavenge?
Microsoft's troubleshooting guidance recommends selecting one server to avoid confusing behavior. The zone, records, and designated server must all be configured, and replication must be healthy.
Does a DNS zone export replace backup?
No. An AD-integrated zone is directory data with ACLs and replication context. An export can assist review, but supported AD/system-state recovery remains the recovery foundation.
Why are manually created records not scavenged?
Static records normally have a zero timestamp and are intentionally protected from aging. If they are obsolete, remove them through the authoritative change process rather than converting the entire zone into a deletion experiment.
Recovery
Rollback
Roll back the narrow server or zone property change, not the whole AD-integrated data set. Restore prior forwarders, conditional-forwarder masters, client options, or aging/server-scavenging settings from reviewed evidence. Preserve replicated zones and record ownership. Recover deleted/corrupt AD DNS data only through the supported Active Directory/DNS recovery process with current system-state backups.
- Stop the rollout and preserve zone properties, record/timestamp samples, DNS audit events, client evidence, and AD replication health.
- For forwarder or conditional-forwarder regression, restore the previous reviewed addresses/scope on one healthy server and verify replication or equivalent node configuration.
- For client resolver regression, revert the authoritative DHCP/policy configuration for the pilot scope before changing individual endpoints.
- For scavenging risk, disable only the newly enabled server/zone scavenging path, preserve events, and restore necessary records through their authoritative owner.
- Do not delete/recreate an AD-integrated zone, import a text export over live data, or remove a DNS application partition as a quick rollback.
- If directory-integrated data is corrupt or widely deleted, invoke the identity recovery plan, select a trusted backup, recover in isolation, and repeat every DNS and AD acceptance test.
Evidence