Dns On Windows Server 1002003 [Electronic resources] نسخه متنی

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 priorityconfusing, 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).

A client previously located in Site A logs in from Site B.

When the client boots up, it thinks it is still in Site A, so it
proceeds to contact the DC it has cached locally in the registry.

The DC in Site A receives the request and realizes that the client
should now be talking to a DC in Site B, since its IP address has
changed. In its reply to the client, the DC in Site A refers the
client to the DC in Site B.

The client then performs a DNS lookup to find a DC in Site B.

The client then contacts a DC in Site B. Three things can happen: the
DC responds and authenticates the client; the DC fails to respond (it
could be down), so the client attempts to use a different DC in Site
B; or the DC fails to respond and the client fails to find another DC
in Site B. In the last case, the client turns back to the DC in Site
A and authenticates with the first server it contacted.

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 fieldwhich is used for the
port for the serviceis 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.

C:\> nltest /dsgetsitecov /server:dc01

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 recordsthey 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.