AD Integrated DNS Replication Scope Guide

AD Integrated DNS Replication Scope Guide

Choosing AD Replication Scope for DNS Zones

Choosing the right AD integrated DNS replication scope eliminates the classic zone transfer topology and allows multi-master updates, but it doesn't mean "replicates everywhere." The choice between Domain, Forest, All Domain Controllers in this Domain, or a Custom application partition determines which servers receive DNS objects and by what route.

[!TIP]
The scope should answer who needs to serve or update the zone, not the generic desire for "more copies." A copy on a DC that doesn't run DNS doesn't improve resolution.

Why This Matters

The replication scope you choose directly impacts which DNS servers can answer queries for the zone, how much AD replication traffic you generate, and how resilient you are to site failures. Pick too narrow and clients in other domains can't resolve the zone. Pick too broad and you're replicating DNS data to DCs that don't need it, adding latency and traffic.

What Changes When You AD-Integrate a Zone

A file-based zone has one writable primary and read-only secondaries. An AD-integrated zone is stored as AD DS objects on domain controllers that also run DNS. Directory replication transports its changes and multiple servers can accept writes. This eliminates designing AXFR/IXFR between those DNS servers but inherits AD sites, links, latency, permissions, and failures.

Microsoft documents two common DNS application partitions: DomainDnsZones for the domain and ForestDnsZones for the forest. The legacy "All domain controllers in this domain" option uses the general domain partition and exists for compatibility. A custom application partition can limit replication to explicitly enrolled servers.

Choosing Your AD Integrated DNS Replication Scope

Scope Use When Risk to Review
Domain Only one domain's DNS servers need the zone DNS in other domains will depend on delegation or forwarding
Forest DNS servers across multiple forest domains must host it directly More replicas and administrative exposure of the zone
Legacy A proven compatibility dependency exists Replicates to domain DCs even if they don't run DNS
Custom A stable subset of DNS servers should receive it Member enrollment and lifecycle become additional operational responsibility

The AD domain zone usually fits Domain scope; _msdcs.<forest> needs Forest scope for forest-wide location. A shared application zone may justify Forest, but delegation or forwarding may be cleaner if domains only need to resolve it, not host it.

Step-by-Step: Inventory and Change

Step 1 — Inventory Before You Touch Anything

Get-DnsServerZone | Sort-Object ZoneName |
  Select-Object ZoneName, ZoneType, IsDsIntegrated, ReplicationScope, DynamicUpdate

Get-ADRootDSE | Select-Object defaultNamingContext, rootDomainNamingContext
repadmin /replsummary
dcdiag /test:dns /e /v

Run inventory on more than one DNS and compare. A different value may mean it's querying a different zone with the same name or that replication is broken. Don't change scope to "fix" a DC that isn't receiving objects without first reviewing partition membership and AD health.

Document clients, updaters, authoritative servers, sites, and latency tolerance. Check permissions on the zone and whether it accepts secure updates. A scope change doesn't fix incorrect record owners or ACLs.

Step 2 — Create or Change With a Controlled Window

For a new zone:

$zone = 'app.example.contoso.com'
if (-not (Get-DnsServerZone -Name $zone -ErrorAction SilentlyContinue)) {
  Add-DnsServerPrimaryZone -Name $zone -ReplicationScope Domain `
    -DynamicUpdate Secure -PassThru
}
Get-DnsServerZone -Name $zone |
  Select-Object ZoneName, IsDsIntegrated, ReplicationScope, DynamicUpdate

For an existing zone, use the corresponding configuration cmdlet and consult its syntax on the installed version — don't copy parameters between a file-based and an integrated zone. Take inventory of records and ACLs, confirm AD replicates without errors, make a single change, and wait for site-predicted convergence.

Step 3 — Verify Convergence

The verification must query SOA and a known record against each DNS that should host the zone, and confirm that a DNS outside the scope doesn't load it directly. Create a test record only in an authorized namespace, resolve it from another site, and remove it when done. Pair the DNS test with repadmin /showrepl for the appropriate partition.

Common Pitfalls

  • DC shows an old version? AD replication error or latency, not DNS transfer. Check neighbors, sites, and partition with repadmin — don't blindly restart DNS.
  • Zone doesn't appear in another domain? Domain scope correctly chosen or by mistake. Decide if it should be hosted; use Forest only if that's the requirement, or configure delegation/forwarding.
  • Scope change fails? Partition unavailable, DNS not enrolled, or replication damaged. Fix AD health and gather diagnostics — don't delete and recreate the zone.
  • Records created but other servers don't see them? Local write accepted and replication pending/failed. Identify source DC, object, and partition; compare metadata and replication state.
  • Updates return access denied? Record ownership/ACL, not scope. Inspect who created the record and permissions; fix the update model.

Alternative Open-Source Options

  • BIND with TSIG — zone transfers with transaction signatures for multi-server authoritative DNS. Not AD-integrated but solid for mixed environments.
  • PowerShell DSC — for declarative, idempotent DNS zone configuration across a fleet. Can enforce replication scope as part of desired state.
  • nsd with xferd — zone transfer daemon for distributing zones across servers without AD dependency.

Conclusion

The best scope is the smallest one that satisfies availability and authority without creating a fragile dependency. That answer changes between the domain zone, _msdcs, and a shared application. Documentation of scope and a per-server test are worth more than a default selection.

Try It

Run Get-DnsServerZone | Select-Object ZoneName, ReplicationScope on your DNS servers. Check if the scopes match what you'd expect — you might find zones replicated to DCs that don't even run DNS, or zones that should be forest-wide but are stuck at domain scope.

Related Posts

Comments

Post a Comment

Popular posts from this blog

Forwarders vs Root Hints DNS: Choosing Resolution

Image
Forwarders vs. Root Hints: Choosing How to Resolve External DNS An internal DNS server can resolve external names by sending queries to designated resolvers or by walking the public hierarchy from root servers. Both paths work, but they have different consequences for filtering, privacy, traceability, firewall rules, and dependency. The common mistake is configuring forwarders and forgetting that root hints can serve as a fallback. [!TIP] The external path should be a visible decision, not the residual of defaults. Design failure as carefully as success and keep internal authority separate. Why This Matters for Forwarders vs Root Hints DNS How your DNS resolves external names determines what your upstream provider sees, how filtering policies are enforced, and what happens when things break. Forwarders give you centralized control but create dependency. Root hints give you independence but require broader egress and more operational overhead. Neither is universally "better...
Read more

Configure Secure Dynamic DNS Updates on Windows Server

Image
Configure Secure Dynamic DNS Updates on Windows Server Dynamic updates save you from manually creating every A and PTR record, but they turn DNS into a writable database for machines and services. The "secure only" option isn't a magic checkbox — it works with AD-integrated zones, authentication, and ACLs, and the initial owner of a record determines who can modify or delete it later. [!TIP] Secure dynamic updates protect writes, not queries. Start by understanding who owns each record before flipping the switch. Why This Matters Every time you rely on DNS automation, you're trusting something to create and maintain records on your behalf. If that trust is misconfigured — or if multiple services compete for the same record — you get orphaned entries, stale IPs, and names that point nowhere. Getting this right means your DNS stays clean and your services stay discoverable. What You Need AD-integrated zones with healthy replication Clients configured to use ...
Read more