8.3 DNS as a Service Location Broker

By now you probably want to hear more about how Active Directory makes use of DNS. At the beginning of the chapter, we dropped the little nugget that when DNS is not available, Active Directory clients may fail to log in. The reason for this is that Active Directory clients use DNS as a service location broker, that is, to find the closest server that is providing a certain Active Directory service. Prior to Active Directory, Windows clients used NetBIOS and WINS to find domain controllers, but hosts running Windows 2000 and later use DNS.

Consider the case of a Windows XP Professional host at Movie U. that's been joined to the movie.edu Active Directory domain. When this system boots up, it sends a series of DNS SRV record queries to its configured name server to find the closest domain controller for the movie.edu domain.

8.3.1 The SRV Resource Record

Most of the DNS queries sent by Windows clients during the location process are for SRV (service location) records. The SRV record, introduced in RFC 2052 and updated in RFC 2782, is a general mechanism for locating services. Before we can talk in detail about exactly how a Windows client finds its domain controller using SRV records, we need to describe the SRV record itself.

Locating a service or a particular type of server within a zone is a difficult problem if you don't know which host it runs on. Some administrators have attempted to solve this problem by using service-specific aliases in their zones. For example, at Movie U. we created the alias ftp.movie.edu and pointed it to the domain name of the host that runs our FTP archive:

ftp.movie.edu.    IN    CNAME    plan9.fx.movie.edu.

This makes it easy for people to guess a domain name for our FTP archive and separates the domain name people use to access the archive from the domain name of the host on which it runs. If we were to move the archive to a different host, we could simply change the CNAME record.

Another option, for clients that understand it, is the SRV record. In addition to simply allowing a client to locate the host on which a particular service runs, SRV provides powerful features for load balancing and backup services, similar to what the MX record provides.

A unique aspect of the SRV record is the format of the domain name to which it's attached. Like the service-specific alias ftp.movie.edu, the domain name that a SRV record is attached to gives the name of the service sought along with the protocol it runs over, concatenated with a domain name. The labels representing the service name and the protocol begin with an underscore to distinguish them from labels in the domain name of a host. So, for example:

_ftp._tcp.movie.edu

represents the SRV records someone ftping to movie.edu should retrieve in order to find the movie.edu FTP servers, while:

_http._tcp.www.movie.edu

represents the SRV records someone accessing the URL http://www.movie.edu should look up in order to find the www.movie.edu web servers.

The names of the service and protocol must come from the latest Assigned Numbers RFC (the most recent as of this writing is RFC 1700) or be unique names used only locally. Don't use the port or protocol numbers, just the names. When entering SRV records through the DNS console, the service name is limited to eight common services.

The SRV record has four resource record-specific fields: priority, weight, port, and target. Priority, weight, and port are unsigned 16-bit numbers (between 0 and 65,535). Target is a domain name.

Priority works similarly to the preference in an MX record: the lower the number in the priority field, the more desirable the associated target. When searching for the hosts offering a given service, clients should try targets with the same priority value before trying those with a higher value in the priority field (lower priority values indicate higher priority—confusing, eh?).

Weight allows zone administrators to distribute load to multiple targets. Clients should query targets of the same priority in proportion to their weight. For example, if one target has a priority of zero and a weight of one and another target has a priority of zero but a weight of two, the second target should receive twice as much load (in queries, connections, etc.) as the first. It's up to the service's clients to direct that load: they typically use a system call to choose a random number. If the number is, say, in the top one-third of the range, they try the first target, and if the number is in the bottom two-thirds of the range, they try the second target.

Port specifies the port on which the service being sought is running. This allows zone administrators to run servers on nonstandard ports. For example, an administrator can use SRV records to point web browsers at a web server running on port 8000 instead of the standard HTTP port (80).

Finally, target specifies the hostname of a host on which the service is running (on the port specified in the port field). Target must be the canonical name of the host (not an alias), with address records attached to it.

So, for the movie.edu FTP server, we might add two SRV records to the movie.edu zone. Adding the first with the DNS console is shown in Figure 8-3.

Figure 8-3. Adding an SRV record with the DNS console

After adding the second record, the movie.edu zone datafile (movie.edu.dns) contains these records:

_ftp._tcp.movie.edu.  IN  SRV  1  0  21  plan9.fx.movie.edu.
                      IN  SRV  2  0  21  thing.fx.movie.edu.

