DNS, SRV records, and DC Locator: How does the client find the right DC? Sites and subnets

1. Core mechanism

The discovery chain between the Netlogon service on the client, its DsGetDcName Locator API, the DNS resolver, the locator (SRV/A) records in DNS, and the responding domain controllers. This lesson only addresses the question 'which DC does the client choose and why'; secure channel leaves the installation to 04.02, and Kerberos leaves the ticket exchange to episode 06. The replication side of the site topology is excluded from this course.

Interfaces and specifications

• DsGetDcName (NetApi32.dll): Win32 Locator API that the application on the client calls to request DC; The request goes to the local Netlogon service with RPC.
• Netlogon service: Implements DsGetDcName, queries DNS, pings LDAP UDP and caches the found DC.
• DNS SRV register: Declares DC capabilities (LDAP, Kerberos, PDC, Global Catalog) in the format _<service>._<protocol>.<DnsDomainName>.
• Site-specific SRV record: Allocates DCs in the client's own site with the format _<service>._<protocol>.<SiteName>._sites...
• LDAP UDP ping: datagram sent to candidate DCs; Verifies that DC is live and available, first responder preferred.
• Netlogon DC cache: stores the discovered DC, ensuring consistent use of DC in subsequent requests; DS_FORCE_REDISCOVERY skips this.
• netlogon.log (%SystemRoot%\debug\netlogon.log): diagnostic log that records site mismatched clients NO_CLIENT_SITE.

How does the client find DC candidates?

When a client wants to log in as BESIKTAS\birkan, it must first answer the question, “Where is a domain controller for this domain?” The component that does this is the client's own Netlogon service; the application calls DsGetDcName API and the request is forwarded to local Netlogon as RPC.

Netlogon queries SRV records by inserting the domain name into the appropriate template for DNS-based discovery. For example, for a LDAP DC the query is of the form _ldap._tcp.<DnsDomainName>. DNS replies with a list of DCs registered to this name.

SRV records identify which hosts advertise DC services; they do not establish that a host is alive or reachable. Therefore, Netlogon sends a ping (datagram) LDAP UDP to the returning candidates. The first responder, DC, is selected and the result is returned to the application via DsGetDcName.

Site and subnet data determine the 'nearest DC' decision

In large environments, a domain can have multiple DCs. The sites-and-subnets topology lets the client prefer a DC in its own location over a remote DC: each subnet is mapped to an AD site, and the DCs also publish site-specific SRV records.

The client determines which site it is on from its IP address and first targets the _<service>._<protocol>.<SiteName>._sites... records. When the SiteName parameter passed to DsGetDcName is NULL, the locator attempts to find a DC in the closest site.

Critical point: this 'nearest' decision depends entirely on the accuracy of the subnet→site mapping. If the client's IP does not fit into any defined subnet, the client remains siteless and can redirect to any DC—possibly a remote one. DC records this status as NO_CLIENT_SITE in netlogon.log.

Cache and rediscovery: balance of consistency and freshness

Netlogon caches the discovered DC. This avoids repeating the discovery process for every request and preserves a consistent AD view by reusing the same DC.

DsGetDcName behavior is controlled by Flags. For example, even when the DS_BACKGROUND_ONLY cache is older than 15 minutes, it skips refreshing the cache with a ping; DS_FORCE_REDISCOVERY completely ignores the cache and makes a fresh discovery. Microsoft recommends that DS_FORCE_REDISCOVERY be used only when it is understood that the returning DC cannot be accessed, and that the cache is normally preferred for performance and consistency.

Let's trace a single client request throughout this tutorial: WS-034 calls DsGetDcName for domain → Netlogon to DNS _ldap._tcp.<site>._sites.dc._msdcs.outreason.example asks → assigns LDAP ping to the returning candidates → the first responder DC01 is selected → the result is cached. What changes at each step is the state cache content and the selected DC ID.

State and data flow

1. The application calls DsGetDcName; The request goes to the client's local Netlogon service with RPC.
2. Assess client IP/subnet mapping to an AD site. A known site allows site-specific SRV candidates; without a mapping, broader candidates and NO_CLIENT_SITE evidence require separate examination.
3. Returns a list of candidate DCs with records DNS, SRV (and A).
4. Netlogon pings candidates LDAP UDP; reports that each appropriate DC is alive.
5. The first responder, DC, is selected and its information is returned to the application via DsGetDcName.
6. Netlogon caches the selected DC; subsequent requests use the same DC without repeating the discovery.

2. Exploitation

Broken trust assumption

The assumption being broken is that the discovery layer (DNS SRV response, LDAP ping, site data) is trustworthy and the result 'found a DC' means that connection is secure/verified. Treating discovery as authentication is the wrong model.

Technical prerequisites

• Impact on the name the client resolves or a location (local resolver, hosts file, spoofed DNS response, response to mailslot/broadcast on the same segment) that would affect the SRV response.
• Or vice versa on the defensive side: the subnet→site mapping is missing, which unintentionally directs siteless clients to the wrong DC.
• To go beyond the effect, the next step the client takes against the spoofed target (authentication, sending credential) can be exploited by that target.

Exploitation mechanism

DC Locator retrieves the data it needs to trust from the network: DNS SRV replies and LDAP ping replies. An actor that can manipulate this discovery data can direct the client to a host of its choosing. However, here it is necessary to distinguish between the mechanism and the result: *directing* the client to a host does not in itself make it give credential or trust that host. In Kerberos, the client expects authentication based on keys that the real DC knows; In the NTLM/relay scenarios, the real risk is not discovery, but the sid of the next authentication flow. So poisoning the DC Locator provides an 'entry'; The effect depends on how durable the subsequent authentication control is.

Reaching the wrong DC is different from trusting the wrong DC

Redirecting the client to a fake host does not mean that that host can authenticate the client. In Kerberos, authentication relies on secrets that KDC and the client share; A random host cannot generate a valid ticket.

The real risk is often not in the discovery itself, but in the fact that the mandatory authentication triggered after discovery (e.g. automatic NTLM) can be relay by an attacker to another service. So the defense focuses on hardening the next authentication layer (signing, channel binding, relay protection) rather than deeming discovery 'safe'.

Misconfiguration is also an attack surface

Even without an attacker, the missing subnet→site mapping redirects clients to incorrect/remote DCs. This is not a privacy violation, but it does produce latency, slow login, and diagnostic confusion; in the case study 'why this DC?' It makes the question difficult.

Kapsam and the blocking condition are important: Affecting the DC Locator is not a broad, automatic domain compromise. The impact depends on the attacker's network location, which authentication protocol is triggered, and that protocol's relay/signing protections.

3. Defense & Detection

Telemetry scope

• DC Locator itself does not generate a Security audit event; Evidence of discovery is largely found in the Netlogon diagnostics (System log and netlogon.log) on ​​the client and DC side.
• System log event 5807 from NETLOGON on the DC side is a summary counter of connections from client IPs that are not mapped to the site; the detail (which client, which IP) is on lines NO_CLIENT_SITE in %SystemRoot%\debug\netlogon.log.
• 5807 is not a threat alert, but a topology hygiene signal: it indicates a missing subnet definition. It should not be interpreted as evidence of assault per se.
• To see which client is authenticating with which DC, one looks at Kerberos/session events in DC (e.g. client IP in 4768/4769), not discovery events; This lesson leaves the details of those events to chapter 06.

Events and relevant fields

• NETLOGON / 5807 (System channel): summary of the number of connections from clients that are not mapped to the site within a certain period of time; per-client detail is in netlogon.log.
• netlogon.log / Lists which IPs do not match any site, in the format NO_CLIENT_SITE: <domain>: NO_CLIENT_SITE: <bilgisayar> <ip>.
• 5807 EventData fields are insertion strings (duration and number of connections) based on the generator message template; named should not be treated as named Security fields.

Distinguish between proof of discovery and proof of authentication

'The client could not find DC' and 'It found a DC but authentication failed' are different stages in a fault investigation. The first one is DNS/SRV/site and Netlogon cache; the second is the Kerberos/NTLM layer.

5807 and netlogon.log illuminate the site/subnet side. authentication events on the DC are examined to see which client successfully authenticated with which DC. Confusing the two sets of evidence leads to the wrong root cause.

5807 is a counter, not a charge

5807 summarizes site-free connections that exceed the threshold; It is conclusive evidence of neither an attack nor a specific client. The value is meaningful when combined with the NO_CLIENT_SITE lines in netlogon.log and the subnet inventory.

