Chapter 11. The Domain Name System

Table of Contents
11.1. Notes and Pre-Requisites
11.2. What is DNS?
11.3. The DNS Files
11.4. Using DNS
11.5. Setting up a caching only name server

This chapter (The Domain Name System) has been contributed by Jason R. Fink

The Domain Name System on NetBSD. This chapter describes setting up a simple small domain with one Domain Name Server (DNS) on a NetBSD system. It does not provide a detailed overview of what DNS is, however, a brief explanation is offered. Further information can be obtained from the DNS Resources Directory (DNSRD) at

11.1. Notes and Pre-Requisites

The examples in this chapter refer to BIND major version 8, however, it should be noted that the data- base format and named.conf are almost 100% compatible between version. The only difference I noticed was that the "$TTL" information was not required.

The reader should have a good understanding of basic hosts to IP address mapping and IP address class specifications.

11.2. What is DNS?

The Domain Name System converts machine names to IP addresses. The mapping is done from name to address and address to name. The difference between just plain hosts IP mapping and Domain mapping is that DNS uses a hierarchichal naming standard. This hierarchy works from right-to-left with the highest level being on the right. As an example, here is a simple domain break-out:

TOP-LEVEL                                .org
                    |                      |                        |

It seems simple enough, however, the system can also be logically divided even further if one wishes at different points. The example shown above shows three nodes on the domain, but we could even divide into subdomains such as, and, in this case, 2 nodes reside on and one on

11.3. The DNS Files

Now let's look at actually setting up a small DNS enabled network. We will continue to use the examples mentioned above, before we begin we must make a few assumptions:

Note: this type of configuration was described in Chapter 10.

Our Name Server will be the "strider" host, it also runs IPNAT and our two clients use strider as a gateway. It is not really relevant as to what type of interface is on strider, but for argument's sake we will say a 56k dial up connection.

So, before going any further, let's look at our hosts file on strider before we have made the alterations to use DNS.

Example 11-1. strider's /etc/hosts file       localhost     strider     samwise sam     wormtongue worm      

not exactly a huge network, it is worth noting that the same rules apply for larger networks as we discuss in the context of this section.

11.3.1. /etc/namedb/named.conf

The NetBSD Operating System provides a set of default files for you to use or go from, they are stored in /etc/namedb, I strongly suggest making a backup copy of this directory for reference purposes.

The default directory contains the following files:

  • 127

  • localhost

  • loopback.v6

  • named.conf

  • root.cache

You will see modified versions of these files in my configuration.

The first file we want to look at is /etc/namedb/named.conf. This file is the config file for bind (hence the catchy name). Setting up system like the one we are doing is relatively simple. First, here is what mine looks like:

