Understanding how DNS

works, part 1
f you want to use TCP/IP on your network, you'll probably
need to set up a DNS server. What is DNS and how does
it work? Jim Boyce examines DNS and shows you some
of its ins and outs.
DNS (Domain Name Service) is one of the most basic services on the
Internet. If you want to effectively set up TCP/IP on your network, youll
probably need to install a DNS server at some point. But what is DNS and
how does it work? In this Daily Drill Down, Ill take a brief look at DNS and
show you some of its ins and outs.

DNS 101
The early Internet landscape was pretty barren with only a few hundred
computers making up the ARPANET, the military/educational precursor to the
Internet. Then, as today, each device on the network was a node, and each
node needed a unique address to enable data packets to find their
destinations. Anyone that has ever used IP addresses knows that its tough
enough to remember a few addresses on your local network, much less keep
track of the addresses for remote systems you use often. Thats where host
names came into the picture.

Host names provide a more friendly way to name hosts, making it easier to
remember host addresses. For example, when you want to get the news, you
can point your browser to www.newsmax.com instead of 64.29.200.227. Add
a couple of hundred other addresses to your frequent site list, and you can
see that host names are a lot easier on the brain than IP addresses.

But converting host names to IP addresses doesnt happen by magic. It needs

some form of translation to make it happen, and the mechanism that enables
that translation is the Domain Name System, or DNS.

In the early days when there were only a few hundred nodes, a single text file
could easily map host names to their corresponding IP addresses. This text
file, called Hosts.txt, was managed by the Standford Research Institute (SRI)
 and contained all of the name-to-address mappings for all nodes on the
ARPANET. Operating systems (primarily UNIX at that point) use the Hosts.txt
file to map host names to IP addresses. System administrators copied the
Hosts.txt file from SRI to their local systems periodically to update their
address maps.

As the number of nodes on the network continued to increase, using a

relatively static text file to provide mapping quickly became impractical. New
hosts were added so rapidly that neither SRI nor system administrators had
any hope of keeping up. So, the DNS system was developed in the mid-1980s
to provide a dynamic means of updating and resolving host names to their IP
addresses.

About those host and domain names

Each device on the Internet is called a host. Whether the host is a computer,
printer, router, and so forth, as long as it has a unique IP address, its a host.
Just as the IP address identifies the host uniquely, so does the host name.
For example, assume your computers host name is rainbow. Your computer
resides in the domain techrepublic.com. So, your computers Fully Qualified
Domain Name (FQDN) is rainbow.techrepublic.com. The FQDN identifies the
host uniquely within the DNS name space.

Domains arent limited to a single level. Assume techrepublic.com has two

different divisions, one on the east coast and one on the west coast. The east
coast domain is east.techrepublic.com and the other is west.techrepublic.com.
Sales is located on the west coast, so its domain is
sales.west.techrepublic.com. Joe Blow, who works in the sales department,
has a computer named jblow. Its FQDN is jblow.sales.west.techrepublic.com.
Traffic reaches his computer through something called delegation, which Ill
cover a little later.

The DNS name space contains seven common domain suffixes, which are
listed in Table A.

Table A
Suffix Purpose Example
com Commercial organizations (businesses) microsoft.com
edu Educational organizations such as colleges and universities berkeley.edu
gov Governmental organizations such as the IRS, SSA, NASA, and so on nasa.gov
mil Military organizations army.mil
net Networking organizations such as ISPs mci.net
org Noncommercial organizations such as the IEEE standards body ieee.org
int International organizations such as NATO nato.int

There are other domain suffixes as well, including national domains such as
the us domain, which is used for governmental, regional, and educational
entities in the United States. Other countries have their own domains, such as
jp for Japan, uk for the United Kingdom, and so forth.

Until recently, an organization known as InterNIC was responsible for

managing the majority of the top-level domains in the DNS name space.
InterNIC switched from being a nonprofit organization to the now for-profit
Network Solutions. When it made that switch, it lost its monopoly on the name
space and now there are several entities that register and maintain the DNS
name space.

How DNS works

DNS essentially functions as a distributed database using a client/server
relationship between clients that need name resolution (mapping host names
to IP addresses) and the servers that maintain the DNS data. This distributed
database structure enables the DNS name space to be both dynamic and
decentralized, giving local domains control over their own portion of the DNS
database while still enabling any client to access any part of the database.

