DNS partitions and record registration

Identify the authoritative data path

Write down the DNS server you’re querying, zone name, zone type, directory partition and record owner name. Two DNS consoles can look much the same while showing zones with different storage or replication scope.

A GC does not automatically receive DNS application partitions as partial replicas. AD-integrated DNS avoids primary/secondary transfers between its AD replicas, but it can still serve zone transfers to configured secondary servers. Disabling AXFR does not stop AD replication. Microsoft’s zone-type guide explains these storage and transfer distinctions.

Get-DnsServerZone -ComputerName 'DC1.contoso.com' |
    Select-Object ZoneName,ZoneType,IsDsIntegrated,ReplicationScope,
        DirectoryPartitionName,DynamicUpdate
Get-DnsServerDirectoryPartition -ComputerName 'DC1.contoso.com'

You’ll need the DNS management tools, access to the server and permission to query it. Compare its hosted zones with the DC’s actual NC list and replication health. A zone may be missing because of its intended scope, an unenlisted server, a loading failure or failed replication.

Duplicate zone copies can hide each other

Event 4515 indicates duplicate zone data in AD. A common shape is one copy under CN=MicrosoftDNS,CN=System,<domain DN> and another under a DNS application partition. A console showing one loaded zone is insufficient to rule out another stored copy. The current DNS event guidance identifies 4515 separately from zone-loading and initialization failures.

From an AD administrative session, inspect the usual containers on an explicit replica:

$dc = 'DC1.contoso.com'
$root = Get-ADRootDSE -Server $dc
$domain = $root.defaultNamingContext
$forestRoot = $root.rootDomainNamingContext
$containers = @(
    "CN=MicrosoftDNS,CN=System,$domain"
    "CN=MicrosoftDNS,DC=DomainDnsZones,$domain"
    "CN=MicrosoftDNS,DC=ForestDnsZones,$forestRoot"
)
foreach ($base in $containers) {
    try {
        Get-ADObject -Server $dc -SearchBase $base -SearchScope OneLevel `
            -LDAPFilter '(&(objectClass=dnsZone)(name=contoso.com))' `
            -Properties whenChanged -ErrorAction Stop |
            Select-Object DistinguishedName,ObjectGUID,whenChanged
    } catch {
        [pscustomobject]@{SearchBase=$base;QueryError=$_.Exception.Message}
    }
}

Add any custom partitions to the check. An error might mean this DC doesn’t host the partition, the container is absent, access was denied or the management path failed. Keep that separate from a successful search with no results. The AD-integrated DNS model defines the usual scopes.

Before changing scope or deleting a copy, compare its records, permissions, replication metadata and the location named in the event on the actual DNS servers. Save both copies and work out which data you need. Removing the loaded copy can expose old data from the other copy at the next load. Deleting a zone deletes replicated data; it isn’t just tidying the console. Don’t base recovery on a guessed load order.

SOA serials do not measure AD convergence

A secondary’s SOA refresh/retry/expiry values govern its transfer behavior. An AD-integrated DNS server instead receives directory updates through the NC replication topology. Comparing its SOA serial with another writable DNS server does not prove that their underlying AD data is synchronized. Compare the disputed record directly, its AD metadata where needed, and the relevant application-NC relationships. Microsoft documents the independent serial-number behavior of AD-integrated zones, including the implications for a secondary transferring from different masters.

For a stub zone, the configured masters supply updates; the NS records identify the zone’s authorities. A stale or unreachable master can break updates even while the NS records point at working servers. Stub maintenance can involve zone-transfer behavior—the Windows DNS protocol includes stub transfer counters and failures. Check the actual requests, responses and configured masters.

A DC has several record-registration paths

Netlogon maintains DC Locator SRV records and other DC-specific registrations. The DNS client maintains host-address registrations, and DHCP can register on a client’s behalf. DNS Server also maintains authority-related information. A missing SRV record and a stale multihomed A record therefore need different registrar checks.

On the affected DC, compare netlogon.dns, effective policy, actual interfaces and authoritative answers. Read both policy and local Netlogon configuration:

$paths = @(
    'HKLM:\SOFTWARE\Policies\Microsoft\Netlogon\Parameters'
    'HKLM:\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters'
)
foreach ($path in $paths) {
    Get-ItemProperty -LiteralPath $path -ErrorAction SilentlyContinue |
        Select-Object PSPath,UseDynamicDns,DnsAvoidRegisterRecords,
            DnsRefreshInterval,AutoSiteCoverage,SiteCoverage,GcSiteCoverage,
            LdapSrvPriority,LdapSrvWeight
}

Run this locally or query the intended DC’s registry through your management tools. An absent value uses its documented default, and policy can override local configuration. The DNS registration settings specification defines precedence and record mnemonics. Check policy before repeatedly trying registration commands.

Generic and site-specific records serve different workloads

Automatic site coverage can register a DC for a site that lacks the required role. A site-specific SRV answer pointing outside the physical site can therefore be intentional. Examine coverage policy, domain/GC requirements, site-link costs and the actual DC Locator result.

Large branch designs sometimes suppress selected site-less records to keep generic discovery from loading remote DCs, while retaining suitable site registrations. A missing generic registration is then different from a failed update. Microsoft’s location-optimization guidance lists the supported mnemonics. Do not suppress records across all DCs without ensuring an eligible discovery path remains.

For SRV selection, a lower numeric priority is preferred; weight distributes selection among equal-priority candidates. Neither proves that every application uses the same selection/caching algorithm. RFC 2782 defines SRV semantics. Reordering A records with round robin is a different mechanism, and a client’s address-selection rules can reorder the returned addresses again.

Registration ownership can explain later scavenging

A record can resolve correctly while its intended registrar lacks permission to refresh it. Check the update identity, DHCP DNS credentials and record ACL, then verify an update on the authoritative server. A DHCP failover or replacement using different credentials can expose this mismatch. Dynamic-update guidance explains ownership; avoid fixing one record by opening write access across the zone.

AD DNS data also has a DNS-specific tombstone state. dNSTombstoned=true is not interchangeable with the directory object’s isDeleted=true. Do not use an AD Recycle Bin search as a complete DNS deletion history or assume a stale DNS-node object is still served. Follow DNS aging/scavenging and the dNSTombstoned definition for the relevant layer.

4013 can expose a startup dependency loop

An AD-integrated DNS server can wait for AD initial synchronization before loading its zones, while AD needs DNS to resolve a replication source. Self-only DNS, simultaneous restarts of mutually dependent servers, unreachable alternates or stale partner metadata can prolong startup. Event 4013 records the initialization wait; it does not by itself prove zone corruption. Microsoft’s 4013 procedure distinguishes this from FSMO initialization.

Check whether an available configured resolver can answer the source GUID CNAME and its target A/AAAA records during startup. Get that lookup working, correct stale metadata through supported DC-removal procedures, and stagger dependent server restarts. Permanently bypassing initial synchronization removes a safeguard without fixing the dependency.