Just a few years ago, TCP/IP was not the king when it came to network communications
protocols. Windows NT 4.0 relied on the venerable NetBIOS Extended User Interface
(NetBEUI) protocol by default, and NetWare servers could be counted on to understand
only IPX/SPX. With the recent widespread adoption of the Internet by the masses,
TCP/IP slowly started to creep into private networks of all sizes and purposes.
Administrators and network designers began to see the power and flexibility
that TCP/IP offered them, and Microsoft and Novell took note of the shift. It
wasn't long before all operating systems provided support for TCP/IP, but
it still was not the networking protocol of choice. With the introduction of
Windows 2000, Microsoft made TCP/IP and the domain name system (DNS) integral
parts of Windows Active Directory networks. But how did DNS come into the picture
all of a sudden?

If you have ever connected to a Web site by name, you have used DNS. DNS is
a service used on the Internet for resolving fully qualified domain names (FQDNs)
to their actual Internet Protocol (IP) addresses. For example, suppose you are
preparing to take the latest Windows Server 2003 certification exam. You've
asked your coworkers what the best study guide available is, and they recommend
that you check out Que Publishing's Web site to see what is available.
Your obvious question is, "Where can I find Que Publishing's Web site?"
Before DNS, the answer would be 165.193.123.44. If you are like most
people, you'll remember that number for less than 30 seconds and will probably
never find Que Publishing's site (or get that study guide you were looking
for).

DNS puts a user-friendly face on that obscure numeric address. With DNS, your
friend can tell you to go to http://www.quepublishing.com,
and the DNS infrastructure of the Internet will translate the name to the correct
address, 165.193.123.44. It's like a series of interconnected
phone books. You put in a name, and it gives you the correct number. Fortunately
for those of us with a limited ability to memorize strings of numbers, the Internet
community recognized the benefits of a name-resolution system as a critical
part of the infrastructure that would make up the original Internet architectureand
DNS was born.

The DNS Namespace