At the uppermost level of the DNS name space are the root servers. The root
servers manage the top level domains: .com, .net, .org, .mil, .edu, .gov, and
.int. With all the domains in existence today, not to mention all the hosts in
those domains, you can see why the root servers actually maintain very little
information about each domain. In fact, the only data the root servers typically
maintain about a domain are the name servers that are authoritative for the
domain, or which have authority for the domains records.

The authoritative name servers actually maintain the records for a domain, or
in some cases delegate some of or the entire domain to other name servers.
The root servers know the name servers for techrepublic.com, for example,
and within those name servers the west.techrepublic.com domain is delegated
to another set of name servers that manage that portion of the overall
techrepublic.com domain. In most cases, domains and their records are either
managed directly by the organization owning the domain or by the ISP that
provides the Internet connection for the organization.

How DNS lookup works

A DNS client uses a resolver to request resolution of a host name to an IP
address. The resolver is really just a special-purpose application that's sole
function is to act as an intermediary between name servers and various
applications that need name resolution, such as Web browsers, e-mail
applications, and so on. Heres an example: Assume you fire up your browser
and direct it to connect to www.techrepublic.com. Your local resolver creates
a DNS query and sends it to the name server(s) listed in the local computers
TCP/IP settings.

In this case, Ill assume that youre connected to the Internet through a dial-up
connection to an ISP, and the ISPs name servers are specified in your
computers TCP/IP settings. The resolver sends the DNS request to the first of
those name servers. The server checks its cache of previously resolved
names, and in this case Ill assume that the ISPs name server has no cached
results for techrepublic.com. So, that name server sends a DNS query to the
root server for the .com domain. The root server responds with the addresses
of the name servers that are authoritative for the techrepublic.com domain.
Your ISPs name server then builds another request for
www.techrepublic.com and submits it to techrepublic.coms name server,
which responds with the IP address of www.techrepublic.com. That
information is passed back to your resolver, which passes it to your
application. Suddenly, techrepublic.coms Web site appears in your browser,
and all in a matter of a second or two.

Resolving a host name to an IP address is called forward lookup. There are

actually other ways the forward lookup can happen, depending on the way the
name servers involved are configured. For now, lets assume it happens as
described above.

Zones, domains, and subnets

You might think there is a relationship between an IP subnet and a domain,
but there is actually no correlation at all. A given domain can encompass any
number of subnets, none of which have any relationship to the domain itself.
In some cases, records in the domain can even point to hosts outside of the
domains subnets. For example, assume your company maintains its own
name servers for its domain but outsources hosting for its Web site. The
company name servers contain a record that points the name www to the
hosting companys subnet, outside of those used by your company.
 A name server in most cases maintains the records for a portion of the DNS
name space called a zone. In many cases, the terms zone and domain seem
synonymous, but theyre actually not the same thing. A zone comprises all the
data for a given domain except those parts of the domain that are delegated
to other name servers. So, a zone is the portion of a domain hosted on a
specific name server. When the entire domain resides on a single name
server, then domain and zone are synonymous.

As mentioned above, a name server can be authoritative for a zone. This

means the server has full information about the zone. A single name server
can manage many different zones, a case in point being a hosting company
that might host several hundred or even thousands of domains. The hosting
companys name servers would typically manage at least one zone for each
hosted domain. In addition, a name server can be authoritative for some
zones and non-authoritative for others.

Zones also fall into two categories: primary master or secondary master. A
primary master maintains the original records for the zone. The zones
administrator can create and modify records in the primary zone. A secondary
master serves as a read-only copy of the primary (essentially a backup copy
of the zone). The name server on which the secondary resides updates its
copy of the records through a periodic zone transfer, the frequency of which is
controlled by the zones configuration. A given name server can maintain
primary zones for some domains and secondary zones for others, so the
distinction between primary and secondary is zone-related, not server-related.

How about those DNS records?

The main purpose for DNS is to map host names to IP addresses, and the
data that makes that possible are stored as records in a zone file on the DNS
server hosting the zone. Within each zone file (really just a text file) are
resource records that define host names and other domain elements. There
are several different types of resource records, each of which performs a
specific function. Table B lists resource record types supported by the
Windows 2000 DNS service.

