Once you have determined how
your network will use DNS, it is time to begin designing the DNS
namespace for your network. The namespace design can include a
hostnaming pattern for all the computers on your network, as well as the
more complex naming of the network’s domains and subdomains, both on
the Internet and in Active Directory.
Using an Existing Namespace
If you are designing a new
network from scratch, you are creating a new DNS namespace as well,
which means that you don’t have to work existing domains and hosts into
your naming strategy. If the organization for which you are designing
the network already has domain names in use, whether internal or
external, or has a computer naming strategy already in place, it is
probably best to retain those elements and build your new DNS namespace
around them.
If the
organization already has an Internet presence, they probably already
have at least one registered domain name and the use of a DNS server to
host the domain. You can continue using the existing domain name, even
expanding it to include internal subdomains. You can also continue using
the existing DNS server, or migrate the DNS services to a new server on
the network you are designing. If you change the DNS server, you must
inform the domain registrar so that they can alter the IP addresses of
the authoritative servers in the top-level domain records. The changes
can take a few days to propagate throughout the Internet, so it is a
good idea to have an overlap period during which both the old and new
DNS servers are operational.
If you are upgrading a
NetBIOS network to Windows Server 2003 and Active Directory, you
already have an internal NetBIOS namespace, which you can migrate to
DNS, gradually or immediately. For example, if you are currently using
WINS for NetBIOS name resolution, you can configure Windows Server 2003
DNS servers to resolve the NetBIOS names by sending queries to your WINS
servers. You can also continue to use your existing NetBIOS names by
integrating them into your DNS namespace design.
|
If
you are deploying Active Directory on your network for the first time,
and you have an existing namespace of any kind, be careful to design
your Active Directory hierarchy in coordination with the names you
already have.
Creating Internet Domains
Designing a DNS
namespace for your organization’s Internet presence is usually the
easiest part of deploying DNS. Most organizations register a single
second-level domain and use it to host all their Internet servers.
Registering a Domain
In most cases, the
selection of a second-level domain name depends on what is available. A
large portion of the most popular top-level domain, com,
is already depleted, and you might find that the name you want to use
is already taken. In this case, you have three alternatives: choose a
different domain name, register the name in a different top-level
domain, or attempt to purchase the domain name from its current owner.
If you are certain
you want to use the second-level domain name you have chosen—for
example, when the name is a recognizable brand of your organization—your
best bet is usually to register the name in another top-level domain.
Although the org and net
domains are available to anyone, these domains are associated with
nonprofit and network infrastructure organizations, respectively, and
might not fit your business. As an alternative, a number of countries
around the world with attractive top-level domain names have taken to
registering second-level domains commercially.
Using Multiple Domains
Some organizations
maintain multiple sites on the Internet, for various reasons. Your
organization might be involved in several separate businesses that
warrant individual treatment, or your company might have independent
divisions with different sites. You might also want to create different
sites for retail customers, wholesale customers, and providers. Whatever
the reason, there are two basic ways to implement multiple sites on the
Internet:
Register a single second-level domain name and then create multiple subdomains beneath it
For the price of a single domain registration, you can create as many
third-level domains as you need, and you can also maintain a single
brand across all your sites. For example, a company called Contoso
Pharmaceuticals might register the contoso.com domain, and then create
separate Web sites for doctors and patients, in domains called
doctors.contoso.com and patients.contoso.com.
Register multiple second-level domains If
your organization consists of multiple completely unrelated brands or
operations, this is often the best solution. You must pay a separate
registration fee for each domain name you need, however, and you must
maintain a separate DNS namespace for each domain. A problem might arise
when you try to integrate your Internet domains with your internal
network. You can select one of your second-level domains to integrate
with your internal namespace, or you can leave your internal and
external namespaces completely separate, as discussed later in this
lesson.
Creating Internal Domains
Using DNS on an
internal Windows Server 2003 network is similar to using DNS on the
Internet in many ways. You can create domains and subdomains to support
the organizational hierarchy of your network in any way you want. When
you are designing a DNS namespace for a network that uses Active
Directory, the DNS domain name hierarchy is directly related to the
directory service hierarchy. For example, if your organization consists
of a headquarters and a series of branch offices, you might choose to
create a single Active Directory tree and assign the name adatum.com to
the root domain in the tree. Then, for the branch offices, you create
subdomains beneath adatum.com with names like miami.adatum.com and
chicago.adatum.com. These names correspond directly to the domain
hierarchy in your DNS namespace.
When selecting names for your internal domains, you should try to observe these rules:
Keep domain names short
Internal DNS namespaces tend to run to more levels than Internet ones,
and using long names for individual domains can result in excessively
long FQDNs.
Avoid an excessive number of domain levels
To keep FQDNs a manageable length and to keep administration costs
down, limit your DNS namespace to no more than five levels from the
root.
Create a naming convention and stick to it
When creating subdomains, establish a rule that enables users to deduce
what the name of a domain should be. For example, you can create
subdomains based on political divisions (such as department names) or
geographical divisions (such as names of cities), but do not mix the two
at the same domain level.
Avoid obscure abbreviations
Don’t use abbreviations for domain names unless they are immediately
recognizable by users. Domains using abbreviations such as NY for New
York or HR for Human Resources are acceptable, but avoid creating your
own abbreviations just to keep names short.
Avoid names that are difficult to spell
Even though you might have established a domain naming rule that calls
for city names, a domain called albuquerque.adatum.com will be all but
impossible for most people (outside New Mexico) to spell correctly the
first time.
When you are designing an internal DNS namespace for a network that connects to the Internet, consider the following rules:
Use registered domain names
Although using a domain name on an internal network that you have not
registered is technically not a violation of Internet protocol, this
practice can interfere with the client name resolution process on your
internal network.
Do not use top-level domain names or names of commonly known products or companies
Naming your internal domains using names found on the Internet can
interfere with the name resolution process on your client computers. For
example, if you create an internal domain named microsoft.com, you
cannot predict whether a query for a name in that domain will be
directed to your DNS server or to the authoritative servers for
microsoft.com on the Internet.
Use only characters that are compliant with the Internet standard
The DNS server included with Microsoft Windows Server 2003 supports the
use of Unicode characters in UTF-8 format, but the RFC 1123 standard,
“Requirements For Internet Hosts—Applications and Support,” limits DNS
names to the uppercase characters (A–Z), the lowercase characters (a–z),
the numerals (0–9), and the hyphen (-). You can configure the Windows
Server 2003 DNS server to disallow the use of UTF-8 characters.
See Also
The
two primary DNS standards are RFC 1034, “Domain Names - Concepts and
Facilities,” and RFC 1035, “Domain Names - Implementation and
Specification.” These and numerous other documents related to the
development and operation of DNS are freely available at http://www.ietf.org. |
Creating Subdomains
Owning a second-level
domain that you have registered gives you the right to create any number
of subdomains beneath that domain. The primary reason for creating
subdomains is to delegate administrative authority for parts of the
namespace. For example, if your organization has offices in different
cities, you might want to maintain a single DNS namespace, but grant the
administrators at each site autonomous control over the DNS records for
their computers. The best way to do this is to create a separate
subdomain for each site, locate it on a DNS server at that site, and
delegate authority for the server to local network support personnel.
This procedure also balances the DNS traffic load among servers at
different locations, preventing a bottleneck that could affect name
resolution performance.
Combining Internal and External Domains
When
you are designing a DNS namespace that includes both internal and
external (that is, Internet) domains, there are three possible
strategies you can use, which are as follows:
Use the same domain name internally and externally.
Create separate and unrelated internal and external domains.
Make the internal domain a subdomain of the external domain.
Using the Same Domain Name
Using the same domain
name for your internal and external namespaces is a practice that
Microsoft strongly discourages. When you create an internal domain and
an external domain with the same name, you make it possible for a
computer in the internal network to have the same DNS name as a computer
on the external network. This duplication wreaks havoc with the name
resolution process.
Note
It
is possible to make this arrangement work by copying all the zone data
from your external DNS servers to your internal DNS servers, but the
extra administrative difficulties make this a less than ideal solution. |
Using Separate Domain Names
When you use
different domain names for your internal and external networks, you
eliminate the potential name resolution conflicts that come with using
the same domain name for both networks. However, using this solution
requires you to register (and pay for) two domain names and to maintain
two separate DNS namespaces. The different domain names can also be a
potential source of confusion to users who have to distinguish between
internal and external resources.
Using a Subdomain
The solution that
Microsoft recommends for combining internal and external networks is to
register a single Internet domain name and use it for external
resources, and then create a subdomain beneath that domain name and use
it for your internal network. For example, if you have registered the
name adatum.com, you would use that domain for your external servers and
create a subdomain, such as int.adatum.com for your internal network.
If you have to create additional subdomains, you can create fourth-level
domains beneath int for the internal network, and additional third-level domains beneath adatum for the external network.
The
advantages of this solution are that it makes it impossible to create
duplicate FQDNs, and it lets you delegate authority across the internal
and external domains, which simplifies the DNS administration process.
In addition, you have to register and pay for only one Internet domain
name.
Creating an Internal Root
When you use the
Windows Server 2003 DNS server with the namespace configurations
described thus far, your network’s namespace is technically part of the
Internet DNS namespace, even if your private network computers are not
accessible from the Internet. This is because all your DNS servers use
the root of the Internet DNS as the ultimate source for information
about any part of the namespace. When a client sends a name resolution
request to one of your DNS servers and the server has no information
about the name, it begins the referral process by sending an iterative
query to one of the root name servers on the Internet.
If you have a large
enterprise network with an extensive namespace, you can create your own
internal root. You do this by creating a private root zone on one of
your Windows Server 2003 DNS servers. This causes the DNS servers on
your network to send their iterative queries to your internal root name
server, rather than to the Internet root name server. Keeping DNS
traffic inside the enterprise speeds up the name resolution process.
Planning
Creating
an internal root is recommended when the majority of your clients do
not need frequent access to resources outside your private namespace. If
your clients access the Internet through a proxy server, you can
configure the proxy to perform name resolutions by accessing the
Internet DNS namespace instead of the private one. If your clients
require access to the Internet but do not go through a proxy server, you
should not create an internal root. |
Creating Host Names
Once you have created the
domain structure for your DNS namespace, it is time to populate these
domains with hosts. You should create hosts the same way you create
domains, by devising a naming rule and then sticking to it. In many
cases, host-naming rules are based on users, geographical locations, or
the function of the computer. When determining your naming rules, follow
these principles:
Create easily remembered names
Users and administrators should be able to figure out the host name
assigned to a particular computer by using your naming rules alone.
Use unique names throughout the organization Although
it is possible to create identical host names as long as they are
located in different domains, this practice is strongly discouraged. You
might have to move a computer and put it in a new domain that already
has a host by that name, causing duplication that interferes with name
resolution.
Do not use case to distinguish names
Although you can use both uppercase and lowercase characters when
creating a computer name on a computer running a Windows operating
system, DNS itself is not case-sensitive. Therefore, you should not
create host names that are identical except for the case of the letters,
nor should you create host names that rely on case to be
understandable.
Use only characters supported by all of your DNS servers
As with domain names, avoid using characters that are not compliant
with the DNS standard unless all the DNS servers processing the names
support these characters. The NetBIOS namespace supports a larger
character set than DNS does. When you are upgrading a Windows network
that uses NetBIOS names to one that uses DNS names, you might want to
use the Unicode (UTF-8) character support in the Windows Server 2003 DNS
server to avoid having to rename all your computers. However, you must
not do this on computers that are visible from the Internet; these
systems must use only the character set specified in RFC 1123.
Practice: Designing a DNS Namespace
Fabrikam, Inc., is
constructing a new data network and has registered the Internet domain
name fabrikam.com. You are to design a DNS namespace for the network
and, in the diagram shown after the following list, write the fully
qualified domain name for each computer in the space provided. Base your
design on the following information:
Fabrikam.com is the only second-level domain name you can use.
The internal network should be in a different domain from the external network.
The
company consists of three internal divisions: Sales, Human Resources,
and Production. Each division is to be represented by a separate
subdomain in the namespace.
Each
division has departmental servers performing various roles and as many
as 200 workstations, only some of which are shown in the diagram. Your
host names should identify the function of each computer.
Three
servers on an external perimeter network host the company’s Internet
services: Web, FTP, and e-mail. These servers must be in the domain
fabrikam.com.
Correct answers for this practice can vary, but they should contain the following characteristics:
The servers in the perimeter network should have FQDNs consisting of host names in the second-level domain fabrikam.com.
All three internal divisions should be in a third-level domain beneath fabrikam.com.
Each of the three divisions should have a fourth-level domain name beneath the internal network’s third-level domain.
Each
computer should have a unique host name that reflects its function and
differentiates it from other computers performing the same function.
The following diagram contains an example of a correctly designed namespace: