System Administration Toolkit: Understanding DNS

Martin Brown March 04, 2008

The Domain Name System (DNS) is the service that converts hostnames and domain details
into the IP addresses required for application to communicate. Under UNIX®, the primary DNS
service is based on BIND, and DNS itself is a key part of most UNIX installations. This article
looks at the basics of DNS setup, how servers and requests are distributed, and exchanged
and how to set up and keep a DNS environment running smoothly.
View more content in this series

About this series

The typical UNIX administrator has a key range of utilities, tricks, and systems he or she uses
regularly to aid in the process of administration. There are key utilities, command line chains, and
scripts that are used to simplify different processes. Some of these tools come with the operating
system, but a majority of the tricks come through years of experience and a desire to ease the
system administrator's life. The focus of this series is on getting the most from the available tools
across a range of different UNIX environments, including methods of simplifying administration in a
heterogeneous environment.

DNS basics
As a general rule, humans are not particularly good at remembering numbers. Unfortunately, the
IP addressing system uses numbers to identify individual hosts. Remembering numbers for all
of the machines that you might want to use both inside and outside of your network is obviously
impractical. Instead, it's easier to remember the name of your server as 'bear' or the address of a
Web site on the Internet as www.mcslp.com.

Historically, UNIX has used three main locations for this type of information. The built-in /etc/hosts
file is the main source and a useful backup, but keeping it up to date across multiple machines
requires a lot of copying of data. A distributed system, where individual machines and services
can contact a central point, is the better method and two systems, the Network Information System
(NIS) and DNS, were developed with different goals in mind.

NIS is a general-purpose database-sharing service and can be used to share host, password, and
other normally text-based databases. Unfortunately, NIS is not as effective across systems, and
certainly not in the distributed format of the Internet.

© Copyright IBM Corporation 2008 Trademarks

System Administration Toolkit: Understanding DNS Page 1 of 12
developerWorks® ibm.com/developerWorks/

The Domain Name System (DNS) resolves that by providing a mechanism so that names can be
resolved to the appropriate IP address. Addresses within the domain name system are organized
in a tree structure. Although you can organize any private DNS in the format that you want, it is
easiest to understand the DNS system by looking at the structure used on the Internet.

Looking at a typical DNS address, www.mcslp.com, the name can be divided by splitting up the
contents by a period, starting with the fragment on the far right (com).

From our example, www.mcslp.com, the 'com' is example of a top-level domain (TLD) name
that organizes the names by organizational or regional structure. For example, valid TLDs
included com (commercial), edu (educational) and net (network related). On the Internet, regional
organization provides for country-specific TLDs, such uk for the United Kingdom or fr for France.

Each fragment to the left of the TLD is a subdivision of the original domain. For example,
mcslp.com is a subdivision of the com TLD. Further subdivisions can occur, up to a maximum
of 127 levels. Each subdivision is known as a subdomain. From the example, mcslp.com is a
subdomain of the com TLD, and www.mcslp.com is a subdomain of the mcslp.com subdomain.

The use of subdomains has two main purposes; one is for ease of identification and the other is for
the purposes of delegation. From an identification perspective, it is much easier to understand and
identify that www.mcslp.com and bear.mcslp.com are both hosts within the mcslp.com domain.
Similarly, it is easy to identify that www.google.com and mail.google.com are both hosts within the
google.com domain.

The delegation relates to the way in which administrators (and computers) are responsible for
the configuration and contents of the various domains. The mclsp.com domain is a subdomain
of the com TLD. The administrators of the com TLD have given permission for the domain and
subdomains of the mcslp.com domain to be the responsibility of another administrator.

This delegation is what enables administrators of services on the Internet to 'own' a domain and in
turn assign their own IP addresses, configure their own names, and organize their own structure to
help them identify the machines within their network.

Internally, the domain name system can also be used as a method for identifying and locating
machines on your network, and you can use the organization and delegation features of DNS to
help organize your network.

For example, mcslp.com is the public domain for a company, while mcslp.pri is the private domain
used internally to identify machines within the network. The address www.mcslp.pri relates to an
internal Web server, and mail.mcslp.pri relates to an internal mail server. In addition, a subdomain,
vm.mcslp.pri, is used to provide a logical grouping of hosts (in this case, virtual machines).

How domain name resolution works

Domain name resolution works by a client contacting a server and requesting that a particular
address be resolved to the corresponding part (i.e., name to IP address, or IP address to name).
Because name servers can hold different types of information, the exact response and process

System Administration Toolkit: Understanding DNS Page 2 of 12

ibm.com/developerWorks/ developerWorks®

depends on the query, but for the examples we will assume a simple name lookup that is expecting
an IP address in response.

In general, the client asks the server to resolve an address and receives the resolved address
back from the server. Queries can be of two types: recursive and non-recursive. In a recursive
query, the client expects the server to respond the full answer (i.e., to resolve a name to the IP
address). Non-recursive queries allow the server to return a partial response, such as returning the
name or address of the server that may know the answer (or may have more information).

The reason for this is that the DNS systems work on a system with an analogy similar to Chinese
whispers. If the server doesn't know the answer itself (because it is not responsible for the
domain), then it will find out which server is responsible for the domain and ask that server instead.
In a recursive query, the server does the asking and returns the final result. Non-recursive queries
are generally used by servers when talking to each other to resolve a query on behalf of a client.

You can see this more clearly by looking at Figure 1. The numbers in the diagram relate to the
same steps within the list below.

1. The client checks its own cache to see if it has resolved the name recently but doesn't find
anything.
2. The client sends a recursive query to its primary name server.
3. The name server checks its database and cache, doesn't find anything, and sends an iterative
request to a root server for the .com top-level domain.
Figure 1. Recursive and non-recursive queries

4. The root server responds to the DNS server with the IP address of the DNS server that is
authoritative for the mcslp.com domain.
5. The DNS server sends an iterative request to the DNS server for the mcslp.com domain to
resolve the address www.mcslp.com.
6. It uses an iterative request because it already knows that the mcslp.com DNS server is
authoritative for the domain.
7. The mcslp.com DNS server returns the IP address to the DNS server.
8. The DNS server returns the IP address to the client.

System Administration Toolkit: Understanding DNS Page 3 of 12

developerWorks® ibm.com/developerWorks/

Caching of DNS requests

Because it's likely that the same hostname can be requested multiple times within a short
period of time (for example, when loading all of the content of a typical Web page), DNS
information is cached, both locally by the client and on the server. Caching on the client
occurs to prevent making multiple requests when the information is already known. Caching
on DNS servers occurs within a controllable limit called the Time To Live (TTL). This sets the
period that a DNS entry will be retained in the cache before a query to resolve the entry is
requested again from a server with responsibility for the domain being queries. The downside
of the TTL and caching is that different users may see different information, based on which
DNS server they requested a name resolution from, and when the original request took
place.

Setting up a DNS server

Earlier in this article, I discussed the role of delegation and the subdivision of domains and
subdomains to allow individual administrators to be responsible for their own domains and the
information and hosts defined within that domain. Setting up your own domain server can be useful
both if you are hosting a public DNS domain available on the Internet, and if you want to configure
your own DNS information to resolve the addresses and other information within your private
network.

To set up a DNS server within a UNIX server or client, you need a DNS daemon, which
answer queries about one or more domains. The most common daemon is BIND, and most
implementations of a DNS server use BIND or a derivative of the BIND code as the basis for
their DNS service. The core of the BIND service is a daemon called named (or in.named), which
handles all of the queries.

The configuration of a typical BIND environment involves the main named configuration file,
usually /etc/named.conf (or /etc/bind/named.conf) and a number of 'zone' files, which hold the
individual information about each DNS domain that the server is responsible for.

The main configuration file sets up the directories used for the zone files, security information,
and also the additional servers that should be queried if the DNS server is unable to resolve the
address itself. You need this setting if you want your server to resolve addresses outside of your
network (for example, on the Internet), in addition to those inside your network for the configured
zones.