This instructs SRV-capable FTP clients to try the FTP server on plan9.fx.movie.edu's port 21 first when accessing movie.edu's FTP service and then to try the FTP server on thing.fx.movie.edu's port 21 if plan9.fx.movie.edu's FTP server isn't available.

The records:

_http._tcp.www.movie.edu.  IN  SRV  0  2  80   www.movie.edu.
                           IN  SRV  0  1  80   www2.movie.edu.
                           IN  SRV  1  1  8000 postmanrings2x.movie.edu.

direct web queries for www.movie.edu (the web site) to port 80 on www.movie.edu (the host) and www2.movie.edu, with www.movie.edu getting twice the queries www2.movie.edu does. If neither is available, queries go to postmanrings2x.movie.edu on port 8000.

But don't get excited and add SRV records for your FTP and web servers: currently few clients actually use SRV records to locate their servers. In fact, we're not aware of any FTP clients or web browsers that look up SRV records. On the other hand, when Microsoft was looking for a way to have Windows-based clients find their domain controllers, SRV records fit the bill perfectly.

8.3.2 DC Locator

One of the fundamental issues for clients in any networked environment is finding the optimal server to authenticate against. The process under Windows NT was not very efficient and could cause clients to authenticate to domain controllers in the least optimal location. With Active Directory, clients use DNS to locate domain controllers via the DC locator process. To illustrate at a high level how the DC locator process works, here's an example where a client has moved from one location to another and needs to find a domain controller (DC).

Two things are needed to support the DC locator process: the site topology must be properly defined in Active Directory, and DNS must contain the necessary Active Directory SRV records, which we describe in the next section. For a more detailed description of how the DC locator process works, including the specific resource records that are used during the process, check out Microsoft Knowledge Base articles 247811 and 314861.

8.3.3 Resource Records Used by Active Directory

When you promote a domain controller into a domain, the file %SystemRoot%\System32\Config\netlogon.dns is generated. This file contains the necessary resource records for the DC to function correctly within Active Directory. The NetLogon service keeps this file updated based on site membership, GC status, and site coverage.

The contents of the file looks like the following for a DC named terminator.movie.edu in the movie.edu domain with the IP address 10.1.1.1. We've reordered the file a bit to group records of similar purpose together. Note that some lines may wrap due to their length.

movie.edu. 600 IN A 10.1.1.1
ec4caf62-31b2-4773-bcce-7b1e31c04d25._msdcs.movie.edu. 600 IN CNAME↵
terminator.movie.edu.
gc._msdcs.movie.edu. 600 IN A 10.1.1.1
_gc._tcp.movie.edu. 600 IN SRV 0 100 3268 terminator.movie.edu.
_gc._tcp.Default-First-Site-Name._sites.movie.edu. 600 IN SRV 0 100 3268↵ 
terminator.movie.edu.
_ldap._tcp.gc._msdcs.movie.edu. 600 IN SRV 0 100 3268 terminator.movie.edu.
_ldap._tcp.Default-First-Site-Name._sites.gc._msdcs.movie.edu. 600 IN SRV 0 100 3268↵ terminator.movie.edu.
_kerberos._tcp.dc._msdcs.movie.edu. 600 IN SRV 0 100 88 terminator.movie.edu.
_kerberos._tcp.Default-First-Site-Name._sites.dc._msdcs.movie.edu. 600 IN SRV 0 100↵ 88 terminator.movie.edu.
_kerberos._tcp.movie.edu. 600 IN SRV 0 100 88 terminator.movie.edu.
_kerberos._tcp.Default-First-Site-Name._sites.movie.edu. 600 IN SRV 0 100 88↵ terminator.movie.edu.
_kerberos._udp.movie.edu. 600 IN SRV 0 100 88 terminator.movie.edu.
_kpasswd._tcp.movie.edu. 600 IN SRV 0 100 464 terminator.movie.edu.
_kpasswd._udp.movie.edu. 600 IN SRV 0 100 464 terminator.movie.edu.
_ldap._tcp.movie.edu. 600 IN SRV 0 100 389 terminator.movie.edu.
_ldap._tcp.Default-First-Site-Name._sites.movie.edu. 600 IN SRV 0 100 389↵ 
terminator.movie.edu.
_ldap._tcp.pdc._msdcs.movie.edu. 600 IN SRV 0 100 389 terminator.movie.edu.
_ldap._tcp.97526bc9-adf7-4ec8-a096-0dbb34a17052.domains._msdcs.movie.edu. 600 IN SRV↵ 0 100 389 terminator.movie.edu.
_ldap._tcp.dc._msdcs.movie.edu. 600 IN SRV 0 100 389 terminator.movie.edu.
_ldap._tcp.Default-First-Site-Name._sites.dc._msdcs.movie.edu. 600 IN SRV 0 100 389↵ terminator.movie.edu.
DomainDnsZones.movie.edu. 600 IN A 10.1.1.1
_ldap._tcp.DomainDnsZones.movie.edu. 600 IN SRV 0 100 389 terminator.movie.edu.
_ldap._tcp.Default-First-Site-Name._sites.DomainDnsZones.movie.edu. 600 IN SRV 0 100↵ 389 terminator.movie.edu.

