Any discussion of DNS and Active Directory must come quickly to a discussion of the AD “signposts” known as the SRV (service locator) records. SRV is just another resource record type, like A and PTR and MX. It is defined in the RFC 2782 document, which states that “The SRV RR allows administrators to use several servers for a single domain, to move services from host to host with little fuss, and to designate some hosts as primary servers for a service and others as backups.” Microsoft decided to use SRV records as a key part of the procedure whereby a client finds a domain controller. So where do these records come from? They are registered with DNS by the NetLogon service of a domain controller when it starts. There are actually quite a few of these records, but for right now let’s just look at two of them, the ones that have to do with domain controllers. They are in the following formats: _ldap._tcp.dc._msdcs.dnsdomainname _ldap._tcp.sitename._sites.dc._msdcs.dnsdomainname So a workstation that belongs to a particular domain can send a DNS lookup query for a record of the first format listed above. (The workstation knows what domain it’s in, and it also knows where its preferred DNS server is.) Of course, the problem with this scheme is that the domain controller address returned by DNS might or might not be in the same site as the querying workstation. And that’s where the second format listed above comes into play. After talking to a DC in a different site, that DC will reply to the workstation with the name of the site that that workstation is in. Now that the workstation knows its site location in AD, the client will use the second listed format to make another query to DNS, but this time specifying the site name in addition to the domain name. In this way, the workstation learns of a DC that’s nearby as opposed to one that might be on the other side of the planet.
SRV Records and Active Directory
How Windows Clients Find Domain Controllers
Copyright © 2009 IDG Communications, Inc.