Domain Controller Not Advertising — Missing SRV Records

Introduction

A branch-site domain controller gets rebuilt over a maintenance window. The promotion finishes cleanly, replication looks healthy in repadmin, and the server shows up in Active Directory Sites and Services under the right site. Two days later, users at that site are authenticating across a slow WAN link against a DC in the hub site instead, Group Policy processing is slower than it should be, and nobody can explain why the new local DC is never picked.

This is what it looks like when a domain controller stops advertising itself. It is not down, and it is not unreachable on the network. It is simply invisible to the DC Locator process, because the DNS records that say “a domain controller lives here” were never registered, or were registered once and then quietly deregistered.

What The Error Looks Like

Running dcdiag /test:dns against the affected DC produces a summary table with the record-registration column failing:

Summary of DNS test results:

                          Auth Basc Forw Del  Dyn  RReg Ext
   _______________________________________________________
   Domain: adatum.com
      BR-DC02              PASS PASS PASS PASS PASS FAIL n/a

   ......................... adatum.com failed test DNS

RReg is the record-registration subtest. When it fails, dcdiag typically prints a line naming the specific lookup that could not be satisfied, similar to:

If the Active Directory Domain Services Best Practices Analyzer has been run against the box, it surfaces the same underlying problem in plainer language:

On the affected DC itself, the System event log usually has matching Netlogon entries from around the same time, most often event ID 5774 (a dynamic DNS update failed), 5781 (“Dynamic registration or deregistration of one or more DNS records failed because no DNS servers are available”), or 5782 (“No DNS servers configured for the local system”). Any of these three is the server-side half of the same symptom: Netlogon tried to publish records and could not.

What It Actually Means

Think of an SRV record as a company directory entry for a job title, not a person’s name. It does not say “server BR-DC02, room 4”; it says “whoever is handling LDAP for this site right now, here’s how to reach them.” A workstation looking for a domain controller doesn’t ask for a specific server by name — it asks DNS who currently holds that role, and the SRV record is the only place that answer lives.

A hostname-to-IP (A) record only answers “where is this specific server.” An SRV record answers a different question: “which servers, anywhere in this domain or this site, provide the LDAP, Kerberos, or global catalog service.” Clients, member servers, and other domain controllers use SRV records almost exclusively to find a DC to talk to — they very rarely look up a domain controller by name.

Netlogon is the service responsible for publishing those SRV records on behalf of the DC, on startup and again roughly every 24 hours, alongside on-demand refreshes. When Netlogon cannot reach a DNS server, does not have permission to update the zone, or has been explicitly told not to register a record, the DC keeps functioning internally — replication, authentication for anyone who already has its address, the directory database itself — but it drops out of DNS-based discovery entirely. Every client and every other DC that relies on the SRV lookup to find a DC in that site will simply never be offered this one.

How To Diagnose

Work from cheapest and most direct to deepest. Each step below either confirms the record is missing or tells you why registration failed.

# Query DNS directly for the DC's LDAP SRV record (the same lookup every client makes)
nslookup -type=SRV _ldap._tcp.dc._msdcs.adatum.com

# Ask DC Locator to find a DC, bypassing any cached result
nltest /dsgetdc:adatum.com /force

# Run the full DNS record-registration subtest against the specific DC
dcdiag /test:dns /v /s:BR-DC02 /DnsRecordRegistration

# Confirm Netlogon and DNS Client are both running on the DC
sc query netlogon
sc query dnscache

# Check the local copy of what Netlogon believes it registered
notepad %systemroot%\System32\Config\netlogon.dns

If the nslookup query returns no SRV answer, and dcdiag /DnsRecordRegistration reports RReg FAIL against that DC, the record genuinely is not in the zone — this is a registration failure, not a client-side caching or forwarder issue. If Netlogon is stopped, or the server has no DNS server configured at all (the classic case for a DC pointing only at itself before its own DNS service has started), that will usually be the first thing the checks above surface.

Common Causes

The Fix

Start with the DC’s own network configuration, since a bad DNS server entry is behind most cases of this: run ipconfig /all and confirm every DNS server listed is reachable and actually authoritative for (or a valid recursive path to) the Active Directory-integrated zone.

Next, rule out an explicit block. Check HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters\DnsAvoidRegisterRecords on the DC, and run Group Policy Results against it to see whether the DC Locator DNS records not registered by the DCs policy is scoped to this server. If DcByGuid, Ldap, or any of the other DC Locator mnemonics show up there and shouldn’t, remove them from whichever source is setting them.

# Force full re-registration once the underlying cause is fixed
ipconfig /flushdns
ipconfig /registerdns
nltest /dsregdns

# Confirm the DC-specific SRV records are back
dcdiag /test:dns /v /s:BR-DC02 /DnsRecordRegistration
nslookup -type=SRV _ldap._tcp.dc._msdcs.adatum.com

If registration still fails after the network path and the avoid-list are both clean, check the zone itself: Dynamic updates must be set to Secure only on a zone that is Active Directory-integrated (a zone with dynamic updates set to None will silently reject every attempt, and a non-AD-integrated zone can’t accept secure updates at all). Running dcdiag /test:dns /v /s:<DCName> /DnsDynamicUpdate proves this end to end: it registers a harmless test record and removes it automatically, so a pass here means the update path itself is sound.

How To Prevent It

Run dcdiag /test:dns /DnsRecordRegistration against every domain controller on a schedule, not just when something is already broken — a Group Policy or registry change to DnsAvoidRegisterRecords made for one DC can drift onto others through inherited GPOs long before anyone notices the discovery problem it causes.

Treat a DC’s own DNS client settings as part of its build checklist: it should point at a DNS server that will actually be up and answering by the time Netlogon starts, which usually means a partner DC first and the local DNS service second, not the other way around. And document any deliberate use of DC Locator DNS records not registered by the DCs — it is a legitimate way to stop a branch DC from being offered outside its site, but only if every administrator touching that GPO knows it’s intentional, because it looks identical to a registration failure from every diagnostic in this post.

Final Thoughts

A domain controller that will not advertise itself is easy to miss because everything it does internally still works — replication, the database, its own logons. The failure is entirely external: nothing outside that server can find it through DNS, so traffic routes around it as if it did not exist.

The fix is almost always one of a short list: Netlogon isn’t running, the DC can’t reach its DNS server, something told it not to register, or the zone won’t accept the update. dcdiag /test:dns /DnsRecordRegistration and a plain nslookup for the SRV record narrow it down in minutes, well before anything more invasive needs to be considered.