Systems Administration Toolkit: Understanding DNS

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.

Martin Brown (, Professional Writer, Freelance

Martin Brown has been a professional writer for more than seven years. He is the author of numerous books and articles across a range of topics. His expertise spans myriad development languages and platforms—Perl, Python, Java™, JavaScript, Basic, Pascal, Modula-2, C, C++, Rebol, Gawk, Shellscript, Windows®, Solaris, Linux, BeOS, Mac OS X and more—as well as Web programming, systems management, and integration. He is a Subject Matter Expert (SME) for Microsoft® and regular contributor to,, and IBM developerWorks. He is also a regular blogger at Computerworld, The Apple Blog, and other sites. You can contact him through his Web site.

04 March 2008

Also available in Chinese

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

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.

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,, 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,, 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, 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, is a subdomain of the com TLD, and is a subdomain of the 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 and are both hosts within the domain. Similarly, it is easy to identify that and are both hosts within the domain.

The delegation relates to the way in which administrators (and computers) are responsible for the configuration and contents of the various domains. The domain is a subdomain of the com TLD. The administrators of the com TLD have given permission for the domain and subdomains of the 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, 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 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
    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 domain.
  5. The DNS server sends an iterative request to the DNS server for the domain to resolve the address
  6. It uses an iterative request because it already knows that the DNS server is authoritative for the domain.
  7. The DNS server returns the IP address to the DNS server.
  8. The DNS server returns the IP address to the client.

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.

Listing 1. Simple configuration file
options {
     directory "/var/bind";

     forwarders {;;

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

     allow-query {

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

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.

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, 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/";
        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/

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.

Listing 3. Zone file
$TTL 86400
mcslp.pri.     IN     SOA     bear.mcslp.pri.
admin.mcslp.pri.     (
               3h     ;                         refresh
               1h     ;                         retry
               1w     ;                         expiry
               1h      ) ;                      minimum
mcslp.pri.          IN     NS     bear.mcslp.pri.     
mcslp.pri.          IN     A
bear.mcslp.pri.     IN     A
airong.wireless     IN     A     
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

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

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

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

Defines the IP address of bear.mcslp.pri as

airong.wireless     IN     A     

Defines the IP address of airong.wireless.mcslp.pri to 
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        IN      SOA     bear.mcslp.pri.
           (       2007111900      ; serial
                   3h              ; refresh
                   1h              ; retry
                   1w              ; expiry
                   1h       )      ; minimum     IN      NS      bear.mcslp.pri.   IN      PTR     bear.mcslp.pri.

The domain is the portions of your IP address class, in reverse order, and then placed within the domain. For example, IP addresses in the class C address 192.168.0.x are defined within the 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).

Listing 6. Adding reverse domain mapping
zone "" 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 (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 "";

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

zone "" IN {
        type master;
        file "pri/";
        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

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.

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

;bear.mcslp.pri.                        IN      A

bear.mcslp.pri.         86400   IN      A

mcslp.pri.              86400   IN      NS      bear.mcslp.pri.

;; Query time: 1 msec
;; 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 {; };

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 connected using
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 end of transfer

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


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.



Get products and technologies

  • ISC BIND is the primary DNS server daemon on the Internet and is included as standard in many Unix and Linux distributions.
  • 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



developerWorks: Sign in

Required fields are indicated with an asterisk (*).

Need an IBM ID?
Forgot your IBM ID?

Forgot your password?
Change your password

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


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

All information submitted is secure.

Choose your display name

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.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

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


All information submitted is secure.

Dig deeper into AIX and Unix on developerWorks

Zone=AIX and UNIX
ArticleTitle=Systems Administration Toolkit: Understanding DNS