As we've discussed, you probably have already used DNS, whether you are
familiar with the underlying mechanism or not. Domain names are easy to use and
remember: The ease at which you can access a Web site using domain names (such
as http://www.microsoft.com
or
http://www.quepublishing.com)
is a built-in simplicity that comes at a price; the DNS namespace is complex.
DNS names are created as part of a hierarchical database that functions much
like the directories in a file system. Hierarchies are powerful database
structures because they can store tremendous amounts of data while making it
easy to search for specific bits of information. Before examining the specifics
of the DNS namespace hierarchy, let's review some rules about hierarchies
in general.

NOTE

Microsoft's Active Directory Service is an excellent example of a
hierarchical database. Of course, given that the hierarchy is created on top of
the existing rules for a DNS namespace, the information on the DNS hierarchy
directly relates to the construction of Active Directory.

Hierarchies

Before getting into the details of a hierarchy, we should introduce some
terms:

TreeThis is a type of data structure with each element
attached to one or more elements directly beneath it. In the case of DNS, this
structure is often called an inverted tree because it is generally drawn with
the root at the top of the tree.

Top-level domain (TLD)TLD refers to the suffix attached to
Internet domain names. There are a limited number of predefined suffixes, and
each one represents a top-level domain. The more popular TLDs include
.COM, .EDU, .GOV, .MIL, .NET, and
.ORG.

NodeA node is a point at which two or more lines in the tree
intersect. In the case of DNS, a node can represent a TLD, a subdomain, or an
actual network node (host).

Fully qualified domain name (FQDN)A domain name that
includes all domains between the host and the root of DNS is an FQDN. For
example,
http://www.microsoft.com is
an FQDN.

LeafA leaf is an item at the very bottom of a hierarchical
tree structure, and it does not contain any other objects.

ZoneA DNS zone is a logical grouping of hostnames within
DNS. For example, quepublishing.com is considered the forward lookup
zone for Que Publishing. It is where the information about the Que Publishing
hosts is contained within DNS.

In DNS, containers called domains hold the information. The hierarchy starts
with a root container, called the root domain. The root domain doesn't
have a name, so it is typically represented by a single period, as shown in
Figure 3.1. The root domain contains
pointers to all TLDs, which are directly below the root. These are also sometimes
called first-level domains. Lower-level domains are second-level, third-level,
and so on. Every domain name has a suffix that indicates which TLD domain it
belongs to. There are only a limited number of such domains as defined by RFC
1591. Some of the more common TLDs are discussed in the following list:

Figure
3.1 This portion of the DNS hierarchy shows the location of two domains in
the DNS database in relation to the rest of the DNS database.

.COMIntended for commercial entities, but it has become the
overwhelming favorite top-level domain (example of .COM:
area51partners.com)

.EDUIntended for higher-education institutions, such as four-year
colleges and universities (example of .EDU:
berkeley.edu)

.GOVIntended for use by agencies of the U.S. Federal Government
(example of .GOV: whitehouse.gov)

.MILIntended for use by agencies of the U.S. military (example of
.MIL: af.mil)

.NETIntended for use by network providers and organizations
dedicated to the Internet, such as Internet service providers (example of
.NET: ibm.net)

.ORGIntended for nonprofit or noncommercial establishments, such as
professional groups, charities, and other such organizations (example of
.ORG: npr.org)

NOTE

Two-letter country code TLDs also exist for nearly all countries on the
planet. Examples include .US for the United States, .CA for
Canada, .JP for Japan, and .UK for the United Kingdom. New TLDs
are constantly being added to meet the requirements for new domain names on the
Internet. Recent additions include .BIZ and .INFO, among
others.

Fully Qualified Domain Names (FQDNs)

As we have discussed, DNS is used to translate a hostname to an IP address.
The FQDN name typically looks something like the following:

This is known as the host's fully qualified domain name (FQDN) because
it lists the host's precise location in the DNS hierarchy. The DNS name in
the example represents the host FILESVR042 in the subdomain
CORPORATE (this is frequently a department or division in a company),
which is in the subdomain AREA51PARTNERS (this is frequently the name
of the company or organization that has registered the domain), which is in the
TLD .COM.

TIP

Make sure you have a good understanding of what an FQDN is and how it is
represented.

Planning a DNS Namespace Design

Up to this point in our discussion about DNS, we have looked at only the
historical and design aspects of DNSand for good reason. Only by
understanding how DNS was created and designed can you effectively plan and
implement a DNS design in a Windows Server 2003 Active Directory domain. Because
DNS permeates Windows Server 2003, you must deliberately and carefully plan out
your DNS namespace before you ever perform the first installation of
Windows Server 2003 on a computer.

The following list represents some questions you should ask yourself when
planning your namespace needs:

Is your DNS namespace to be used for internal purposes only? If
so, you can use characters that are not typically used in DNS names, such as
those outside of the RFC 1123 standards. An example might be
bigcorp.local.

Is your DNS namespace to be used on the Internet as well? If you
are currently using a corporate DNS namespace on the Internet, or think that you
might at any point in the future, you should register your own domain name and
conform to Internet naming standards.

Will you be implementing Active Directory? The design and
implementation of Active Directory on your network plays a critical role in
determining how domains should be created and nested within each other. Chapter
7, "Planning and Implementing an Active Directory Infrastructure,"
examines the relationship between Active Directory and the domain structure in
more detail.

You have the following three basic options to consider when planning the DNS
namespace you will be using:

Use an Existing DNS NamespaceThis option uses the same
namespace for both the internal (corporate network) and external (Internet)
portions of your network. If your domain name is bigcorp.com, you would
use this for both internal and external use. Although this method is the easiest
and provides simple access to both internal and external resources, it poses
additional administrative requirements because an administrator must ensure that
the appropriate records are being stored on the internal and external DNS
servers as a security precaution.

Use a Delegated DNS NamespaceThis option uses a delegated
domain of the public namespace. If your domain name is bigcorp.com, you
might consider using corp.bigcorp.com for the internal namespace. When
using this option, the corp.bigcorp.com domain becomes the root of the
Active Directory forest and domain structure. Internal clients should be allowed
to resolve external namespace addresses; however, external clients should not.
Using a delegated DNS namespace provides a namespace that is easy to understand
and remember, and that fits in nicely with the existing registered domain name.
All internal domain data is isolated in the domain or domain tree, thus
requiring its own DNS server for the delegated internal domain. The downside to
delegated namespaces is that this adds length to the total FQDN.

Use a Unique DNS NamespaceThis option uses a completely
separate but related domain name for your internal namespace. As an example, if
you are using bigcorp.com for your external namespace, you might use
bigcorp.net for your internal namespace. This configuration provides
the advantage of improving security by isolating the two namespaces from each
other. Additionally, the administrative burden is relatively low because zone
transfers do not need to be performed between the two namespaces, and the
existing DNS namespace remains unchanged. In addition, this prevents internal
resources from being exposed directly to the Internet.

Consider the following example of a fictitious company that is in the
planning stages of a major worldwide network reorganization and upgrade to
Windows Server 2003 Active Directory. Gidget's Widgets, Inc., is a major
manufacturer of household goods and already owns the gidgets.com domain
name for its Internet Web site. Gidget's makes everything from bath towels
to kitchen sinks. Gidget's corporate headquarters are located in the United
States, with regional field offices in Canada, Mexico, England, Germany, India,
Japan, and Australia. Gidget's corporate structure has the following major
departments: Executive, Administrative, Engineering, Manufacturing, Facilities,
Sales, Legal, and Information Services. Within each department are one or more
individual divisions. How would you go about designing a DNS namespace for the
Gidget's Widgets internal network?

You have several options; let's assume for the sake of argument that you
are going to first create a delegated domain named corp to serve as
the root of the internal network and also as the Active Directory root. Starting
with the corp.gidgets.com domain, you could create fourth-level domains
by country code. Within these, you could create fifth-level domains, as required,
for each of the major departments. You might end up with a configuration that
looks something like that shown in Figure
3.2.

If you were a network administrator in the United States working from a computer
called GREENGUY42, your FQDN would be greenguy42.it.us.corp. gidgets.com.
Of course, you could also design the DNS namespace using continents instead
of countries, if desired. When creating DNS namespaces that are several levels
deep like the example seen in Figure 3.2,
you must keep in mind some general DNS restrictions as outlined in Table 3.1.

No matter what design you settle on, you must (in most cases) get it right
the first time. Redesigning a DNS namespace is a difficult and time-consuming
task after the fact, at best. In addition, failing to properly design the
namespace for Active Directory compatibility can lead to functionality problems
in the future.

Figure
3.2 Gidget's network has been nicely organized by using countries as
third-level domains and major departments as fourth-level domains.

Table 3.1 DNS Name Restrictions

Restriction

Standard DNS

DNS in Windows Server 2003 (and Windows 2000)

Characters

Supports RFC 1123, which permits A to Z, a to z, 0 to 9, and the hyphen
().

Supports several different configurations: RFC 1123 standard, as well
as support for RFCs 2181 and the character set specified in RFC 2044.-

FQDN length

Permits 63 bytes per label and 255 bytes for an FQDN.

Permits 63 bytes per label and 255 bytes for an FQDN. Domain controllers
are limited to 155 bytes for an FQDN.

After you've planned out your namespace, you're ready
to get down to business and start working out the finer points of your DNS
implementation. The next thing you need to plan for is the type of zones you
will be using. But what exactly is a zone?