As you may have heard, Microsoft Windows 2000 will depend heavily on
the Domain Name System (DNS) service. With the currently scheduled
Microsoft Windows 2000 release date just around the corner, it makes sense
to ensure that you have a DNS server and that it's set up correctly. In
this article, we'll explain why you should be running DNS. We'll begin by
exploring the various components and functions of a DNS server. In part 2
of this article, we'll show you how to plan and implement a DNS server in
your organization.
What is DNS?
If you have a small network that's never been tied to the Internet,
chances are good that you've never needed a service such as DNS. Normally,
on small networks, computers running Microsoft Windows NT have no trouble
communicating with each other across the network. Such communications may
include browsing and resource sharing. The reason that you can perform
such tasks without the aide of external services is that Microsoft Windows
NT is designed to allow protocol-independent communications via UNCs
(Universal Naming Conventions). This means that no matter which protocol
two machines have in common, Microsoft Windows NT can mediate
communications between the two machines by passing information in the UNC
format. The UNC format includes computer names and resource names. For
example, you've probably seen network drives mapped with a command like
NET USE \\COMPUTER\RESOURCE. The \\COMPUTER\RESOURCE part of this command
is in the UNC format.
UNCs work great as long as everyone on the network is running on a
Microsoft Windows platform and the network is small enough that routing
isn't required. However, in the real world, this isn't the case.
For example, the Internet is a giant network made up of every type of
computer imaginable. Since only a fraction of Web servers are running
Microsoft Windows NT, the use of Universal Naming Conventions for Internet
surfing is impractical.
As you probably know, each Web site has a corresponding IP address. For
a computer on your network to connect to a Web server, which could be
anywhere in the world, you must know or be able to determine the server's
IP address. Only when the IP address is known can your computer begin the
complex routing process of connecting to a Web server halfway around the
world.
This is where DNS comes in. DNS is a service that rides on top of
Microsoft Windows NT and resolves domain names to IP addresses. For
example, if you enter http://www.techrepublic.com/ in
your Web browser, your browser passes the domain name (techrepublic.com)
to the DNS server. The DNS server performs several operations, which we'll
explain later, and returns the IP address to your Web browser. Once the
Web browser knows the IP address that's registered to the page, it can
begin the process of connecting to the Web page.
Why Does Microsoft Windows 2000 Depend On DNS?
Microsoft Windows 2000 is more heavily dependent on DNS than Microsoft
Windows NT 4.0. As we mentioned earlier, Microsoft Windows NT has no
trouble communicating with other Microsoft Windows-based computers as long
as it doesn't have to perform any routing. The NetBEUI protocol that is
usually used for small workgroups isn't routable. If you're performing
routing, you must use a routable protocol such as TCP/IP. As you may know,
Microsoft Windows NT attempts to send computer names across TCP/IP.
However, if there is a router between two PCs, Microsoft Windows NT relies
on a WINS server to pass the computer name and other NetBIOS information
between the two computers.
Microsoft Windows 2000 does away with the WINS service. Instead, it
incorporates WINS functionality into a service called Dynamic DNS. This
means that even if your network isn't connected to the outside world, you
may still have to run the DNS service, just to be able to browse and share
resources among computers with routers between them.
The DNS Hierarchy
Originally, all domain name resolution occurred on one computer, which
contained a text file called HOSTS.TXT. However, as time went on, the
HOSTS.TXT file required update after update. The computer containing this
file was also being overrun with name resolution requests.
In response to this situation, DNS was designed in a way that would
keep all the domain information from being stored on a single computer.
Instead, DNS servers follow a specific hierarchy. At the top of the
hierarchy is the root-level DNS. The root-level DNS contains information
about all the top-level domains. Top-level domains are the common domain
names such as COM, EDU, ORG, and GOV. Below the top-level domains are
second-level domains. For example, TECHREPUBLIC is a second-level domain
to the COM domain, thus making the TECHREPUBLIC.COM domain name possible.
Second-level domains may also include sub-domains. For example,
support.microsoft.com is a sub-domain of the microsoft.com domain.
A DNS server can play several roles. It may cache information that it
obtains from the Internet, or it may actively participate in the domain
structure. For example, if your organization has a registered domain name,
it's probably a second-level domain name. This means that your DNS server
would include a list of any sub-domains that you own and a link to the
top-level domain that you're linked to. The portion of the domain
structure that an individual DNS is responsible for is called the DNS's
zone of authority.
You can also have a secondary DNS server. This secondary DNS server can
copy domain information across the network from the primary DNS server
that has authority over at least one zone. Such an action is called a zone
transfer.
Types of DNS Queries
Before you can effectively set up a DNS server, you must truly
understand the tasks that the server must perform. A DNS server is capable
of performing four different types of tasks.
Recursive Queries
The simplest type of DNS query is the recursive query. In a recursive
query, the server either returns the information that the client is asking
for or returns an error message stating that the information doesn't
exist. The DNS server doesn't attempt to contact another server to obtain
the information.
Iterative Queries
In an iterative query, the DNS server either resolves the requested
name to an IP address or refers the client to another DNS server that may
be able to. For example, suppose a client needs to resolve
www.techrepublic.com. The DNS will check its zones first. If it doesn't
find the requested domain, the DNS will send the request to a root-level
domain. The root-level domain will reply to the request with the address
of the .COM name server. The local DNS will then send a query for
www.techrepublic.com to the .COM name server. The .COM name server will
then respond to the DNS with the address of the DNS servicing
www.techrepublic.com. Finally, the DNS will contact the DNS responsible
for maintaining the techrepublic.com domain. That DNS will pass the IP
address of www.techrepublic.com to the local DNS, which in turn passes the
address on to the client that requested it.
Inverse Queries
An inverse query is a query in which a client tries to determine the
host name associated with a known IP address. There is no direct
searchable way of performing a reverse lookup. Therefore, a special domain
called in-addr.arpa was created to handle this task. The in-addr.arpa
domain contains nodes named after IP addresses.
Caching
As you saw with the iterative query, a DNS may have to perform several
queries to obtain a single piece of information. Once that information is
obtained, it's stored in a cache so that the DNS doesn't have to look it
up again the next time the information is asked for.
Each item in the cache is assigned a TTL (Time To Live) value. This
value is set by the Administrator and controls how long a resolved name
will remain in the cache. Shorter TTL periods result in more frequent DNS
updates, resulting in greater accuracy. Unfortunately, short TTL periods
place additional strain on your DNS since it has to search the Internet
for name resolutions more frequently.
DNS Configuration Files
A typical DNS server uses four basic types of files: a database,
reverse lookup, cache, and boot file. Each of these files stores
information related to performing specific DNS tasks. In the sections that
follow, we'll describe each file type.
Database Files
By default, Microsoft Windows NT comes with a file called PLACE.DNS.
This file is a template that you can use to build your database file.
Microsoft recommends copying this file to another file with a name that
matches your domain. For example, we would copy PLACE.DNS to
TECHREPUBLIC.COM.DNS.
The database file always begins with a start of authority record, which
is responsible for defining the general parameters of the DNS zone.
The database file may also contain name server records. Name server
records list additional DNS servers.
Another optional component of a database file is host records. A host
record is used to make a static association between a host name and an IP
address.
The final component of a database file is a CNAME record. A CNAME
record allows you to assign more than one host name to a single IP
address. This allows you to use multiple aliases to a single domain.
Reverse Lookup File
The reverse lookup file uses a structure similar to the database file.
The main difference is that it deals strictly with the in-addr.arpa zone.
Within the reverse lookup file, IP addresses are linked to the
in-addr.arpa zone in reverse order. For example, to provide reverse
lookups for the network 147.100.100.0, a reverse lookup file is created
with a filename of 100.147.in-addr.arpa. This file contains a start of
authority record like database files, but it also contains pointer records
that make the reverse lookups possible.
Cache File
The cache file CACHE.DNS contains all the resolutions the name server
has performed where the TTLs haven't expired. By default, the CACHE.DNS
file also contains records for all the root name servers on the Internet.
Boot File
The boot file is only used if you plan to make changes to the DNS
through the editing of text files and not through the DNS Manager. In such
cases, the boot file controls the startup behavior of the DNS.
Conclusion
In this article, we've provided you with information regarding the way
that a DNS server functions. In part 2, we'll show you how to plan and
implement a DNS server in your organization.
Brien M. Posey is an MCSE and a freelance technical writer. He
also works as a network engineer for the Department of Defense. You can
contact him via e-mail at Brien_Posey@xpressions.com.
(Because of the large volume of e-mail that he receives, it's impossible
for him to respond to every message. However, he does read them
all.)