Chad DuffeySecurity engineer

Active Directory Replication and topology

DNS and DC Locator

Separate host lookup, service discovery, site selection, and the DNS configuration on the machine doing the lookup.

Start with the resolver the client actually uses

A DC running DNS still uses its network-interface DNS client settings for its own lookups. Check those settings; it won’t necessarily ask its local DNS service.

Get-DnsClientServerAddress |
    Select-Object InterfaceAlias, AddressFamily, ServerAddresses
Get-DnsClient | Select-Object InterfaceAlias, ConnectionSpecificSuffix,
    RegisterThisConnectionsAddress

Use DNS resolvers that can resolve the AD zones. Public DNS addresses in a domain client’s adapter configuration can produce intermittent failures; external resolution belongs behind the internal DNS service’s forwarding or recursion design. Microsoft’s DNS client configuration guidance covers DC and member configurations.

Host resolution is not service discovery

An A or AAAA answer for DC1.contoso.com proves a host record exists. DC Locator also needs service information and a reachable suitable DC.

Resolve-DnsName 'DC1.contoso.com' -Server '192.0.2.10'
Resolve-DnsName '_ldap._tcp.dc._msdcs.contoso.com' `
    -Type SRV -Server '192.0.2.10'
Resolve-DnsName '_ldap._tcp.Sydney._sites.dc._msdcs.contoso.com' `
    -Type SRV -Server '192.0.2.10'

Replace the example addresses with your resolver. Query each relevant authoritative DNS server directly when comparing answers. Recursive and client caches can still hold a stale answer after the AD-integrated zone has converged.

Observe locator results on the affected machine

nltest /dsgetsite
nltest /dsgetdc:contoso.com

DC Locator combines DNS discovery, DC responses, requested capabilities, site information, and caching. Pinging the domain name or reading %LOGONSERVER% doesn’t exercise that process. Different callers can ask for different kinds of DC.

Changes the local discovery cache: to request fresh discovery during a controlled reproduction:

nltest /dsgetdc:contoso.com /force

Save the existing result first. Microsoft’s DC Locator documentation also covers the Windows Server 2025 change that blocks NetBIOS-style discovery by default. Use DNS names and DNS-based discovery in applications.

Check DC registration

On a DC, %systemroot%\System32\Config\netlogon.dns lists records Netlogon expects to register. Compare those names with DNS and with the DC’s actual host records. Netlogon registers DC service-location records; other registration paths also exist, so inspect the particular missing record before choosing a remedy.

dcdiag /s:DC1 /test:DNS /DnsBasic /v
dcdiag /s:DC1 /test:DNS /DnsRecordRegistration /v

Writes a temporary test record: /DnsDynamicUpdate tests dynamic updates and is not a purely read-only DNS query. Label it accordingly in collection procedures. The DCDiag reference describes these test scopes.

Secure updates can fail because of ownership

A record can resolve correctly even when its client can’t update it. DHCP may have registered it under a different owner from the computer. Check DHCP’s DNS credentials/configuration, the record’s security descriptor, and the identity sending the update. Opening write access across the zone isn’t a good fix for an ownership mismatch. See DNS dynamic updates.

Disjoint namespaces need two names in your notes

A computer’s primary DNS suffix can differ from its AD domain DNS name. Its host records may live in one zone and service discovery records in another. Write down both names, and check application assumptions, certificate names, and cross-forest suffix routing before changing them. Microsoft’s disjoint namespace guide describes the constraints.

Follow discovery through the LDAP ping

An SRV response gives DC Locator some candidates. Netlogon then sends a UDP LDAP ping to check their availability and capabilities; the response includes site information used to refine the choice. A firewall can allow TCP 389 but block UDP 389 and break this stage. Trace DNS, UDP discovery, and the later connection separately. Microsoft’s locator sequence describes those stages.

Check the caller’s requirements with separate requests, rather than assuming every use of the domain name asks the same question:

nltest /dsgetdc:contoso.com /writable
nltest /dsgetdc:contoso.com /gc

The first requires a writable DC. The second requests a GC, whose placement and forest view differ from an ordinary domain DC. Preserve cached behavior first; add /force only when testing rediscovery deliberately. The Nltest reference documents these capabilities.

Distinguish the replication alias from client SRV records

For a source DC involved in replication, obtain its NTDS Settings object GUID from repadmin /showrepl. Then inspect its forest-wide alias:

Resolve-DnsName 'SOURCE-DSA-GUID._msdcs.contoso.com' -Type CNAME `
    -Server '192.0.2.10'

Resolve the returned target’s A and AAAA records too. A correct alias pointing at a host with a stale address still sends traffic to the wrong place. This is a different question from whether _ldap._tcp.dc._msdcs.contoso.com lists the server. Replication error 8524 explains the GUID-based dependency.

Compare the hosted zone and its scope

With the DnsServer module and DNS administration access:

Get-DnsServerZone -ComputerName 'DC1.contoso.com' -Name 'contoso.com' |
    Format-List ZoneName, ZoneType, IsDsIntegrated,
        ReplicationScope, DirectoryPartitionName, DynamicUpdate
Get-DnsServerResourceRecord -ComputerName 'DC1.contoso.com' `
    -ZoneName 'contoso.com' -Name 'DC2' |
    Select-Object HostName, RecordType, Timestamp, RecordData

Compare the servers actually hosting DNS. A zone in a domain-scoped application partition won’t be on every DC in the forest. A standard secondary uses zone transfer rather than AD multimaster replication. Check the intended scope before treating a missing zone as a fault. See Get-DnsServerZone.

Match registration repair to the registrar

Registration changes DNS data. For a Windows DHCP client, ipconfig /renew follows the DHCP registration path. ipconfig /registerdns instead asks the DNS client to register directly, which can bypass DHCP’s intended ownership and affect later updates. Decide which identity should own the record before selecting the operation. The dynamic-update guide specifically describes that distinction.

Afterwards, query the authoritative server and check the record’s owner and timestamp. A completion message, cached answer or successful host lookup isn’t enough to tell you the registration worked.

← All Active Directory topics