Table B
Record Purpose
SOA Specifies authoritative server for the zone
NS Specifies address of domains name server(s)
A Maps host name to an address
PTR Maps address to a host name for reverse lookup
CNAME Creates alias (synonymous) name for specified host
MX Mail exchange server for domain
SRV Defines servers for specific purpose such as HTTP, FTP, and so on
AAAA Maps host name to Ipv6 address
AFSDB Location of AFS cell database server or DCE cells authenticated server
HINFO Identifies hosts hardware and OS type
ISDN Maps host name to ISDN address (phone number)
MB Associates host with specified mailbox; experimental
MG Associates host name with mail group; experimental
MINFO Specifies mailbox name responsible for mail group; experimental
MR Specifies mailbox name that is proper rename of other mailbox; experimental
RP Identifies responsible person for domain or host
RT Specifies intermediate host that routes packets to destination host
TXT Associates textual information with item in the zone
WKS Describes services provided by specific protocol on specific port
X.25 Maps host name to X.121 address (X.25 networks); used in conjunction with RT records
WINS Allows lookup of host portion of domain name through WINS server
WINS-R Reverses lookup through WINS server
ATMA Maps domain name to ATM address

As you can see in Table B, there are a lot of resource record types to deal
with. Fortunately, most installations only require a few of the more common
types, including SOA, A, NS, PTR, CNAME, and MX. The SOA record
indicates that the server is authoritative for the zone, and Windows 2000
automatically creates an SOA record when you create a zone. The NS
records identify the name servers for the zone.

The A record, also called a host record, maps a host name to an IP address.
A given host might have different host names all mapped to the same IP
address. For example, a multipurpose server might map the www, FTP, and
mail host names to the same IP address, since the server performs all of
those functions (Web server, FTP server, and mail server). In addition, a zone
might have multiple entries for the same host name, each mapped to a
different IP address. The server returns all matching addresses to the
resolver. When the client is on the same network as the name server, the
name server sorts the results so that the address closest to the client is at the
top of the list for performance reasons. If the client is on a different network,
the server cycles through the addresses in round-robin fashion. In one query,
the first matching record is returned at the top of the list. In the second query,
the second match is returned at the top of the list and so on. This gives the
server the ability to essentially load-balance queries. For example, if youre
hosting the same Web site on redundant servers, round-robin query results
enable the DNS server to help balance the load across all of the servers.

CNAME stands for Canonical NAME. CNAME records map an alias name to a
Fully Qualified Domain Name (FQDN). They are also called alias records.
Host (A) records and CNAME records are usually applied in conjunction with
one another. You might map a servers host name using an A record, then
map (for example) www, FTP, and mail using CNAME records.

Mail Exchanger (MX) records are used to route e-mail. An MX record includes
the FQDN of the mail server for the zone, along with a preference number
from 0 through 65535. The preference number establishes priority for mail,
and when there are multiple MX records with different preference numbers,
the one with the lowest number is attempted first. Failing that, the sending
server uses the record with the next highest number. If all MX records in the
zone have the same preference number, the remote mail server decides
which record to use to attempt mail delivery.

The Pointer (PTR) record is another common record type. PTR records
perform the reverse of what host records do by mapping IP addresses to host
names. PTR records enable reverse lookup. When you create or modify an A
record, the Windows 2000 DNS service can automatically create or modify the
associated PTR record for you.

Regardless of its type, each resource record has certain properties associated
with it, and this information is stored along with the record in the zone file.
Among these properties is a time-to-live (TTL) property that specifies the
number of seconds the resolver should cache the record before it is
considered stale and is discarded. When the specified TTL period is reached,
the resolver discards the record and a subsequent attempt to resolve the
name will pull it from the authoritative name server for the record rather than
from the local cache.

The Internet is a dynamic place with hosts coming and going or changing their
addresses frequently. The TTL enables records to be cached locally to
improve response time and reduce the load on the network, since resolution
doesnt go past the initially queried name server where the record is cached.
When the record grows stale, the caching server (or resolver) throws it out,
ensuring that the next query will pull an up-to-date version of the record.

Conclusion
In part 2 of this Daily Drill Down series, Ill delve into the opposite of forward
lookup, appropriately called reverse lookup, which enables IP addresses to be
mapped to host names. Ill also examine delegation and several other ways
DNS servers resolve queries.

Jim Boyce is a former contributing editor and monthly columnist

for WINDOWS Magazine. Jim has authored and co-authored over 40 books
about computer software and hardware. He has been involved with computers
since the late 1970s as a programmer and systems manager in a variety of
capacities. He has a wide range of experience in the MS-DOS, Windows,
Windows NT, Windows 2000, and UNIX environments. In addition to a full-
time writing career, Jim is a founding partner and vice president of Minnesota
Webworks, a Midwest-based Web development firm.

The authors and editors have taken care in preparation of the content
contained herein, but make no expressed or implied warranty of any kind and
assume no responsibility for errors or omissions. No liability is assumed for
any damages. Always have a verified backup before making any changes.