You can see the header portion of a simple configuration file in Listing 1.

System Administration Toolkit: Understanding DNS Page 4 of 12

ibm.com/developerWorks/ developerWorks®

Listing 1. Simple configuration file

options {
directory "/var/bind";

forwarders {
212.23.3.100;
212.23.6.100;
};

listen-on-v6 { none; };
listen-on { 127.0.0.1; };

allow-query {
192.168.0.*;
192.168.1.*;
192.168.2.*;
};

pid-file "/var/run/named/named.pid";
};

Note that within the configuration file you need to use the double-slash (//) to introduce a comment.
You should also be aware that the semicolon is used to split up individual configuration options of
the file, and that braces are used to group configuration options together. Most problems with the
content of the configuration file are introduced when a semicolon or brace is missing.

The individual configurable options show in this example are as follows:

• directory -- This sets the base directory where the zone files can be found.
• forwarders -- This sets the list of DNS hosts that will be queried when a recursive query is
sent to the DNS server that the server is unable to answer. Usually you should set this to the
next highest DNS server in the hierarchy. For example, if the server was configured for the
subdomain servers.mcslp.pri, then you would set the forwarding to point to the DNS servers
of mcslp.pri for resolution. For most situations, you should set the forwarding addresses to
those of your ISP to allow Internet addresses to be resolved.
• listen-on-v6 -- Sets whether the server should listen on an IPv6 address. The 'none' setting
disables IPv6 support.
• listen-on -- Sets the IP addresses on which the server should listen for resolution requests. In
the example, the server will only listen to requests from localhost (i.e., the machine itself). If
you omit this configuration line, the server will listen on all configured IP interfaces. You can
use this to limit requests on certain interfaces if you are using the server as a router where
you only want certain interfaces to support DNS.
• allow-query -- This configures the hosts that are allowed to request DNS resolution. In
a network that may span multiple IP subnets, you may want to limit which servers are
responsible for handling queries to a specific subnet to allow for the load to be spread among
multiple servers.
• pid-file -- Sets the location of the file to hold the process ID of the running named daemon.
This is useful if you want to be able to kill or reload the zone information because you can
locate the PID of the server using this file.
The remainder of the configuration file contains the zone file data that will be used by your server
to share DNS information.

System Administration Toolkit: Understanding DNS Page 5 of 12

developerWorks® ibm.com/developerWorks/

Setting up the DNS data

DNS information is stored within a series of 'zone' files. Typically you have one zone file for each
domain that you host.

• Forward zones -- These primarily map domain names to IP addresses. In addition, other
domain-level information, such as valid nameservers, mail server priorities for the domain,
and so on is stored in these files. Normally you would use a single zone file for a forward
domain. For example, mcslp.com or an internal mcslp.pri zone.
• Reverse zones -- These map IP addresses back to names. For security reasons, many
services, including NFS, OpenSSH, and Web servers can be configured to check whether
the IP address of a request resolves back to a name, and, where relevant, that the request
host and IP/address match both forwards and backwards. For reverse zones, you only create
records recording the relationship between the IP address and the host.
• Root zones -- These provide the list of 'root' servers that hold information about subdomains
on the Internet and their delegation records. By providing a root zone file, you can let your
DNS server query the root Internet servers for information about other hosts on the internet.

All configured zones within your configuration are designated either as master or secondary.
Master zones are those for which the server is a master host (i.e., the delegated server for
the domain). Only one server can be the master for a domain; additional servers that can be
authoritative for a domain (that is, they provide qualified responses) are classed as 'secondary,' or
slave, servers. You can use the slave servers to help spread the load and provide resilience in the
event of a failure. We'll return to this issue later in this article.

For each zone file that you host, you must add a zone portion to the named.conf file (see Listing
2).

Listing 2. Adding a zone portion to the named.conf file

zone "mcslp.pri" in {
file "pri/mcslp.pri.zone";
type master;
};

This configures the zone mcslp.pri (an internal subdomain used to identify computers only on the
local network), the file in which the zone data is located (relative to the directory option), and the
type of the file.

In this case, the actual file will be located in /var/bind/pri/mcslp.pri.zone.

An example of the contents of the file, in this case a 'forward' zone, primarily mapping names to IP
addresses, are shown in Listing 3.

System Administration Toolkit: Understanding DNS Page 6 of 12

ibm.com/developerWorks/ developerWorks®

Listing 3. Zone file

$TTL 86400
mcslp.pri. IN SOA bear.mcslp.pri.
admin.mcslp.pri. (
2008021401;
serial
3h ; refresh
1h ; retry
1w ; expiry
1h ) ; minimum
mcslp.pri. IN NS bear.mcslp.pri.
mcslp.pri. IN A 192.168.0.2
bear.mcslp.pri. IN A 192.168.0.2
airong.wireless IN A 192.168.0.210
...
mail IN CNAME bear
www IN CNAME bear
mcslp.pri. IN MX 10 bear

The header block of the zone file specifies the information about the domain. In this case, we
specify the domain name and the SOA (Start of authority) information. The SOA configures the
data about the domain to define which servers are classed as authoritative (that is, then give
qualified responses to queries for this domain). The remainder of the SOA record configures a
serial number (used by other DNS servers to determine whether their copy of the domain data is
up to date), and the refresh and retry intervals (in seconds) for updating the information.

From our example, there is only one server qualified to give responses about hosts and other data
within the domain, bear.mcslp.pri. The hostname, rather than IP address, is provided so that you
can change the host IP address without having to update the DNS SOA record.

The remainder of the information within the zone file then configures the specific DNS records.
DNS is capable of holding much more information than simple name to address data, and
therefore the DNS records are organized into different types.

A list of the main types includes:

• A (address) -- Specifies the IP address for a given name.

• NS (nameserver) -- Specifies the nameserver for a given domain.
• CNAME (canonical name) -- An alias to an existing host.
• MX (mail exchanger) -- The hostname of a server responsible for handling e-mail for the
domain.
For names within the domain, you can specify a name that is implied to be within the domain
simply by specifying the name, for example: bear IN A 192.168.0.2.

Because the DNS knows that this file contains information for the mcslp.pri domain, the full
hostname is expanded to bear.mcslp.pri.

You can also specify the fully qualified domain name (FQDN) by setting the full hostname and
appending a period to the end of the name: amazon IN CNAME www.amazon.com

The above will configure the amazon.mcslp.pri hostname to act as an alias to www.amazon.com.

System Administration Toolkit: Understanding DNS Page 7 of 12

developerWorks® ibm.com/developerWorks/

Returning to the original list of hosts, the hosts are configured as follows in Listing 4.

Listing 4. Configuring the hosts

bear.mcslp.pri. IN A 192.168.0.2

Defines the IP address of bear.mcslp.pri as 192.168.0.2

airong.wireless IN A 192.168.0.210

Defines the IP address of airong.wireless.mcslp.pri to 192.168.0.210.

This is an example of setting up a subdomain within our original mcslp.pri
domain for organizational purposes. In this case, the wireless.mcslp.pri
is used to hold the details of wireless devices.

mail IN CNAME bear

www IN CNAME bear

Creates aliases to bear.mcslp.pri. These are examples of utility aliases

that can be used to identify different services. By using an alias, you
can change the host ultimately responsible for these services without having
to reconfigure clients with the updated host.

mcslp.pri. IN MX 10 bear

The mail exchanger records are used by mail transport agents like sendmail and postfix when
looking up where to send e-mail. In the above example, bear.mcslp.pri is configured to accept any
e-mail where the domain within the e-mail address is mcslp.pri.

For 'reverse' lookups, that is, when you want to resolve an IP address to a name, you should set
up an additional zone. Reverse zones have a specific domain name that identifies them as reverse
zones. You can see an example of this in Listing 5.

Listing 5. Reverse zones

$TTL 86400
0.168.192.in-addr.arpa. IN SOA bear.mcslp.pri.
admin.mcslp.pri.
( 2007111900 ; serial
3h ; refresh
1h ; retry
1w ; expiry
1h ) ; minimum
0.168.192.in-addr.arpa. IN NS bear.mcslp.pri.
2.0.168.192.in-addr.arpa. IN PTR bear.mcslp.pri.

The domain is the portions of your IP address class, in reverse order, and then placed within the
in-addr.arpa domain. For example, IP addresses in the class C address 192.168.0.x are defined
within the 0.168.192.in-addr.arpa domain, as shown in Listing 4.

The header and NS (name server) records are as before. IP address to hostname mappings
are defined use the PTR (pointer) record. You should have one of these records for each
corresponding name to IP address entry within your domain.

To add your reverse domain mapping to your named config, specify the domain and domain file in
the same way within your named.conf file (see Listing 6).

System Administration Toolkit: Understanding DNS Page 8 of 12

ibm.com/developerWorks/ developerWorks®

Listing 6. Adding reverse domain mapping

zone "0.168.192.in-addr.arpa" IN {
file "pri/db.192.168.0";
type master;
};

You should also configure the 'hint' zone, which refers to the root servers and a localhost forward
and reverse domain so that resolution of localhost and 127.0.0.1 (the localhost IP address)
operate correctly. You can find examples of these in the bind source, and usually also provided
with your bind installation. Listing 7 shows the named.conf zone entries.

Listing 7. named.conf zone entries

zone "." IN {
type hint;
file "named.ca";
};

zone "localhost" IN {
type master;
file "pri/localhost.zone";
allow-update { none; };
notify no;
};

zone "127.in-addr.arpa" IN {
type master;
file "pri/127.zone";
allow-update { none; };
notify no;
};

Once the zones are configured and you have added the zone file, you can start up the named
daemon. For most UNIX/Linux variants, you can do this using the script in /etc/init.d: # /etc/
init.d/named start.

For Solaris 10, use svcadm: # svcadm enable bind.

Once the named daemon is running, make sure you edit your /etc/resolv.conf file (see Listing 8) to
configure the domain and DNS servers that provide responses:

Listing 8. Edit your /etc/resolv.conf file to configure the domain and DNS
servers
domain mcslp.pri
nameserver 192.168.0.2

You may also need to edit your /etc/nsswitch.conf file so that hostname lookups are redirected to
the DNS service. For example, to use the local files first and then resort to DNS: hosts: files
dns.

You should now be able to look up hosts from the DNS using dig, a tool that queries DNS servers
for information. Listing 9 shows the result when looking up bear.mcslp.pri.

System Administration Toolkit: Understanding DNS Page 9 of 12

developerWorks® ibm.com/developerWorks/

Listing 9. Result when looking up bear.mcslop.pri

# dig bear.mcslp.pri

; <<>> DiG 9.3.4-P1 <<>> bear.mcslp.pri

;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 858
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;bear.mcslp.pri. IN A

;; ANSWER SECTION:
bear.mcslp.pri. 86400 IN A 192.168.0.2

;; AUTHORITY SECTION:
mcslp.pri. 86400 IN NS bear.mcslp.pri.

;; Query time: 1 msec

;; SERVER: 192.168.0.2#53(192.168.0.2)
;; WHEN: Wed Feb 20 18:08:34 2008
;; MSG SIZE rcvd: 62

The output shows the server that was queried, and the full DNS record returned.

Spreading the load

DNS is a distributed service, in that more than one server is capable of responding to a given
query, providing it knows who to ask for the information. In addition to forwarding DNS requests
and the recursive nature, you can also configure more than one server to be 'authoritative' for a
particular domain. Secondary or slave servers are delegated through the domains NS records as
being qualified to give responses.

Secondary DNS servers transfer their zone information directly from the primary DNS server
and keep a copy locally. Clients can then be configured to use one or more of the DNS servers
responsible for a domain. This can help to reduce the load on requests and also ensures that if the
primary server (or another slave) is down when a query is made, another server can provide an
answer to the client resolution query.

To add more DNS servers to your configuration, first edit your zone files and add NS records
for each slave that will also be hosting the domain. This ensures that your slaves will return
authoritative answers to queries for that domain.

Then, add an entry to your named.conf file that specifies the domain name with a type of 'slave'
and then providing a list of qualified 'masters' that can transfer a copy of the domain to the slave.
For an example, setting up a slave for the mcslp.pri domain (see Listing 10).

Listing 10. Setting up a slave for the mcslp.pri domain

zone "mcslp.pri" IN {
type slave;
file "sec/mcslp.pri";
masters { 192.168.0.2; };
};

System Administration Toolkit: Understanding DNS Page 10 of 12

ibm.com/developerWorks/ developerWorks®

Now reload or start the named service on your slave server and check the logs. You should see
entries reporting the successful transfer of the domain to your slave (see Listing 11).

Listing 11. Reloading the named service on your slave server

Feb 20 18:17:41 tweedledum named[27142]: running
Feb 20 18:17:41 tweedledum named[27142]: zone mcslp.pri/IN: Transfer started.
Feb 20 18:17:41 tweedledum named[27142]: transfer of 'mcslp.pri/IN'
from 192.168.0.2#53: connected using 192.168.0.6#53905
Feb 20 18:17:41 tweedledum named[27142]: zone mcslp.pri/IN:
transferred serial 2008022000
Feb 20 18:17:41 tweedledum named[27142]: transfer of 'mcslp.pri/IN'
from 192.168.0.2#53: end of transfer

Now you can add the IP address of your new slave server to the list of valid IP addresses to query.

Summary
The DNS system, at its heart, resolves the names with which we are all familiar on the Internet and
locally on our networks to an IP address. Although we take the system for granted, it is in fact a
well-designed service that distributes and delegates queries and zones around the Internet and
enables you to create custom zones within your own network.

In this article we've seen how the fundamentals of the DNS service work, and how that relates
not only to the internal process of resolve local addresses but also to addresses on the Internet.
We've also examined how to create a simple DNS setup for use on your local network, and how
that integrates with Internet name resolution.

System Administration Toolkit: Understanding DNS Page 11 of 12

developerWorks® ibm.com/developerWorks/

Related topics
• ISC BIND is the primary DNS server daemon on the Internet and is included as standard in
many Unix and Linux distributions.
• System Administration Toolkit: Monitoring User Usage (Martin Brown, developerWorks,
October 2007) looks at ways of examining the utmp and wtmp files for information about users
and their activities.
• System Administration Toolkit: Monitoring Disk Usage (Martin Brown, developerWorks, June
2006) covers many techniques for investigating the disk space used on your machine.
• Read System Administration Toolkit: Standardizing your UNIX command-line tools (Martin
Brown, developerWorks, May 2006) to learn how to use the same command across multipled
machines.
• For an article series that will teach you how to program in bash, see Bash by example,
Part 1: Fundamental programming in the Bourne again shell (bash) (Daniel Robbins,
developerWorks, March 2000), Bash by example, Part 2: More bash programming
fundamentals (Daniel Robbins, developerWorks, April 2000), and Bash by example, Part 3:
Exploring the ebuild system (Daniel Robbins, developerWorks, May 2000).
• System Administration Toolkit: Check out other parts in this series.
• Different systems use different tools, and the IBM Redbook Solaris to Linux Migration: A
Guide for System Administrators will help you identify some key tools.
• syslog-ng is an open source implementation of the syslog service that includes improvements
and enhancements to make it a more general purpose logging mechanism

© Copyright IBM Corporation 2008

(www.ibm.com/legal/copytrade.shtml)
Trademarks
(www.ibm.com/developerworks/ibm/trademarks/)

System Administration Toolkit: Understanding DNS Page 12 of 12