Skip to main content

By clicking Submit, you agree to the developerWorks terms of use.

The first time you sign into developerWorks, a profile is created for you. Select information in your profile (name, country/region, and company) is displayed to the public and will accompany any content you post. You may update your IBM account at any time.

All information submitted is secure.

  • Close [x]

The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerworks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

By clicking Submit, you agree to the developerWorks terms of use.

All information submitted is secure.

  • Close [x]

developerWorks Community:

  • Close [x]

LPI exam prep: Domain Name System (DNS)

Intermediate Level Administration (LPIC-2) topic 207

David Mertz (, Developer, Gnosis Software
David Mertz
David Mertz has been writing the developerWorks columns Charming Python and XML Matters since 2000. Check out his book Text Processing in Python. For more on David, see his personal Web page.

Summary:  This is the third of seven tutorials covering intermediate network administration on Linux®. In this tutorial, David Mertz gives an introduction to DNS and discusses how to use Linux as a DNS server, chiefly using BIND 9. He shows how to set up and configure the service, how to create forward and reverse lookup zones, and how to ensure that the server is secure from attacks.

View more content in this series

Date:  01 Dec 2005
Level:  Intermediate PDF:  A4 and Letter (281 KB | 14 pages)Get Adobe® Reader®

Activity:  18929 views

Understanding domain name system queries

The topology of DNS

DNS is a hierarchical system of domain zones. Each zone provides a limited set of answers about domain name mappings, the ones within its own subdomain. A given server will query a more general server when it does not know a mapping and, if necessary, follow redirect suggestions until it finds the correct answer (or determines that no answer can be found, producing an error). When a local named server finds the answer to a DNS query, it caches that answer for a configurable amount of time (typically on the order of hours rather than seconds or days). By caching DNS queries, the overall network demand is lowered considerably, especially on top-level-domain (TLD) servers. The article on DNS at Wikipedia (see Resources for a link) is an excellent starting point for understanding the overall architecture. This tutorial borrows a public domain diagram from that site (see Figure 1 below).

A diagram of a hypothetical DNS query makes it easy to understand the overall lookup process. Suppose your local machine wishes to contact the symbolic domain name To find the corresponding IP address, your machine would first consult the local nameserver you have configured for a client machine. This local nameserver may run on the same machine as the client application; it may run on a DNS server on your local LAN; or it may be provided by your ISP. In almost all cases, it is an instance of BIND's named. This local nameserver will first check its cache, but assuming no cached information is available, will perform steps as in the following diagram:

Figure 1. Example of DNS recursion
An example of DNS recursion

Understand that in this diagram, the "DNS Recurser" is the actual DNS server (named), not the client application that talks to it.

DNS uses TCP and UDP on port 53 to serve requests. Almost all DNS queries consist of a single UDP request from the client followed by a single UDP reply from the server.

How an application knows where to find a DNS server

Configuring client application access to its DNS server(s) is quite straightforward. The entire configuration is contained in the file etc/resolve.conf, whose job is principally to specify the IP addresses for one or more "local" DNS servers. You may manually configure /etc/resolve.conf with known DNS servers; however, if you use DHCP to configure a client, the DHCP handshaking process will add this information to /etc/resolve.conf automatically (you may still read it or even modify it after DHCP sets it up, but it will be reset on reboot). The library code modified by /etc/resolv.conf is called the "DNS resolver."

If more than one DNS server is configured in an /etc/resolv.conf file, secondary and tertiary DNS servers will be consulted if the primary server fails to provide an answer within the specified timeout period. A maximum of three DNS servers may be configured.

The basic entry within an /etc/resolv.conf file contains the nameserver <IP-addr> entries. Some other entries let you modify returned answers. For example, the directives domain and search let you expand names without dots in them (like machines on the local LAN). The options directive lets you change timeouts per DNS server, turn on debugging, decide when to append full domain names, and change other aspects of DNS resolver behavior. For example, one of my machines is configured with:

Listing 1. Modifying options to configure DNS servers
# cat /etc/resolv.conf
search gnosis.lan
options timeout:3

The first directive lets this machine know that machines on the local LAN use the private domain gnosis.lan, so the simple name bacchus may be resolved as bacchus.gnosis.lan. More than one space-separated domain may be listed in the search directive.

Next, I list several DNS servers to try. The first is the local machine itself, which can be referred to either as or by its official IP address, but not with a loopback address. The next nameserver directive lists my home-office router that connects my LAN to the Internet (and provides DHCP and DNS services). The tertiary nameserver is one provided by my ISP. I also set an option to use a three-second timeout on each nameserver rather than the default five seconds.

DNS client utilities

BIND 9 comes with four main client utilities. Three of those -- dig, nslookup, and host -- perform similar functions, more or less in descending order of detail. All three utilities are simply command-line utilities to exercise the DNS resolver. Essentially they do what many client applications do internally: these utilities simply provide output on the results of lookups on STDOUT. The most powerful of the three utilities, dig, also has the most options to limit or configure its output.

These utilities are most often used to look up an IP address from a symbolic domain name, but you may also perform reverse lookups or other record types other than default "A" records. For example, the command host -t MX will show you mail servers associated with Some examples might help:

Listing 2. host query of
$ host has address has address

Listing 3. host MX query of
$ host -t MX mail is handled by 10

For the nslookup utility:

Listing 4. nslookup using default (machine-local) server
$ nslookup

Non-authoritative answer:

Or a reverse lookup using the dig utility and specifying a non-default nameserver:

Listing 5. dig reverse lookup specifying a non-default nameserver
$ dig @ -x

; <<>> DiG 9.2.4 <<>> @ -x
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 3950
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

;    IN  PTR

2004041601 21600 3600 1038800 86400

;; Query time: 1 msec
;; WHEN: Thu Nov 10 02:00:27 2005
;; MSG SIZE  rcvd: 104

The remaining BIND 9 utility to keep in mind is rndc. The rndc utility controls the operation of a name server. It supersedes the ndc utility that was provided in older BIND releases. If rndc is invoked with no command-line options or arguments, it prints a short summary of the supported commands. See the manpage for rndc for full information on its use.

3 of 8 | Previous | Next


TutorialTitle=LPI exam prep: Domain Name System (DNS)