Let's go through what these records are actually used for, splitting them up into sections for ease of understanding. To start with, the first record is for the domain itself:

movie.edu. 600 IN A 10.1.1.1

This A record is for LDAP clients that don't understand SRV records. Since Windows clients use SRV records to locate the LDAP service on the domain controller, you don't need this A record (the one for movie.edu) unless you're running other LDAP clients. (And even then, you can just point those clients at the domain controller using its fully qualified name: terminator.movie.edu, in this case.) It's good that the A record isn't required because a lot of folks already have an A record at the apex of their DNS namespace. This record usually points to a web server, not to an Active Directory server. For example, Movie U.'s main web server is accessible via both www.movie.edu and movie.edu.

Next, we have the following record:

ec4caf62-31b2-4773-bcce-7b1e31c04d25._msdcs.movie.edu. 600 IN CNAME↵ 
terminator.movie.edu.

This CNAME record, found under the _msdcs subdomain, is used by domain controllers during replication. The left side of the record is the globally unique ID (GUID) for the server. DCs use this record if they know the server's GUID and want to determine its hostname. If this record isn't present for a DC, other DCs cannot replicate changes from it. The DNSLint command, available in the Windows Server 2003 Support Tools, can be used to make sure all DCs have this CNAME record present. Here is an example command line:

C:\> dnslint /ad 10.13.51.18 /s 10.13.52.15 /v

The required /ad switch is optionally followed by the IP address of a DC to perform LDAP queries against. If an IP address is not specified, the local host is assumed. The /s option, also required, must be followed by the IP address (or the text localhost) of a DNS server that is authoritative for the_msdcs subdomain of the DC's domain. See Chapter 15 for more on using DNSLint for troubleshooting.

Next, we have this A record:

gc._msdcs.movie.edu. 600 IN A 10.1.1.1

This record is registered only if the DC is a global catalog server. You can query gc._msdcs.movie.edu to obtain a list of all the global catalog servers in the forest in much the same way you could query the AD domain's A record to get a list of all the domain controllers for a domain (if you allow registration of that record by domain controllers).

A few more global catalog-specific records are shown next:

_gc._tcp.movie.edu. 600 IN SRV 0 100 3268 terminator.movie.edu.
_gc._tcp.Default-First-Site-Name._sites.movie.edu. 600 IN SRV 0 100 3268↵ 
terminator.movie.edu.
_ldap._tcp.gc._msdcs.movie.edu. 600 IN SRV 0 100 3268 terminator.movie.edu.
_ldap._tcp.Default-First-Site-Name._sites.gc._msdcs.movie.edu. 600 IN SRV 0 100 3268↵ terminator.movie.edu.

Note that in the case of global catalog SRV records, the fourth record-specific data field—which is used for the port for the service—is 3268, the global catalog port. You may have also noticed the entries that contain Default-First-Site-Name. Each global catalog server registers site-specific records so clients can find the optimal global catalog server based on their site membership. If you renamed the default site and have other sites defined, you will see these site names used in the SRV records. See the "Site Coverage" sidebar for more information.

