Name resolution is an essential function on all
TCP/IP networks, and the network infrastructure design process includes a
determination of what names your computers will use, and how those
names will be resolved into Internet Protocol (IP) addresses. As with IP
addressing itself, the names you choose for your computers are affected
by your network’s interaction with the Internet and by the applications
the computers are running.
What Is Name Resolution?
TCP/IP communications
are based on IP addresses. Every IP datagram transmitted by a TCP/IP
computer contains a source IP address, which identifies the computer
sending the datagram, and a destination IP address, which identifies the
computer that is to receive it. Routers use the network identifiers in
the IP addresses to forward the datagrams to the appropriate locations,
eventually getting them to their final destinations.
Off the Record
Computers
are able to read and process IP addresses easily, but human beings
unfortunately cannot. It is not practical to expect people to remember
the 32-bit IP addresses associated with Web sites, file system shares,
and e-mail addresses, so it has become common practice to assign
friendly names to these resources. This is why you use names like
www.adatum.com for Internet Web sites, access the computers on your
network by browsing among a list of names instead of IP addresses, and
address e-mail messages to [email protected], rather than to [email protected]. |
Friendly names are only
for use by people; they do not change the way the TCP/IP computers
communicate among themselves. Whenever you use a name instead of an
address in an application, the computer must convert the name into the
proper IP address before initiating communications with the target
computer. This name-to-address conversion is called name resolution.
When you type the name of an Internet server in your Web browser, the
first thing your computer does is resolve that name into an IP address.
Once the computer has the address of the Internet server, it can send
its first message, requesting access to the resource you specified in
the browser.
Note
Although
it is possible, in some cases, for computers themselves to resolve
names into IP addresses, most of the time the computer sends the name to
another system on the network and receives a response containing the IP
address associated with the name. The resource that the computer uses
to resolve the name depends on the type of name and the application that
generates the name resolution request. |
What Types of Names Need to Be Resolved?
To design a name
resolution strategy for an enterprise network, you must know the types
of names that the computers will have to resolve. Networks running
Microsoft Windows operating systems use two basic types of names for
computers and other resources: DNS names and Network Basic Input/Output
System (NetBIOS) names. DNS is the name resolution mechanism that
computers use for all Internet communications and for private networks
that use the Active Directory directory service provided with Windows
Server 2003 and Windows 2000 Server.
All the names that you
associate with the Internet, such as the names of Internet servers in
Uniform Resource Locators (URLs) and the domain names in e-mail
addresses, are part of the DNS namespace and are resolvable by DNS name
servers. All Internet service providers (ISPs) have DNS servers, which
they make available to their customers, but Windows Server 2003 includes
its own DNS server, which you can deploy on your private network.
Off the Record
Active
Directory is also based on DNS, and the names you assign to computers
on an Active Directory network can also be resolved by DNS servers, but
you must deploy a DNS on your own network for this purpose. |
Windows operating
systems prior to Windows 2000 used NetBIOS names to identify the
computers on the network. The NetBIOS name of a Windows system is the
computer name that you assign it during the operating system
installation. Windows includes several different name resolution
mechanisms for NetBIOS names, and chief among these is WINS.
Off the Record
Even
though Windows operating system releases starting with Windows 2000
rely on Active Directory instead of NetBIOS names, all Windows operating
system versions still include a WINS client, and Windows Server 2003
and Windows 2000 Server still include the WINS server, so that they can
interact with computers on the network running the older operating
systems. |
If
all the computers on your network are running Windows 2000 and later
versions, and Active Directory has been installed, the network is not
using NetBIOS names, and you don’t have to run WINS servers. You can
also disable the NetBIOS Over TCP/IP (NetBT) protocol on your computers,
using the controls in the NetBIOS Settings box, found in the WINS tab
in the computer’s Advanced TCP/IP Settings dialog box.
|
In the 1970s, when
the Internet was still an experimental network called the ARPANET,
system administrators assigned friendly names to their computers, which
they called host names.
A host name is a single word that administrators used to represent the
computer’s IP address in applications and other references. To resolve
host names into IP addresses, every computer had a host table,
which was simply a text file called hosts that contained a list of host
names and their equivalent IP addresses, similar to the following list:
172.16.94.97 server1 # source server
10.25.63.10 client23 # x client host
127.0.0.1 localhost
The first column of the
host table contained IP addresses, the second column contained host
names, and the third column (including everything after the # symbol)
contained the administrator’s comments, which the computer ignored when
processing the table. When an application encountered a reference to a
host name, it consulted the computer’s hosts file, searched for the
name, and read the IP address associated with that name. Every TCP/IP
computer still contains a host table, although few of them actually use
it anymore. On a computer running Windows Server 2003, the host table is
called Hosts, and it is located in the %Systemroot%\System32\Drivers\Etc folder.
|
Because the ARPANET was
quite small when the host table was invented, the table was not too
large, and the administrators did not have to change it very often. As
the ARPANET grew, however, so did the number of computers on the
network, and so did the size of the host table. Soon, the network grew
to the point that host tables became impractical. To address these
problems, development began on what came to be known as the DNS.
Using the DNS
At
its core, the DNS is still a list of names and their IP addresses, but
instead of storing all the information in one place, the DNS distributes
it among servers all over the Internet. The DNS consists of a
hierarchical namespace, a collection of name servers, and DNS clients
called resolvers.
Each name server is the authoritative source for a small part of the
namespace. When DNS servers receive name resolution requests from
resolvers, they check their own records for the IP address associated
with the requested name. If the server does not have the information
needed, it passes the request to other DNS servers, until it reaches the
authoritative server for that name. That authoritative server is the
ultimate source for information about that name, so the IP address it
supplies is considered definitive. The authoritative server returns a
reply containing the IP address to the requesting server, which in turn
relays it back to the resolver, as shown in Figure 1.
For the DNS to
function in this manner, it was necessary to divide the namespace in a
way that would distribute it among many servers. It was also necessary
to devise a methodology that would enable a server to systematically
locate the authoritative source for a particular name. To accomplish
these goals, the developers of the DNS created the concept of the
domain. A domain is
an administrative entity that consists of a group of hosts (which are
usually computers). When a DNS server is the authoritative source for a
domain, it possesses information about the hosts in that domain, in the
form of resource records.
The most common resource record is the Host (A) resource record, which
consists of the host name and its equivalent IP address.
Off the Record
In
addition to Host (A) resource records, DNS servers also maintain other
types of resource records that contain additional information about the
hosts. |
Therefore, the full name
for a computer in the DNS consists of two basic parts: a host name and a
domain name. Note the similarity between the DNS name and an IP
address, which also consists of two parts: a network identifier and a
host identifier. The host name, as in the days before DNS, is a single
word that identifies a specific computer. Unlike host names in the early
days, however, current host names do not have to be unique in the
entire namespace; a host name only has to be unique in its domain.
Understanding Domains
The domain name part
of a DNS name is hierarchical, and consists of two or more words,
separated by periods. The domain namespace takes the form of a tree
that, much like a file system, has its root at the top. Just beneath the
root is a series of top-level domains, and beneath each top-level
domain is a series of second-level domains.
At
minimum, the complete DNS name for a computer on the Internet consists
of a host name, a second-level domain name, and a top-level domain name,
written in that order and separated by periods. The complete DNS name
for a particular computer is called its fully qualified domain name (FQDN).
|
Unlike an IP address,
which places the network identifier first and follows it with the host,
the notation for an FQDN places the host name first, followed by the
domain name, with the top-level domain name last. For example, in the
FQDN www.adatum.com, www is a host (or computer) in the adatum.com
domain. In the adatum.com domain name, com is the top-level domain and
adatum is the second-level domain. Technically, every FQDN should end
with a period, representing the root of the DNS tree, as follows:
However, the period is rarely included in FQDNs today.
|
Name Resolution and the Domain Hierarchy
The hierarchical
nature of the DNS domain namespace is designed to make it possible for
any DNS server on the Internet to use a minimum number of queries to
locate the authoritative source for any domain name, as shown in Figure 2.
This efficiency is possible because the domains at each level are
responsible for maintaining information about the domains at the next
lower level. For example, if a DNS server receives a name resolution
request for www.adatum.com from a client resolver, and the server has no
information about the adatum.com domain, it forwards the request to one
of the root name servers on the Internet. This is called a referral.
Note
The root name servers
are the highest-level DNS servers in the namespace, and they maintain
information about the top-level domains. Software developers
preconfigure all DNS server implementations with the IP addresses of
multiple root name servers, so they can send referrals to these servers
at any time. |
On receiving the request, the root name server reads the top-level domain in the requested name, in this case com,
and returns a resource record that contains the IP addresses of the
authoritative servers for the com domain to the requesting server. With
this information, the requesting server can now send a duplicate of the
client request to the authoritative server for the top-level, or com,
domain. The top-level domain server reads the requested name and replies
with a resource record that contains the IP addresses of the
authoritative servers for the second-level domain, in this case adatum.
The requesting server can
now forward its request to the server that is ultimately responsible
for the adatum.com domain. The adatum.com server reads the requested
name and replies by sending the resource record for the host called www
to the requesting server. The requesting server can now relay the
resource record to the client that originally requested the resolution
of the www.adatum.com FQDN. The client reads the IP address for www.adatum.com from the resource record and uses it to send packets to that server.
|
The name resolution
process described in the previous section is designed to convert DNS
names into IP addresses. However, there are occasions when it is
necessary for a computer to convert an IP address into a DNS name. This
is called a reverse name resolution.
Because the domain hierarchy is broken down by names, there is no
apparent way to resolve an IP address into a name using iterative
queries, except by forwarding the reverse name resolution request to
every DNS server on the Internet, which is obviously impractical.
To
address this problem, the developers of the DNS created a special
domain called in-addr.arpa (described in RFC 1035, “Domain
Implementation and Specification”), specifically designed for reverse
name resolution. The in-addr.arpa second-level domain contains four
additional levels of subdomains. Each of the four levels consists of
subdomains that are named using the numerals 0 to 255. For example,
beneath in-addr.arpa, there are 256 third-level domains, numbered from 0
to 255. Each of those 256 third-level domains has 256 fourth-level
domains beneath it, also numbered from 0 to 255. Each fourth-level
domain has 256 fifth-level domains and the fifth-level domains have 256
sixth-level domains, as shown in Figure 3.
Using this hierarchy,
it is possible to express an IP address as a domain name, and to create
a resource record in the domain that contains the name associated with
the IP address. For example, to resolve the IP address 192.168.89.34
into a name, a DNS server would locate a domain called
34.89.168.192.in-addr.arpa in the usual manner and read the contents of a
special type of resource record called a Pointer (PTR)
resource record to determine the name associated with that IP address.
The IP address is reversed in the domain name because in IP addresses,
the host identifier is on the right and in FQDNs, the host name is on
the left.
|
Speeding Up the DNS
Although
this might seem like a long and tedious process, the DNS name
resolution procedure usually occurs in a few seconds or less. Several
DNS elements speed up the process. The first reason for the quick
responses is that the most commonly used top-level domains, such as com,
org, and net, are actually hosted by the root name servers, eliminating
one iteration from the request referral process.
The second
reason is that most DNS server implementations maintain a cache of
information they receive from other DNS servers. When a server possesses
information about a requested FQDN in its cache, it responds directly
using the cached information, rather than sending another referral to
the authoritative server for the FQDN’s domain. Therefore, if you have a
DNS server on your network that has just successfully resolved the name
www.adatum.com by contacting the adatum.com server, a second user
trying to access the same host a few minutes later would receive an
immediate reply from the local DNS server, rather than having to wait
for the entire referral process to repeat.
|
DNS servers recognize two types of name resolution requests: recursive queries and iterative queries.
In a recursive query, the DNS server receiving the name resolution
request takes full responsibility for resolving the name. If the server
possesses information about the requested name, it replies immediately
to the requestor. If the server has no information about the name, it
sends referrals to other DNS servers until it obtains the information it
needs. TCP/IP client computers send recursive queries to their
designated DNS servers. In an iterative query, the servers that receive
the name resolution request immediately respond with the best
information they possess at the time, whether that information is a
fully resolved name or a reference to another DNS server. DNS servers
use iterative queries when communicating with each other. It is
considered impolite to configure one DNS server to send a recursive
query to another DNS server, except in the case of a special type of
server called a forwarder, which is specifically configured to interact
with other servers in this way.
|
Understanding the Domain Hierarchy Levels
The top two levels of the
DNS hierarchy, the root and the top-level domains, exist primarily to
respond to queries for information about other domains. The root name
servers do nothing but respond to millions of iterative requests by
sending out the addresses of the authoritative servers for the top-level
domains.
Note
There
are seven primary top-level domains: com, net, org, edu, mil, gov, and
int, plus two-letter international domain names representing most of the
countries in the world, such as fr for France and de for Deutschland
(Germany). There are also a number of newer top-level domains promoted
by Internet entrepreneurs, such as biz and info, which have yet to be
widely used commercially. |
Each top-level
domain has its own collection of second-level domains. Individuals and
organizations can lease these domains for their own use. For example,
the second-level domain adatum.com belongs to a company that purchased
the name from one of the many Internet registrars now in the business of
selling domain names to consumers. For the payment of an annual fee,
you can purchase the rights to a second-level domain.
To use the domain
name, you must supply the registrar with the IP addresses of the DNS
servers that you want to be the authoritative sources for information
about this domain. The administrators of the top-level domain servers
then create resource records pointing to these authoritative sources, so
that any com server receiving a request to resolve a name in the
adatum.com domain can reply with the addresses of the adatum.com
servers.
Planning
To
create authoritative sources for your domain, you can deploy your own
DNS servers, using Windows Server 2003 or another operating system, or
you can pay to use your ISP’s DNS servers. |
Determining DNS Requirements
If
you plan to give network users client access to the Internet, they must
have direct access to one or more DNS servers. You can run your own DNS
servers on your network for this purpose, or you can use your ISP’s DNS
servers. You do not need to register a domain name. The clients’ DNS
servers can be caching-only servers,
meaning that they exist only to process name resolution requests sent
by clients, and they can be located on your private network, with
unregistered IP addresses.
Hosting an Internet Domain
If you plan to host an
Internet domain, you must register a second-level domain name and give
the IP addresses of your DNS servers to your domain registrar. These
servers must have registered IP addresses and must be available on the
Internet at all times. The servers do not have to be on your network,
and do not have to be in the domain you have registered. You can use
your ISP’s DNS servers for this purpose (for a fee), but be aware that
you will occasionally have to change the server configuration, to create
or modify the resource records stored there. If you maintain your own
DNS servers, you can manage the resource records yourself and retain
full control over their security. If your ISP hosts your domain, you
might have to have them make the changes, and they might charge you an
additional fee for each modification.
Hosting Internet Servers
If you plan on hosting
Internet servers on your network, you must have access to a registered
domain on the Internet, with authoritative DNS servers on which you can
create resource records that assign host names to your servers. You can
either register your own domain (in which case you must meet the
requirements described in the previous paragraph, “Hosting an Internet Domain”), or you can use your ISP’s DNS servers, in which case they must create the necessary resource records for you.
Using Active Directory
If you plan to run Active Directory on your network, you must have at least one DNS server on the network that supports the Service Location (SRV)
resource record, such as the DNS Server service in Windows Server 2003.
Computers on the network running Windows 2000 and later versions use
DNS to locate Active Directory domain controllers. To support Active
Directory clients, the DNS server does not have to have a registered IP
address or an Internet domain name.
Combining DNS Functions
In many cases, a network
requires some or all of these DNS functions, and you must decide which
ones you want to implement yourself and which you want to delegate to
your ISP. It is possible to use a single DNS server to host both
Internet and Active Directory domains, as well as to provide name
resolution services for clients. However, when planning a DNS name
resolution strategy for a medium or large network, you should run at
least two DNS servers, to provide fault tolerance.
Important
If
you plan to use your ISP’s DNS servers for any functions other than
client name resolution, be sure that the DNS server implementation they
are using is compatible with the Windows Server 2003 DNS servers you are
using, and that they are able to provide the services you need. |
You might also want
to consider splitting up these functions by using several DNS servers.
For example, you can use your ISP’s DNS servers for client name
resolution, even if you are running your own DNS servers for other
purposes. The main advantage of using your ISP’s servers is to conserve
your network’s Internet bandwidth. Remember that the Internet name
resolution requests that DNS servers receive from client resolvers are
recursive queries, giving the first server responsibility for sending
iterative queries to other DNS servers on the Internet to resolve the
name. When the DNS server receiving the recursive queries is on your
private network, all the iterative queries the server generates and
their responses go through your Internet access router, using your
bandwidth (see Figure 4).
If your clients use a DNS server on your ISP’s network (which is nearly
always a free service), only one query and one response go through your
router. The ISP’s DNS servers generate all the iterative queries, and
these queries travel directly to the Internet.
Using NetBIOS Names
If computers on your
network are running versions of Microsoft Windows earlier than Windows
2000, they are using NetBIOS names and must have a means of resolving
those names into IP addresses. When Microsoft originally incorporated
networking capabilities into the Windows operating systems, it relied on
NetBIOS names to identify computers and on the NetBEUI protocol for
communications. NetBEUI uses these names exclusively; the protocol has
no other addressing system. Later, Microsoft adopted TCP/IP as its
default protocols, but continued to use NetBIOS to provide friendly
names for computers until the release of Active Directory with Windows
2000.
Off the Record
These
earlier Windows operating systems are capable of interacting with
computers running Windows 2000 and later versions because the computers
maintain an equivalent that is compatible with NetBIOS for every Active
Directory name. |
The NetBIOS
namespace is flat, not hierarchical like the DNS namespace. Each
computer and other entity has a single NetBIOS name up to 16 characters
long, which must be unique on the network. In the Windows operating
system, the sixteenth character is reserved for a code that identifies
the type of resource represented by the name; therefore, the NetBIOS
names you assign to computers running Windows operating systems can be
no longer than 15 characters. The non-hierarchical nature of the NetBIOS
namespace means that it is not as scaleable as DNS, and indeed it need
not be, because NetBIOS is intended for private networks only, not for
huge networks like the Internet.
NetBIOS Name Resolution Mechanisms
Windows has several name resolution mechanisms for NetBIOS names, which are as follows:
WINS
WINS is a NetBIOS name server included with all current server versions
of the Windows operating system, WINS registers the names and IP
addresses of Windows NetBIOS computers as they start up and compiles its
own name resolution database. Every computer running a Windows
operating system includes a WINS client that an administrator must
configure with the IP address of at least one WINS server on the
network. Before the computer running the Windows operating system can
communicate with another NetBIOS computer on the network, it sends a
message called a NAME QUERY REQUEST as a unicast to its WINS server. The
message contains the NetBIOS name of the other computer, and the WINS
server responds with the IP address associated with the name. WINS
servers are able to provide NetBIOS name resolution services for an
entire enterprise network running Windows operating systems.
Broadcast transmissions
When an administrator does not configure a computer running a Windows
operating system to use WINS for NetBIOS name resolution, the system
attempts to resolve names by broadcasting a NAME QUERY REQUEST message.
The computer that possesses the name in the message is responsible for
replying to the sender with its IP address. The broadcast transmission
method is less efficient than WINS, both because broadcasts generate
more network traffic than unicasts and because broadcast transmissions
are limited to the local network.
Lmhosts This
text file contains a lookup table that is much like the Hosts file
originally used by TCP/IP systems. Lmhosts name resolution is extremely
fast, because no network communication is required, but administrators
must update the file manually, making the method subject to the same
administrative drawbacks as the Hosts file. Computers running Windows
operating systems that rely on broadcast name resolution typically use
Lmhosts as a backup method for resolving the names of computers that are
not on the local network.
NetBIOS name cache
No matter what other NetBIOS name resolutions they use, all computers
running Windows operating systems also maintain a cache of recently
resolved names and their IP addresses. When a computer needs to resolve a
NetBIOS name, it always checks the cache first. This enables the
computer to avoid repeatedly resolving the same names.
Windows uses these
name resolution mechanisms in combination, depending on the
configuration of the computer. When you configure a computer to use
WINS, it resolves NetBIOS names by first checking the NetBIOS name
cache, then sending messages to its WINS server. If the WINS server
fails to resolve a name or is unavailable, the computer reverts to
broadcast name resolution, and then to Lmhosts. Computers not configured
to use WINS generate broadcast transmissions after checking the cache
then revert to Lmhosts if broadcast transmissions fail to resolve the
name.
Determining NetBIOS Name Resolution Requirements
If your network has
computers running Windows operating systems that use NetBIOS on multiple
local area networks (LANs), running WINS servers is all but essential.
Otherwise, your network would be burdened with the additional traffic
generated by broadcast name resolution, and you would have to create and
update an Lmhosts file for every computer that has to resolve NetBIOS
names on other LANs. If all your NetBIOS computers are in the same
broadcast domain on a single local area network (LAN), you can do
without WINS, because the broadcast transmission method is automatic and
requires no administration. However, if you have a large number of
NetBIOS computers, you might want to use WINS anyway, to save network
bandwidth.
Off the Record
Although
WINS is generally not a major administrative burden, you might want to
consider eliminating NetBIOS and NetBT traffic from your enterprise
completely by upgrading all your downlevel computers to Windows 2000 or
higher. |
Using Local Host Name Resolution
Although network
administrators rarely use Hosts and Lmhosts files as primary name
resolution methods, these files are useful as fallback mechanisms. If
you have computers performing critical functions that would be
interrupted by the failure of a name resolution mechanism, you can
create a Hosts or Lmhosts file on these computers. The file would
contain the names and IP addresses of systems that must be resolvable
for the critical functions to proceed.
