Active Directory / Basic / Lesson 4
DNS and domain-controller discovery
Explain service discovery and locality using synthetic records, then separate name resolution from availability, authentication, and permission.
On this page
Lesson goals
- Distinguish host address records from service locator records.
- Explain the role of DNS, site information, and locator caching.
- Reason about discovery evidence without issuing DNS or network commands.
Finding a controller is more than resolving the domain name
AD DS clients and controllers use DNS to locate services. A host address record maps a server name to an address, while SRV records advertise a service, target, and port. A successful lookup of an organization’s public web name does not establish that a client can locate a suitable domain controller. Microsoft’s DC Locator also considers capabilities, site information, responses, and cached results; it is not a simplistic first-IP rule. Keep the client’s configured resolver context and requested service explicit. Windows Server 2025 discovery behavior has documented changes, so avoid treating legacy NetBIOS location as the modern default design.
Filter declared records without pretending to implement DC Locator
The complete Python model selects an explicitly declared LDAP candidate in the East site from two synthetic records. It does not perform DNS resolution, SRV priority/weight randomization, LDAP availability checks, or locator caching. The output is therefore a model candidate, not a proven reachable controller. Real selection may need fallback when no suitable local controller is available. A record’s presence is only one evidence layer: its target must resolve appropriately and the required service must be available under the actual network and security policy. No DNS request or connection is sent by the program.
records = [
{"target": "dc-a.ad.example.test", "site": "East", "service": "ldap"},
{"target": "dc-b.ad.example.test", "site": "West", "service": "ldap"},
]
candidates = [r["target"] for r in records if r["site"] == "East" and r["service"] == "ldap"]
print(candidates)
print("_ldap._tcp.dc._msdcs.ad.example.test")
['dc-a.ad.example.test']
_ldap._tcp.dc._msdcs.ad.example.test
The model lists dc-a and a documentation SRV query name as text. It never submits that name to any resolver or verifies the target.
Resolver context and registration must agree
A domain member needs DNS resolution that can answer the AD DS namespace and relevant locator records; using an unrelated public resolver as an assumed substitute can break discovery. AD-integrated zones have directory replication scope and update security to review, while non-integrated DNS has its own replication and registration design. Do not assume a stale record means a controller is healthy, or that deleting records is a safe first response. Compare intended registrations, target addresses, and the time of observations. A change in DNS configuration can affect authentication and replication even when ordinary internet browsing still works.
Record the intended query and evidence boundaries
The contextual record below captures a synthetic resolver observation plan and documentation address. It is not a DNS zone file, command, or configuration to apply. A real investigation should preserve the client’s view, the requested record type, response time, selected controller, and relevant site mapping, using only authorized collected evidence. Name resolution, connectivity, service advertisement, Kerberos, and resource access are separate steps. An intermittent issue may reflect cached discovery or different controllers rather than random password failure. Keep the failure’s scope and timing precise before recommending any operational repair.
{"domain":"ad.example.test","requested_type":"SRV","requested_name":"_ldap._tcp.dc._msdcs.ad.example.test","planned_target":"dc-a.ad.example.test","documentation_address":"192.0.2.10","state":"evidence_plan_only"}
The plan names what an authorized observation would need to distinguish. It changes no resolver, record, domain member, or service.
Prove the failing layer before changing identities
If a client cannot discover a controller, resetting its user account is not evidence-based repair. Compare a working and failing client’s already-authorized observations for resolver, site, requested domain, and selected controller. Do not run broad scans or force registration as a teaching shortcut. A local model cannot establish an actual firewall or DNS issue, and a single successful lookup cannot establish end-to-end sign-in. Record uncertainty explicitly. Later lessons combine discovery, time, authentication, replication, and policy evidence into a bounded diagnosis so a directory-wide change is not made to fix one unexplained endpoint symptom.
Common errors and fixes
Public website resolution is used as proof of AD discovery.
- Why it happens
- Host lookup and directory-service location were conflated.
- How to fix it
- Review the relevant AD locator records and client resolver context.
- Prevent it next time
- Record the exact service name and record type.
A stale SRV target is assumed reachable.
- Why it happens
- Record existence was mistaken for service availability.
- How to fix it
- Separate name, address, availability, and authentication evidence.
- Prevent it next time
- Correlate observations by time and controller.
A user password is changed for a locator failure.
- Why it happens
- The failure layer was never established.
- How to fix it
- Diagnose discovery before account changes.
- Prevent it next time
- Require a stated hypothesis for each proposed change.
Check your understanding
1. Remove the East record from the model. What does the empty output establish, and why is it not proof the real domain is unavailable?
Show worked solution
The model has no declared candidate matching its narrow East/LDAP filter. It says nothing about real DNS, remote-site fallback, cached controllers, service capabilities, or network availability. A live domain could have an appropriate fallback, and a listed candidate could still be unreachable. Keep the model result separate from authorized operational observations.
2. A failing client resolves dc-a but sign-in still fails. Name the next evidence categories without executing a command.
Show worked solution
Confirm the service and capability actually selected, relevant connectivity under the approved policy, clock context, account/session status, and authentication failure category. Then distinguish successful authentication from resource authorization. Do not infer any one cause from a single host-address result or broaden permissions as a substitute for identifying the stage.
Key takeaways
- DNS service records support controller discovery.
- A candidate is not proof of availability or permission.
- Diagnose discovery before changing accounts.