options {
        directory "/etc/namedb";
        allow-transfer {; };
        recursion yes;
        allow-query {; };
        listen-on port 53 {; };

zone "localhost" {
   type master;
   notify no;
   file "localhost";

zone "127.IN-ADDR.ARPA" {
   type master;
   notify no;
   file "127";

zone "" {
   type master;
   file "loopback.v6";

zone "" {
   type master;
   notify no;
   file "";

zone "" {
   type master;
   notify no;
   file "1.168.192";

zone "." in {
   type hint;
   file "root.cache";

Note that in my named.conf the root section is last, that is because there is another domain called on the internet (I happen to own it) so I want the resolver to look out on the internet last. This is not normally the case on most systems.

Another very important thing to remember here is that if you have an internal setup, in other words no live internet connection and/or no need to do root server lookups, comment out the root zone. It may cause lookup problems if a particular client decides it wants to reference a domain on the internet.

Looks like a pretty big mess, upon closer examination it is revealed that many of the lines in each section are somewhat redundant. So we should only have to explain them a few times.

Lets go through the sections of named.conf: options

This section defines some global parameters, most noticeable is the location of the DNS tables, on this particular system, they will be put in /etc/named.

Following are the rest of the params:


for remote DNS servers acting as secondaries and need zone file information from you.


what network may query this name server

listen-on port

the port this server will run named on

The rest of the named.conf file consists of "zones", each zone has a file associated with and tables within that file for resolving that particular area (or, zone) of the domain. As is readily apparent, their format in named.conf is strikingly similar, so I will highlight just one of their records: zone ""


the type of zone in all cases except "." they are master


do you want to send out notifications when your zone changes? Obviously not in this setup.


the filename in our named directory where records about this particular zone may be found.

11.3.2. /etc/namedb/localhost

For the most part, the zone files look quite similar, however, each one does have some unique properties. Here is what the localhost file looks like:

Example 11-2. localhost

1|$TTL    3600
 2|@              IN SOA (
 3|                        1       ; Serial
 4|                        8H      ; Refresh
 5|                        2H      ; Retry
 6|                        1W      ; Expire
 7|                        1D)     ; Minimum TTL
 8|                        IN NS   localhost.
 9|localhost.      	   IN      A
10|                        IN      AAAA    ::1        

Line by line:

Line 1

This is the Time To Live for lookups, this is generally the same in all of the files.

Line 2

This line is generally the same in all zone files except root. Of specific interest on this line are and Obviously one is the name of this server and the other is the contact for this DNS server, in most cases root seems a little ambiguous, it is preferred that a regular email account be used for the contact information (for example, mine would be

Line 3

This line is the serial number, most people use the date they installed the server in a format like so: MMDDYYYY. The serial number should be incremented each time there is a change to the file after it has been initially installed. That is why I prefer to just start with 1.

Line 4

This is the refresh rate of the server, in this file it is set to once every 8 hours.

Line 5

The retry rate.

Line 6

Lookup expiry.

Line 7

The minimum Time To Live

Line 8

This is the Nameserver line, as you can see it is set to localhost.

Line 9

This is the local host entry.

Line 10

This line is the ipv6 entry.

11.3.3. /etc/named/zone.127.0.0

This is the reverse lookup file (or zone) for the localhost. It looks like this:

1| $TTL    3600
 2| @              IN SOA (
 3|                        1       ; Serial
 4|                        8H      ; Refresh
 5|                        2H      ; Retry
 6|                        1W      ; Expire
 7|                        1D)     ; Minimum TTL
 8|                 IN NS   localhost.
 9| 1.0.0           IN PTR  localhost.      

In this file, all of the lines are the same as the localhost zonefile with exception of line 9, this is the reverse lookup record. It is defined in a separate file because it is the localhost and has a totally different address than the remaining zones. Something we will discuss after looking at all of the zone files.

11.3.4. /etc/namedb/

This zone file is populated by records for all of our hosts on the network. Here is what it looks like:

1| $TTL    3600
 2| @              IN SOA (
 3|                         1       ; serial
 4|                         8H      ; refresh
 5|                         2H      ; retry
 6|                         1W      ; expire
 7|                         1D )    ; minimum seconds
 8|                 IN NS
 9|                 IN MX   10   ; primary mail server
10|                 IN MX   20   ; secondary mail server
11| strider         IN A
12| maila           IN CNAME
13| samwise         IN A
14| www             IN CNAME
15| mailb
16| worm            IN A      

There is a lot of new stuff here, so lets just look over each line that is new here:

Line 12

This line shows our mail handler, in this case it is strider, but for scaling reasons, we want to call it maila. As you will see below this is not a big deal, the number that precedes is the priority number, the lower the number their higher the priority. The way we are setup here is if strider cannot handle the mail, then mailb (which is really samwise) will.

Line 12

CNAME stands for canonical name, or in lamens, an alias. So we have aliased the following: to to   to              

The rest of the records are simply mappings of IP address to a full name.

11.3.5. /etc/namedb/1.168.192

This zone file is the reverse file for all of the host records, the format is similar to that of the localhost version with the obvious exception being the addresses are different:

1|$TTL    3600
 2|@              IN SOA (
 3|                     1       ; serial
 4|                     8H      ; refresh
 5|                     2H      ; retry
 6|                     1W      ; expire
 7|                     1D )    ; minimum seconds
 8|                IN NS
 9|1               IN PTR
10|2               IN PTR
11|3               IN PTR      

11.3.6. /etc/namedb/root.cache

This file is a list of root servers for your server to query when it gets requests outside of it's own domain. Here are first few lines of a root zone file:

;       $NetBSD: root.cache,v 1.8 1997/08/24 15:50:47 perry Exp $
;       This file holds the information on root name servers needed to
;       initialize cache of Internet domain name servers
;       (e.g. reference this file in the "cache  .  file"
;       configuration file of BIND domain name servers).
;       This file is made available by InterNIC registration services
;       under anonymous FTP as
;           file                /domain/named.root
;           on server           FTP.RS.INTERNIC.NET
;       -OR- under Gopher at    RS.INTERNIC.NET
;           under menu          InterNIC Registration Services (NSI)
;              submenu          InterNIC Registration Archives
;           file                named.root
;       last update:    Aug 22, 1997
;       related version of root zone:   1997082200
; formerly NS.INTERNIC.NET
.                        3600000  IN  NS    A.ROOT-SERVERS.NET.
A.ROOT-SERVERS.NET.      3600000      A
; formerly NS1.ISI.EDU
.                        3600000      NS    B.ROOT-SERVERS.NET.
B.ROOT-SERVERS.NET.      3600000      A
; formerly C.PSI.NET
.                        3600000      NS    C.ROOT-SERVERS.NET.
C.ROOT-SERVERS.NET.      3600000      A
. . .      

This file can be obtained from ISC at and usually comes with a distribution of BIND. A root.cache file is included with the NetBSD core Operating System.

11.4. Using DNS

In this section we will look at how to get DNS going and setup strider to use it's own services.

NetBSD already provides a dns caching server install (shown in the next section). Along with this are the tools to manage the server at runtime. Before that can start, however, we must look at how to properly initialize the server.

Setting up named to start automatically is quite simple. In /etc/defaults/rc.conf simply go to the line named and replace NO with YES. Additional options can be specified on that line in between the quotes, for example, I like to use -g nogroup -u nobody, so a non root account runs the named process.

In addition to being able to startup named at boot time, it can also be controlled with the ndc facility. In a nutshell the ndc facility can stop, start or restart the named server process. It can also do a great many other things (see the ndc man page for more details).

The general usage is ndc.

Next we want to point strider to itself for lookups. We have two simple steps, first, decide on our resolution order. On a network this small, it is likely that each host has a copy of the hosts table, so we can get away with using hosts then dns, however, on larger networks it is much easier to use DNS. Either way, the file where this is determined is /etc/nsswitch.conf (see Example 10-2.) Here is part of a typical nsswitch.conf:

. . .
group_compat:   nis
hosts:          files dns
netgroup:       files [notfound=return] nis
. . .    

the line we are concerned with is hosts, files means the system uses /etc/hosts to determine ip to name translation. The entry on the left is the first method of resolution.

The next file is /etc/resolv.conf, this file is the dns resolution file, the format is pretty self explanatory but we will go over it anyway:


In a nutshell this file is telling the resolver that this machine belongs to, should search it before looking elsewhere and the nameserver address is .

To test our nameserver we can use several commands, for example:

# host    

here is the output of running host is a nickname for has address has address has address has address has address    

The procedure for setting up the client hosts are the same, setup /etc/nsswitch.conf and /etc/resolv.conf.

11.5. Setting up a caching only name server

A caching only name server has no local zones; all the queries go to the root servers and the replies are accumulated in the local cache. The next time the query is performed the answer will be faster because the data is already in the server's cache. Since this type of server doesn't handle local zones, to resolve the names of the local hosts it will still be necessary to use the already known /etc/hosts file.

Since NetBSD supplies defaults for all the files needed by a caching only server, the configuration of this type of DNS is very easy, and can be performed with a few commands, without writing a single line in the configuration files.

Note: the number of the configuration files and their contents varies between versions of NetBSD.

The program which supplies the DNS server is the named daemon, which uses the named.conf configuration file for its setup. The default file supplied by NetBSD is located in the /etc/namedb directory, but the daemon looks for it in the /etc/ directory, so we start by creating a link:

# ln -s /etc/namedb/named.conf /etc/named.conf    

The name server is ready for use! We can now tell to the system to use it adding the following line to the /etc/resolv.conf file:


Now we can start named.

# named    

Note: we have now started the name server manually. Once we have tested it and are confident that it works, we can launch it automatically at boot using the relevant option of the /etc/rc.conf file.

11.5.1. Testing the server

Now that the server is running we can test it using the nslookup program.

# nslookup
Default server: localhost


Let's try to resolve an host name, for example (try a site near you.)

Server:  localhost


If you repeat the query a second time, the result is slightly different:

Server:  localhost

Non-authoritative answer:

As you've probably noticed, the address is the same, but the message "Non-authoritative answer", has appeared. This message indicates that the answer is not coming from an authoritative server for the domain but from the cache of our own server.

The results of this first test confirm that the server is working correctly.

We can also try the host command, which gives the following result.

# host has address