Cloud, VPN, and ad-hoc networks can be site-less by design; so turning a single 5807 into an event without the allowlist and expected IP pools produces a false positive.

Detection logic · KQL

// 5807 NETLOGON System-log uyarisidir (Security auditi degil); topoloji hijyen sinyali.
// Log Analytics 'Event' tablosu Windows System/Application loglarini tasir (MMA/AMA collector).
Event
| where TimeGenerated > ago(24h)
| where Source == "NETLOGON" and EventID == 5807
| project TimeGenerated, Computer, EventID, RenderedDescription
| summarize EventCount = count(), Ilk = min(TimeGenerated), Son = max(TimeGenerated) by Computer
| sort by EventCount desc

Query assumptions

• Event 5807 is recorded in the System channel, not the Security channel; verify that the Sentinel/SIEM pipeline collects the System log (for example, the Event table or an AMA DCR System-log entry).
• The Source value may be normalized differently by the collector instead of appearing as 'NETLOGON'; verify the mapping.
• Per-client IP addresses and computer names are in netlogon.log, not in the event; collect that file separately for a complete list.
• The query was not run against a real workspace or data set.
• EventCount counts 5807 records, not the client connections summarized in their messages. Extracting a connection total from insertion strings requires collector, language and version validation; this query does not do that.

False positives

• Temporary 5807 increase before newly added subnets are defined in Sites and Services.
• VPN/DirectAccess or IP pools that do not have site mapping by design, such as cloud clients.
• Test or lab segments and temporary DHCP ranges.

Hardening

• Map all client subnets to the correct sites in Sites and Services; Inventory NO_CLIENT_SITE IP in netlogon.log and close missing subnet definitions.
• Instead of counting the discovery as safe, harden the next layer authentication: apply protections LDAP signing/channel binding, SMB signing, and NTLM relay (in related tutorials).
• Maintain the integrity of locator records in DNS and the integrity of DNS infrastructure; Monitor scavenging and unauthorized registry changes.
• Windows In Server 2025 and later, NetBIOS-based discovery is disabled by default (BlockNetBIOSDiscovery); Inventory the dependency on the old WINS/mailslot discovery and gradually move it to DNS-based discovery, prepare a fallback plan.

Read the examples

<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
  <System>
    <Provider Name="NETLOGON" />
    <EventID>5807</EventID>
    <Channel>System</Channel>
    <Computer>DC01.outreason.example</Computer>
  </System>
  <EventData>
    <Data>24</Data>
    <Data>137</Data>
  </EventData>
</Event>

Two reality checks

Assumption: The client always goes to the nearest DC on its site.

In fact: The 'nearest' decision depends on the subnet→site mapping. If the client's IP does not fit into any defined subnet, the client remains site-free (NO_CLIENT_SITE / 5807 on DC) and may point to a remote DC; The Netlogon cache can also retain a previously selected DC.

Assumption: Finding the correct SRV record in DNS and reaching DC means the authentication will also be successful.

In fact: The SRV query and LDAP UDP ping are only discovery and liveness check. Authentication is a separate step: a reachable DC may still refuse authentication, and a random host may not generate a valid Kerberos ticket. Discovery ≠ authentication.

Sources

• Microsoft · Locating Active Directory Domain Controllers (DC Locator)
  Domain controller locator process; Discovery process (DNS-based); SRV format _<service>._<protocol>.<DnsDomainName>; LDAP UDP ping; Netlogon cache; BlockNetBIOSDiscovery
• Microsoft · Domain Controller Location
  Locator records; clients use DNS to locate domain controllers
• Microsoft · DsGetDcNameW function (dsgetdc.h)
  Syntax; SiteName parameter (NULL = closest site); Flags DS_BACKGROUND_ONLY (15-minute cache), DS_FORCE_REDISCOVERY, DS_TRY_NEXTCLOSEST_SITE; NetApi32.dll
• Microsoft · Slow/timeout LDAP, Kerberos and DC locator responses; NO_CLIENT_SITE and event 5807
  NETLOGON 5807; netlogon.log NO_CLIENT_SITE; missing subnet-to-site mapping
• IETF · RFC 2782 (DNS SRV RR)
  _Service._Proto.Name SRV record format; priority/weight/port/target