Professional Windows Server 1002003 Security A Technical Reference [Electronic resources] نسخه متنی

DNS is the backbone of Active
Directory for two reasons: domains are named using DNS and domain
controllers are located using DNS. So if DNS is not set up properly,
client computers will not be able to locate domain controllers and
users will be unable to log on to the network and access resources.
Since DNS is critical to the operation of WS2003-based networks,
I'll begin by briefly reviewing basic DNS concepts
while keying in on various issues relating to DNS on WS2003. For a
more detailed look at DNS on Microsoft platforms, see

DNS
on Windows 2003 (O'Reilly).

How DNS Works

DNS is a client/server, Internet-standard protocol that implements a
hierarchical naming system using a distributed database for
associating names of hosts with IP addresses. This database is stored
on DNS servers in the form of zones containing resource records, and
DNS clients query these servers to resolve hostnames into IP
addresses. DNS queries can be issued by DNS clients to DNS servers or
by DNS servers to other DNS servers, and this system of queries is an
essential part of the name-resolution process.

Let's unpackage that brief description in more
detail.

DNS Namespace

The DNS namespace is
hierarchical
in structure and starts with a root domain represented by a period.
Beneath the root

domain are
top-level domains, which are either functional
(

.com ,

.org ,

.edu , and so on) or geographical
(

.us ,

.ca ,

.uk , and so on). Beneath these top-level domains
are second-level domains, usually simply called domains, which can be
registered by individuals, companies, or organizations. An example is

microsoft.com , which Microsoft Corporation has
registered under the

.com top-level domain.
Organizations that have registered a domain name have the right to
subdivide it any way they like into third-level domains, usually
called subdomains. An example of a subdomain is

msdn.microsoft.com , which Microsoft uses for the
Microsoft Developer Network.

An individual host (a computer, router interface, network printer, or
anything else having an IP address) is uniquely described within the
DNS namespace by its fully qualified domain name (FQDN). For example,
a computer whose hostname is

bob and belongs to
the

sales subdomain of the

mtit.com domain would have the FQDN

bob.sales.mtit.com . FQDNs can consist only of
the letters a-z and A-Z, the numbers 0-9, and the dash (-) symbol if
they are to be RFC 1123-compliant, and this is important if your
Microsoft DNS server needs to interoperate with another name server
such as a Unix system running BIND.

DNS has several advantages over plain old IP addressing. FQDNs are
easier to remember than IP addresses, and the hierarchical structure
of the DNS namespace makes it easier to search for a particular host.
Also, by organizing your hosts into a series of domains and
subdomains, you can distribute management of your hosts across
different DNS servers by creating zones. That way, instead of
requiring that each DNS server contain and manage the entire DNS
database, each DNS server can manage a portion of the distributed DNS
database.

Resource Records

The DNS namespace

is implemented as a distributed
database containing resource records that map the FQDN of each host
on the network to its IP address. They are called resource records
because they are records of the resources (servers, gateways, and so
on) on your network. Some important types of resource records
include:

SOA (start of authority) record

Each zone has one SOA record that identifies which DNS server is
authoritative for domains and subdomains in the zone.

NS (name server) record

An NS record contains the
FQDN and IP address of a DNS server authoritative for the zone. Each
primary and secondary name server authoritative in the domain should
have an NS record.

A (address) record

By far the most common
type of resource record, an A record is used to resolve the FQDN of a
particular host into its associated IP address.

CNAME (canonical name) record

A CNAME record contains an alias (alternate name) for
a host. For example, if a server functioned as both a web server and
an FTP server, its A record might use the FQDN

www.mtit.com , while the CNAME record might
specify

ftp as an alias for

www . CNAME records can also be
used to hide the true names of hosts on your network from external
clients.

PTR (pointer) record

The opposite of an A
record, a PTR record is used to resolve the IP address of a host into
its FQDN.

SRV (service) record

An SRV record is used
by DNS clients to locate a server that is running a particular
servicefor example, to find a domain controller so you can log
on to the network. SRV records are key to the operation of Active
Directory.

MX (mail exchange) record

An MX record points to one
or more computers that process SMTP mail for an organization or site.

DNS Servers

The backbone of any DNS

implementation is the collection of DNS servers (or name servers)
that contain the distributed DNS database. The main job of a name
server is to resolve the names of hosts into their IP addresses.
There are four different types of DNS servers you can deploy:

Primary name server

A name server that maintains the writable copy of the zone information
for a zone. There can be only one primary name server for each zone.

Secondary name server

A name server that has a read-only copy of the zone information for a
zone. A secondary name server gets its zone information from a master
name server by a process called zone transfer. Each zone can have
zero, one, or several secondary name servers to provide fault
tolerance in case the primary server goes down. Secondary servers can
also be used to reduce the load on primary servers; they can be
deployed at branch offices to prevent clients from trying to perform
name resolution over slow WAN links using primary name servers at
company headquarters.

Master name server

Any name server configured to allow secondary name servers to download
zone information. A master name server can be either a primary or
secondary name server.

Caching-only name server

A name server that doesn't have any zone
information. Instead, these servers cache the results of name queries
and use this information to answer other queries. Caching-only name
servers are useful in reducing unwanted WAN traffic. For example, say
you have a primary name server located at company headquarters and
configure a caching-only name server at a smaller branch office that
is connected to headquarters over a slow WAN link. If clients at the
branch office use DNS to issue name queries, the caching-only name
server receives the requests and uses the WAN link to query the
primary name server for the information. When the primary server
returns a response, the caching-only server passes it on to the
client but caches it in case it is requested later by another client.
This reduces the WAN traffic that would occur if no name server was
located at the branch office.

Note that a master name server can be either a primary or a secondary
name server. In other words, secondary name servers can download
their zone file from either a primary name server or another
secondary name server. Note also that a name server can be a primary
name server for one zone while being a secondary name server for
another zone. In other words, each DNS server can service multiple
zones and have different roles in different zones.

Zones

A

zone is a
contiguous
(unbroken) subtree of the DNS namespace managed by name servers
authoritative for that zone. For example, a zone might include a
domain (

mtit.com ) and several
subdomains (

sales.mtit.com and

marketing.mtit.com ) but exclude
other subdomains (

accounting.mtit.com and

support.mtit.com ). Each zone has one primary
name server that is authoritative over the zone and zero, one, or
more name servers that are associated with the zone but
aren't authoritative.

Name servers that are member servers use standard zones that store
their zone information in ASCII files called zone files. A standard
primary zone has a writable copy of the zone file while a standard
secondary zone has a read-only copy. Name servers that are also
domain controllers running WS2003 can use either standard zones or
Active Directory-integrated zones. An Active Directory-integrated
zone stores its zone information in Active Directory, which has
several advantages over standard zones:

• Zone transfers are subsumed into Active Directory replication, a
  process that is more efficient than traditional DNS zone transfers
  using standard zones. This also means there is only one replication
  topology to configure instead of two.

• All name servers are primary name servers and can therefore have zone
  information directly modified on them. This provides fault tolerance
  compared to traditional DNS where, if a primary name server goes
  down, you have to promote a secondary name server to take its place.

• Storing zone information in Active Directory is more secure as it
  prevents unauthorized clients from performing dynamic updates.

Zone transfers can be performed between standard and Active Directory-integrated zonesfor example, between WS2003 name servers and Unix BIND machines or legacy NT DNS servers.

Regardless of how zone information is stored, you can create
three types of zones:

Forward-lookup zone

Contains mostly A records for resolving FQDNs into IP addresses when
clients issue forward-lookup queries. Also contains an SOA record
that defines the zone; NS records that specify authoritative name
servers for the zone; and possibly other kinds of resource records
such as SRV, MX, or CNAME.

Reverse-lookup zone

Contains mostly PTR records for resolving IP addresses into FQDNs
when clients issue reverse-lookup queries (rare) or when
administrators use nslookup to troubleshoot
name-resolution problems (more common). Reverse lookups
don't try to search all DNS namespaces to resolve
their IP address into an FQDN; instead, they use a special DNS domain
called

in-addr.arpa , which uses a reverse
ordering of the dotted IP address notation to identify hosts and
stores this information in PTR records.

Stub zone

Contains only those resource records (SOA, NS, and possibly A
records) needed to identify the authoritative name servers for that
zone. Stub zones are new to WS2003. Stub zones help manage DNS query
traffic by enabling local name servers to know the names and
addresses of remote name servers authoritative for a given zone
without requiring the local name server to have a copy of the
information in that zone.

Zone Transfers

Zone transfer is the
process
by
which zone information is replicated between name servers. Zone
transfer ensures that all name servers for a zone have identical
copies of the zone information, which enables clients to use any name
server for the zone to perform name resolution. In DNS on NT, zone
files were updated by a process called full zone transfer. This meant
that when a DNS administrator updated one or more resource records in
the primary zone, the full zone file would be replicated from the
primary name server to any secondary name servers for the zone. This
wasted network bandwidth, and WS2003 uses incremental zone transfer,
in which only changes to the zone files are updated. Incremental zone
transfer initiates when any of the following events occurs:

• The master server for a zone notifies all secondary name servers for
  the zone that records have changed in its zone file and that they
  need to request an update. The process used by the master name server
  to notify secondary name servers is called DNS Notify. The secondary
  name servers then contact their master name server requesting the
  updates for their zone files.

• The DNS Server service on a secondary name server starts up or is
  restarted. The secondary name server then contacts the designated
  master name server for the zone, requesting the updates for its zone
  file.

• The refresh interval configured on the secondary server expires. The
  secondary name server then contacts the master name server for the
  zone, requesting the updates for its zone file.

Note that name servers using incremental transfer require additional
disk space to maintain a version history of their zone filesin
effect, a DNS transaction log.

Resolvers

A

resolver is software running

on a client
computer that enables the computer to communicate with name servers
to resolve FQDNs into IP addresses. In other words, a name server
represents the server side of DNS while a resolver represents the
client side. The WS2003 resolver is a caching resolver
servicewhen a name is resolved, the results are cached locally
by the client in case it needs to resolve the name again in the
immediate future (before the time-to-liveor TTLof the
resolved entry expires). WS2003 resolvers also cache negative
name-query responses (failure to resolve a name).

Resolvers must be configured with the IP address of the name servers
they will use to perform name resolution. This may be done either
manually (for static IP addressing) or dynamically using DHCP.

Name Queries

A

name query is a request


for resolving a name into an IP address.
Name queries may be issued by resolvers to name servers, or by name
servers to other name servers. There are two types of queries:

Iterative query

When a DNS client or server issues an iterative query to a
DNS server, the server must respond with its best current answer
without contacting any other servers itself. This best answer is
either:

• The requested information (typically the IP address associated with
  the FQDN sent in the query). If this response is returned, the client
  is satisfied because it has what it wants.

• A time-out or error message. If this is the case, the client is
  satisfied because an authoritative answer was received. However,
  since the answer was "I don't
  know," the desired network communications
  can't take place.

• A pointer to an authoritative DNS server that is located one level
  down in the hierarchical DNS namespace. This kind of response is
  known as a

  referral . If a referral is returned,
  the client goes on to interactively query the lower name server. This
  process continues until one of the two previous responses is received
  by the client.

Recursive query

When a client or server issues a recursive query to a DNS
server, the server that receives the query takes on full
responsibility for finding an answer to the client's
request and does so iteratively querying other DNS servers until it
has an answer or receives an error or time-out message. Whatever the
result of the process, it is passed to the client.

Recursive queries are used by:

• DNS clients (resolvers), such as those running on XP Professional or
  other desktop Microsoft Windows operating systems.

• DNS servers that are configured to forward unresolved names to
  another DNS server. A DNS server that has been configured to perform
  recursive instead of iterative queries is called a forwarder because
  it forwards queries for resolving FQDNs outside of its domain to a
  different DNS server.

Dynamic Updates

Dynamic updates is a process that
enables resolvers to automatically update their associated resource
records on their zone's primary name server. This is
a big improvement over traditional DNS, in which administrators had
to manually create and update resource records in zone files. Dynamic
DNS can be used with both standard and Active Directory-integrated
zones and can be used in conjunction with DHCP to make administering
DNS even easier. Depending on how dynamic updates have been
configured, either the DHCP client itself updates its records on the
DNS server or the DHCP server updates the client's
records for it.

Using Dynamic DNS with Active Directory-integrated zones enables
resource records on name servers to be automatically updated more
securely than when using standard primary and secondary zones. This
works because only clients and servers that have been authorized in
Active Directory can update their own records on the DNS server.

Delegation

You can also create
subdomains
in a domain and then delegate authority over those subdomains to
different name servers. This lets you delegate the task of
administering DNS for each subdomain to different name servers. For
example, in the large enterprise

mtit.com
domain, there might be several subdomains such as

ontario.mtit.com ,

quebec.mtit.com,
bc.mtit.com , and so on. You can have one or more DNS
servers to service each geographical location within the enterprise
and make them authoritative over their own subdomain.

Planning DNS

Let's now look at planning issues
related to DNS and Active Directory. There are three basic approaches
to implementing a DNS namespace with Active Directory.
I'll examine each of them briefly.

Single-Name Approach

In this approach, your existing DNS name is used for both
the forest root domain of your internal (Active Directory) network
and for your external servers connected to the Internet. For example,
if your company has the registered domain name

mtit.com and you want to migrate your NT network
to WS2003, you could choose

mtit.com as the name
of your forest root domain. The advantage of this solution is that it
is the simplest form of namespace to adopt. The disadvantage is that
you would need to consider carefully how to secure your private
corporate network from the Internet since both your private and
public servers use the same naming system. The solution is to
implement a firewall/proxy server with identical DNS zones created on
your internal and external name servers. Your internal DNS server
needs resource records for all the IP hosts on your private network,
including special records to support Active Directory. Using a WS2003
DNS server is a good choice for your private network, since it fully
supports Active Directory's features. Your external
DNS server needs only those web servers and other hosts that you
maintain outside your firewall for public access, and it can be
either Microsoft DNS or BIND. You can then configure your internal
name server to forward client requests for Internet resources to your
external name server.

The advantages of this approach are:

• Users need to remember only a single domain name when they want to
  access your company's resources, whether within the
  private corporate intranet or on your public Internet servers.

• You need to register only one company name with your domain name
  registrary.

The disadvantages are:

• The additional DNS administration work involved in making sure
  internal and external DNS servers contain only the records they are
  supposed to have

• The complexity of reconfiguring your firewall

• The fact that if you maintain some resources on both your internal
  and external networks, you need to figure out how to keep them
  synchronized properly

Double-Name Approach

In this approach, your existing DNS issued name for your public
(external) servers connected to the Internet and a second DNS name
for the forest root domain of your internal network is obtained. For
example, you could use the DNS domain name

mtit.com for your public web servers and
register a new second name such as

mtitenterprises.com to use for your internal
network. You can then configure your internal name server to use your
external server (typically your ISP's name server)
as a forwarder for name resolution on the Internet. Note that when
you use the Configure Your Server Wizard to install DNS on WS2003, it
checks to see if your network is connected with the Internet. If it
is, it creates a root hints file called

Cache.dns that contains the addresses of the
Internet's root name servers, and as a result you
don't need to configure a forwarder to resolve hosts
on the Internet. However, you may still want to configure a forwarder
to increase performance and reduce DNS query traffic over your
Internet connection.

If Configure Your Server can't detect an Internet connection, it may create a root (.) forward-lookup zone on your server to designate your server as a root name server! As a result, you may not be able to resolve hosts on the Internet even with a forwarder configured. The solution is to delete the root zone.

A variant of this approach is to use your existing DNS name
(

mtit.com ) for your public presence and a local
DNS name such as

mtit.local for your internal
network. The

.local suffix is not part of the
Internet's DNS system, and as a result clients on
the Internet are unable to resolve and access hosts on your internal
network and can resolve and access only public hosts on your DMZ.
This provides an added layer of protection for your internal network
by isolating it from the Internet, and if you use Manage Your Server
to add the Typical First Server role to your first WS2003 machine,
the Configure Your Server Wizard suggests this approach.

The advantages of this approach are:

• The DNS naming hierarchy of your
  private WS2003 domains, trees, and forests is hidden from external
  users on the Internet. The security of your network resources is
  greater because internal and external resources are clearly
  distinguished by belonging to different DNS domains.

• You can leave your existing corporate DNS
  naming hierarchy and zone files (if implemented) intact and simply
  upgrade your NT DNS servers to WS2003.

The disadvantages are:

• You may need to register a second DNS
  domain name for your company with ICANN (unless you use the
  

  .local approach).

• Some users might be confused by the fact that your company has
  two DNS domain names. Which one should they use?

Subdomain Approach

In this approach, your existing DNS domain name is used for your
public servers connected to the Internet and for the legacy portion
of your internal network that you don't plan to
migrate to WS2003, and then a subdomain is created for the portion of
your private network that you plan to upgrade to WS2003 and as the
name for your WS2003 root domain in Active Directory. This might be
the best approach in a heterogeneous network in which you migrate
only a portion of your network to WS2003, especially if DNS is
already configured on your existing network. For example, say your
existing network uses the DNS name

mtit.com , and
you want to install Active Directory on a portion of your network. In
this case you could create a DNS subdomain such as

windows.mtit.com and make this the name of your
new WS2003 root domain. Note that it might be better to use

windows.mtit.com than

win2003.mtit.com in case you decide to upgrade
your network to Windows 2006 later on!

To make this happen, you need to:

• Create a DNS zone for

  windows.mtit.com ,
  preferably on a WS2003 name server since it will support Active
  Directory.

• Create a delegation record on the existing name server that is
  authoritative for your

  mtit.com domain. The
  delegation record will indicate that authority for the
  

  windows.mtit.com subdomain is delegated to your
  WS2003 name server.

• Install Active Directory with

  windows.mtit.com
  as your forest root domain.

The advantages of this approach are:

• It provides a contiguous namespace for Active Directory, which you
  can easily administer.

• It doesn't necessitate the upgrade of your existing
  DNS servers, so you can keep your good old BIND servers if you like.

• You can leave your firewall pretty much the way it is right now.

The main disadvantage is that it takes longer for your DNS naming
structure to name resources on your WS2003 network. This is only a
minor bother, however, unless your domain name is something like

wishicouldthinkofabetterdomainnamethanthis.com !

BIND and WS2003

Most name servers on the Internet and in large enterprises with
heterogeneous networks are Unix machines running BIND, which stands
for Berkeley Internet Name Domain. Recent versions of BIND are
compatible with Active Directory, and you can elect to keep your
existing BIND name servers if you like when deploying WS2003 on your
network. The procedures for integrating BIND with Active Directory
aren't trivial, however, and there are several ways
you can approach the issue of integrating existing BIND name servers
and Active Directory:

• You can use BIND exclusively, an approach your DNS administrator may
  prefer. You should use BIND 8.2.1 or later if you plan to keep your
  BIND servers and not implement WS2003 name servers. This is because
  BIND 8.2.1 supports Dynamic DNS (DDNS), SRV resource records,
  incremental zone transfers, and negative cachingall features
  supported by Active Directory. However, BIND doesn't
  support WINS or WINS-R records, which may be needed if you need to
  integrate WINS with DNSfor example, if part of your network
  will continue to use NT. If you want to use a BIND name server for
  the forest root domain of Active Directory, you need to create
  special subdomains like
  

  _msdcs.<domainname> ,
  

  _sites.<domainname> ,
  

  _tcp.<domainname> , and
  

  _udp.<domainname> , where
  

  <domainname> is the DNS name you
  registered for your company. These special subdomains are used by
  Active Directory to store various configuration information on the
  DNS server. See the

  Deployment Planning Guide of
  the

  Windows Server 2003 Resource Kit for more
  information.

• You can use WS2003 name servers exclusively. This is the simplest
  solution from the point of view of WS2003 but requires an upheaval of
  your existing BIND name servers and DNS administration scheme, plus
  the retraining of your DNS administrators. With the proven stability
  of BIND, your DNS administrators may try to talk you out of this
  approach.

• You can use Windows name servers for your internal network and BIND
  name servers for name resolution on the Internet. This might be the
  best solution, and it doesn't even require upgrading
  your BIND servers. What you can do here is register a second DNS name
  and use this as your forest root domain in Active Directory. You can
  then leave your BIND server to manage DNS for the portion of your
  network you don't plan to migrate to WS2003 and to
  manage DNS for your Internet hosts. Then create a secondary zone on
  your BIND name server for your WS2003 domain and a secondary zone on
  your WS2003 DNS server for your BIND server's
  domain.

• You can use BIND for both the internal and external network and
  configure your WS2003 root domain as a subdomain of your
  company's existing DNS domain. This might be a good
  solution if you are planning to migrate some (but not all) of your
  network to WS2003. On the BIND server, you then delegate authority
  for the WS2003 subdomain to Active Directory, which manages the
  delegated portion of DNS namespace for the network. You must be
  running BIND 8.2.1 or later if you go this route, however. What you
  need to do is create a delegation record on your BIND name server for
  the new subdomain and then configure the WS2003 DNS server to use the
  subdomain as the root domain for Active Directory.

For more information on BIND, see

DNS and BIND
by Paul Albitz and Cricket Liu (O'Reilly).