Round trip DNS
By Sandra Henry-Stocker
I was recently asked to describe in detail the process by which DNS
queries are resolved. The process turns out to have enough twists and
turns to be interesting and enough general utility for sysadmins to be
worth the trouble of generating a step-by-step description. So, in this
week's column, we follow the flow of a DNS query from start to finish -
beginning with an initial query (generated by a ping or ssh request) and
ending with the answer arriving back at the user's system.
The process that we are about to describe occurs hundreds, maybe
thousands, of times every day on the typical computer, usually without
the user being aware. Whenever someone logs into or transfers a file to
a remote system, he is (with few exceptions) calling on DNS to determine
the remote system's IP address.
The host names sent to DNS servers for resolution are typically referred
to as "friendly" names, referring to the fact that they are generally
easier to remember than the corresponding IP addresses, thus being
"human-friendly". Having worked with numerous systems with names more
difficult to pronounce, more difficult to differentiate and generally
less memorable than IP addresses, I don't have any particular fondness
for this term and generally refer to the names of systems simply as host
names or FQDNs (fully qualified host names).
Stop 1: /etc/nsswitch.conf
On Solaris and other Unix systems which make use of nsswitch.conf files
to determine how to look for various types of network information, the
first stop after the user presses his enter key is the
/etc/nsswitch.conf file. The hosts line in this file will tell the
system what service to use to resolve host names. If the hosts line
looks like the one below, the next stop in resolving the host name will
be DNS. If the words "nis" and "files" were listed in reverse order,
the second stop would be /etc/hosts. Other options that you might see
in this file are ldap, nis and nisplus.
hosts: nis files [NOTFOUND=return]
Stop 2: /etc/resolv.conf
Stop two (assuming a hosts line like that shown above) would be the
/etc/resolv.conf file. This file tells the system where to find the DNS
server that will act as its point of contact for DNS information. This
file will look something like this:
domain dragonflyditch.com
nameserver 10.10.10.2
nameserver 10.10.11.2
search dragonflyditch.com
In this example, the DNS server is set to query the domain
dragonflyditch.com. The two name servers, located at IP addresses
10.10.10.2 and 10.10.11.2, are likely a master and a slave (replica),
but there is no way to tell this from the /etc/resolv.conf file.
Stop 3: A Nearby DNS Server
Stop three involves the first of the listed name servers. Generally,
this is a name server that belongs to the particular organization, thus
able to resolve the names of local systems inaccessible from the
Internet. If this server does not respond to the query (e.g., if the
system or the bind process is down), the query will be sent to the
second of the listed name servers and so on. Otherwise, secondary and
tertiary name servers are not queried, whether or not the first name
server is able to resolve the host name.
The responding name server will examine the host name that is sent to it
and determine whether or not the particular host is a member of its own
domain. This happens whether or not the name has a domain attached to
it. For example, if the name server for the dragonflyditch.com domain
is asked to resolve the hostname www.xanga.com, it will check to see
whether www.xanga.com.dragonflyditch.com is a known host before looking
outside the local domain.
This name server will also look in its cache to see if it has saved the
requested information as a result of an earlier request. If the IP
address of the target system is located in the cache, it will be sent
back to the requesting system.
Stop 4: A Root DNS Server
Once the initial name server has determined that the requested host
information is neither in its zone files nor in its cache, it will refer
to the root domain servers - the upper level servers that maintain
information about the locations of name servers for various domains - to
locate a name server that is responsible for the root of the DNS "tree".
Information about the root domain servers is maintained in the server's
"hints" file. This may be called root.hints, root.cache or named.root;
the name isn't important as long as it is properly referenced in the
/etc/named.conf file. With the root hints file, a DNS server is able to
locate the name servers that are authoritative for any DNS domain.
The name server first parses the host name to determine which of the
top-level domains it belongs in (e.g., .com, .org, .de). It then uses
an iterative query to find a server for the target domain.
Stop 5: An Authoritative Name Server
Once the name server has located the name server which is authoritative
for a particular domain, it can request the needed information (i.e.,
that host's IP address) and return that information, when received, to
the requesting client.
Stop 6: The Requesting Process
The round trip time for a DNS lookup is generally measured in
milliseconds. In spite of the number of stops that are required, the
process is generally robust and surprisingly reliable.
Next week, we will examine some complexities of DNS resolution that we
glossed over today. In particular, we will look at the various types of
DNS queries: recursive, iterative and inverse.
About the author(s)
-------------------
Sandra Henry-Stocker has been administering Unix systems for nearly 18
years. She describes herself as "USL" (Unix as a second language) but
remembers enough English to write books and buy groceries. She
currently works for TeleCommunication Systems, a wireless
communications company, in Annapolis, Maryland, where no one else
necessarily shares any of her opinions. She lives with her second
family on a small farm on Maryland's Eastern Shore. Send comments and
suggestions to mailto:sstocker@itworld.com.
________________________________________________________________________________
CUSTOMER SERVICE
VIEW YOUR NEWSLETTERS
http://www.itworld.com/nl/registration
UNSUBSCRIBE
For instruction on how to unsubscribe, go to:
http://www.itworld.com/response/site_support.html#unsubnl
CHANGE YOUR E-MAIL ADDRESS
To change your e-mail, go to:
http://www.itworld.com/nl/email
For instruction on how to change your e-mail address, go to:
http://www.itworld.com/response/site_support.html#email
NEWSLETTER ARCHIVES
http://www.itworld.com/nl/archive.html
NEWSLETTER FAQS
For commonly asked newsletter questions, go to:
http://www.itworld.com/response/site_support.html
________________________________________________________________________________
CONTACTS
* Advertising: Clare O'Brien, Vice President of Sales,
clare_obrien@accelacommunications.com
* Other inquiries: Jodie Naze, Director, ITworld.com Site Network,
jodie_naze@accelacommunications.com
________________________________________________________________________________
PRIVACY POLICY
http://www.itworld.com/Privacy/
ITworld.com is a product of:
Accela Communications, Inc.
118 Turnpike Road
Southborough, MA 01772 USA
Copyright 2004 Accela Communications, Inc., All Rights Reserved.
http://www.accelacommunications.com
________________________________________________________________________
VISIT OUR SITE NETWORK
http://open.itworld.com
http://security.itworld.com
http://smallbusiness.itworld.com
http://storage.itworld.com
http://utilitycomputing.itworld.com
http://wireless.itworld.com
http://www.itworld.com