Domain Controllers and Directory DNS

A domain controller, sometimes abbreviated as Domain Controller or DC in runbooks, is an identity authority for a directory domain. In Microsoft Active Directory Domain Services (AD DS), domain controllers authenticate users and computers, issue Kerberos tickets through the Key Distribution Center (KDC), serve LDAP directory data, replicate directory partitions, and apply domain policy.

The operational surprise is how much of AD DS depends on DNS. Clients do not usually know a domain controller by a hard-coded IP. They ask DNS for SRV records that advertise LDAP, Kerberos, Global Catalog, and site-specific domain controller locations.

What Domain Controllers Provide

Domain controllers are not just “Windows DNS servers.” DNS may run on the same hosts, and AD-integrated zones are common, but the DC role is about identity, authentication, directory state, and replication.

DNS-Based Discovery

Windows DC locator uses DNS-based discovery for modern AD domains. A client asks for SRV records, receives candidate domain controllers, then contacts candidates using LDAP-style discovery and normal authentication protocols. Microsoft recommends DNS-based discovery over legacy NetBIOS-based discovery; Windows Server 2025 blocks NetBIOS-style DC location by default unless policy explicitly allows it.

Records operators should recognize:

The _msdcs namespace is special because it carries Microsoft directory service locator records. If _msdcs delegation, replication, or dynamic registration is wrong, domain join, logon, Group Policy, and application LDAP discovery can fail even while ordinary A records resolve.

Ports and Protocols

Firewalls around domain controllers need more than TCP 443. Common flows include:

This is why “DNS works but domain join fails” is common. The SRV records can resolve, but Kerberos, LDAP, SMB, or RPC may still be blocked.

Time and Kerberos

Kerberos is time-sensitive. If a client, domain controller, or virtualization host drifts too far, authentication can fail with misleading credential or trust errors. In AD DS, the PDC Emulator FSMO role in the forest root is usually the top internal time authority, and other domain members follow the domain time hierarchy.

Treat time sync as identity infrastructure:

• monitor NTP or Windows Time status,
• avoid conflicting hypervisor and guest time settings,
• check clock skew before resetting passwords or rejoining machines,
• remember that TLS, Kerberos, certificates, and logs all depend on sane time.

Replication, Sites, and Roles

Multiple domain controllers improve availability only when replication and client location are healthy.

DNS discovery and sites are linked. If subnet-to-site mapping is missing, clients may authenticate against distant DCs or Global Catalog servers, causing slow logons and fragile application behavior.

Dynamic DNS and DHCP

Domain-joined machines and domain controllers commonly use secure dynamic updates to keep A, PTR, and SRV records current. DHCP can also register records for clients, depending on policy.

Watch for these failure patterns:

• stale A/PTR records after rebuilds or IP reuse,
• duplicate names from cloned machines,
• DHCP registering records with the wrong credentials,
• non-Microsoft DNS zones that allow SRV records but not secure dynamic update behavior,
• scavenging settings that remove live records or retain dead ones too long.

Failure Modes

Commands

dig _ldap._tcp.dc._msdcs.example.com SRV
dig _kerberos._tcp.example.com SRV
dig example.com SOA
nslookup -type=SRV _ldap._tcp.dc._msdcs.example.com
nltest /dsgetdc:example.com
dcdiag /test:dns

More checks for Windows and mixed environments:

dcdiag /test:dns /v
repadmin /replsummary
repadmin /showrepl
nltest /dsgetsite
w32tm /query /status
realm discover example.com
kinit user@example.com
ldapsearch -H ldap://dc01.example.com -b dc=example,dc=com

Troubleshooting Flow

1. Confirm the client is using domain DNS resolvers, not a public resolver.
2. Query _ldap._tcp.dc._msdcs.<domain> and _kerberos._tcp.<domain> from the affected client network.
3. Confirm returned DC names have A/AAAA records and are reachable on DNS, Kerberos, LDAP, SMB, and RPC paths.
4. Check client site mapping so the client prefers a local DC or Global Catalog.
5. Check clock skew before treating errors as bad passwords.
6. Check DC health and replication with dcdiag and repadmin.
7. Check stale DNS records, duplicate machine names, and secure dynamic update failures.

Study Cards

References

• Microsoft Learn: Locating Active Directory Domain Controllers
• Microsoft Learn: Verify SRV DNS records for Active Directory
• Microsoft Learn: Service overview and network port requirements
• Microsoft Learn: Windows Time service
• Microsoft Learn: FSMO roles
• Microsoft Learn: Active Directory Domain Services overview