Site Coverage You can create sites in the Active Directory topology that do not have domain controllers located in that site (i.e., DC-less sites). In this situation, the domain controllers that have the lowest cost as defined by the site links cover for that site. When a DC covers for a site, it adds site-specific SRV records so that it advertises itself as a DC that can handle queries for clients in the site. To see a list of the sites that a particular DC is covering for, run the following nltest command (contained in the Windows Support Tools) and replace dc01 with the name of the DC you want to query: C:\> nltest /dsgetsitecov /server:dc01 So why would you want DC-less sites, especially when you could just add the subnets in those sites to the closest site that contains a domain controller? As far as Active Directory goes, there aren't many benefits to creating DC-less sites. One possible benefit is that it allows you to mimic your physical network topology in your site topology. In that situation, it is very likely that you have sites that do not have domain controllers. The real benefits come in with other services that depend on the site topology, such as DFS. It is possible that you might need a DFS server in a remote site that does not contain a domain controller. If you created the DC-less site, the clients in that site would use the local DFS server instead of one in the next closest site. Another benefit of DC-less sites is being able to apply group policy at the site level. If you have small sites that need a distinct group policy, you can create a small site group policy object and apply it to the target sites.

The next few SRV records are for Kerberos authentication (port 88) and the Kpasswd process (port 464), which allows users to change passwords:

_kerberos._tcp.dc._msdcs.movie.edu. 600 IN SRV 0 100 88 terminator.movie.edu.
_kerberos._tcp.Default-First-Site-Name._sites.dc._msdcs.movie.edu. 600 IN SRV 0 100↵ 88 terminator.movie.edu.
_kerberos._tcp.movie.edu. 600 IN SRV 0 100 88 terminator.movie.edu.
_kerberos._tcp.Default-First-Site-Name._sites.movie.edu. 600 IN SRV 0 100 88↵ terminator.movie.edu.
_kerberos._udp.movie.edu. 600 IN SRV 0 100 88 terminator.movie.edu.
_kpasswd._tcp.movie.edu. 600 IN SRV 0 100 464 terminator.movie.edu.
_kpasswd._udp.movie.edu. 600 IN SRV 0 100 464 terminator.movie.edu.

Just as with the global catalog SRV records, there may be more of the site-specific Kerberos records for any additional sites the DC covers.

The rest of the SRV records are used to represent a domain controller for a particular domain, site, and application partition. One record to note is the _ldap._tcp.pdc._msdcs.movie.edu. entry, which is registered by the DC that is acting as the primary domain controller (PDC) emulator for the domain.

_ldap._tcp.movie.edu. 600 IN SRV 0 100 389 terminator.movie.edu.
_ldap._tcp.Default-First-Site-Name._sites.movie.edu. 600 IN SRV 0 100 389↵ 
terminator.movie.edu.
_ldap._tcp.pdc._msdcs.movie.edu. 600 IN SRV 0 100 389 terminator.movie.edu.
_ldap._tcp.97526bc9-adf7-4ec8-a096-0dbb34a17052.domains._msdcs.movie.edu. 600 IN SRV↵ 0 100 389 terminator.movie.edu.
_ldap._tcp.dc._msdcs.movie.edu. 600 IN SRV 0 100 389 terminator.movie.edu.
_ldap._tcp.Default-First-Site-Name._sites.dc._msdcs.movie.edu. 600 IN SRV 0 100 389↵ terminator.movie.edu.
DomainDnsZones.movie.edu. 600 IN A 10.1.1.1
_ldap._tcp.DomainDnsZones.movie.edu. 600 IN SRV 0 100 389 terminator.movie.edu.
_ldap._tcp.Default-First-Site-Name._sites.DomainDnsZones.movie.edu. 600 IN SRV 0 100↵ 389 terminator.movie.edu.

Note the last three records—they are for the DomainDnsZones application partition. As we mentioned early, the DC locator process is used to find domain controllers for domains, but it is also used for application partitions as well. There will be records like those three for all the application partitions terminator replicates.

Based on all of these records, you can obtain a lot of information about an Active Directory environment by doing simple DNS queries. Some of the information you can retrieve includes:

• Global catalog servers in a forest or a particular site

• Kerberos servers in a domain or a particular site

• Domain controllers in a domain or a particular site

• PDC emulator for a domain

We could go on and on about Active Directory, but this is a book about DNS, so we won't. If you are interested in more information on Active Directory, see Active Directory, Second Edition and Active Directory Cookbook, both from O'Reilly. We return to a core DNS issue in the next chapter: growing your domain.