DNS and joining a client

Goal

Session 2 warned you that AD depends on DNS. This session proves it by watching DNS actually do the work. By the end you'll understand how a domain-joined client finds a domain controller through DNS SRV records, you'll join a Windows client to lab.local, log in as a domain user, and — most importantly — you'll be able to diagnose the classic "wrong DNS server" failure by causing it on purpose and fixing it. You already know DNS as a technology; the new part here is how AD uses DNS. Still Tier 1: you're wiring the first client into the domain, not designing multi-site name resolution.

Concepts

Closing the loop from Session 2

You've heard "AD needs DNS" since Session 2, where promoting DC01 stood up an AD-integrated zone for lab.local. That was the warning. Here's the mechanism: a client doesn't have the DC's address memorized and doesn't broadcast for it — it asks DNS where the domain's services live. Everything a member does — joining, logging on, applying policy — begins with a DNS lookup. Get that lookup right and the domain "just works"; get it wrong and nothing does.

SRV records: how AD advertises its services

When DC01 was promoted, it registered a set of SRV (service locator) records into the lab.local zone. Unlike an A record (name → address), an SRV record answers "which host provides service X, and on what port?" AD publishes these under two branches of the zone:

• _msdcs — Microsoft-specific locator records, including domain-controller and Global-Catalog entries.
• _tcp (and _udp) — the standard service entries such as LDAP and Kerberos.

The two you'll care about most:

• _ldap._tcp.dc._msdcs.lab.local — "here is a domain controller for lab.local, reachable via LDAP." This is the record the DC Locator leans on to find a DC specifically (not just any LDAP server).
• _kerberos._tcp.lab.local — "here is the Kerberos KDC," so the client knows where to authenticate.

Each SRV record points at a host name (e.g. dc01.lab.local) and a port (389 for LDAP, 88 for Kerberos). The host name still has to be resolved to an address by an ordinary A record — so a working join needs both the SRV records and the DC's A record.

The DC Locator flow

Put it together and the sequence at logon or join is short and strict:

The chain has a single point of failure at the top: if the client can't resolve those SRV records, it never learns a DC's name, never gets an address, and the join or logon fails before any authentication is even attempted. No DNS resolution → no DC found → no logon.

The critical point: the client's DNS server must be the DC

Here's where real deployments break. A domain member's preferred DNS server must be the DC (or another DNS server that hosts or forwards the lab.local zone) — not a public resolver like 8.8.8.8. The reason is simple: public DNS knows how to resolve microsoft.com, but it has never heard of lab.local and holds none of its SRV records. A client pointed at 8.8.8.8 will happily browse the web and still be unable to find the domain, because the one zone it needs isn't there.

Dynamic DNS registration

Registration isn't a one-way street from the DC. When a Windows machine joins the domain, it uses dynamic DNS update to register its own A record into the zone — so after the join, the client shows up by name in the lab.local zone in DNS Manager without you typing anything. Domain members keep these records refreshed automatically. Seeing your client appear in the zone is direct confirmation the join and dynamic registration both worked.

Lab

Goal: stand up a second VM — a Windows client — point it at DC01 for DNS, join it to lab.local, log in as a domain user, then inspect the DNS records that made it all work and prove the failure mode by breaking DNS on purpose. This is the first time two VMs share the lab; keep them on the same virtual network so they can reach each other. Fake values only — lab.local, DC01, the Session 3 users, no real credentials.

The join itself is done in the GUI: System Properties (sysdm.cpl) → Computer Name tab → Change → Member of: Domain → type lab.local. DNS inspection is in DNS Manager (dnsmgmt.msc) on DC01. Read-only checks like nslookup lab.local, nltest /dsgetdc:lab.local, and ipconfig /all are handy for confirming resolution before you commit to the join.

How you know it worked: the client joins without error and reboots; you log in as a domain user (e.g. LAB\jsmith) — proving end-to-end DNS → locator → Kerberos logon; on DC01, DNS Manager shows the client's freshly registered A record in the lab.local zone plus the DC's _msdcs / _tcp SRV records; ADUC shows the client's new computer object in the Computers container; and when you point the client at 8.8.8.8 you watch domain logon/DC location fail while the web still loads, then recover the moment you restore DC01 as preferred DNS. If you can explain why the public-DNS client failed, you understand the pillar.

Add-Computer -DomainName "lab.local" -Credential (Get-Credential) -Restart
Resolve-DnsName -Type SRV _ldap._tcp.dc._msdcs.lab.local