1. The Domain Name System
    1. DNS Background and Concepts
      1. Naming Services
      2. The DNS namespace
      3. Resource Records
      4. Delegation
      5. Delegation to multiple servers
      6. Secondaries, Caching, and the SOA record
      7. Name Resolution
      8. Reverse Resolution
    2. The DNS Files
      1. /etc/named.conf
      2. /etc/namedb/localhost
      3. /etc/namedb/zone.127.0.0
      4. /etc/namedb/
      5. /etc/namedb/1.168.192
      6. /etc/namedb/root.cache
    3. Using DNS
    4. Setting up a caching only name server
      1. Testing the server

The Domain Name System

Use of the Domain Name System has been discussed in previous chapters, without going into detail on the setup of the server providing the service. This chapter describes setting up a simple, small domain with one Domain Name System (DNS) nameserver on a NetBSD system. It includes a brief explanation and overview of the DNS; further information can be obtained from the DNS Resources Directory (DNSRD) at

DNS Background and Concepts

The DNS is a widely used naming service on the Internet and other TCP/IP networks. The network protocols, data and file formats, and other aspects of the DNS are Internet Standards, specified in a number of RFC documents, and described by a number of other reference and tutorial works. The DNS has a distributed, client-server architecture. There are reference implementations for the server and client, but these are not part of the standard. There are a number of additional implementations available for many platforms.

Naming Services

Naming services are used to provide a mapping between textual names and configuration data of some form. A nameserver maintains this mapping, and clients request the nameserver to resolve a name into its attached data.

The reader should have a good understanding of basic hosts to IP address mapping and IP address class specifications, see Name Service Concepts.

In the case of the DNS, the configuration data bound to a name is in the form of standard Resource Records (RRs). These textual names conform to certain structural conventions.

The DNS namespace

The DNS presents a hierarchical name space, much like a UNIX filesystem, pictured as an inverted tree with the root at the top.

TOP-LEVEL                                .org
                    |                      |                        |

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 in "" and one in "".

There are directories of names, some of which may be sub-directories of further names. These directories are sometimes called zones. There is provision for symbolic links, redirecting requests for information on one name to the records bound to another name. Each name recognised by the DNS is called a Domain Name, whether it represents information about a specific host, or a directory of subordinate Domain Names (or both, or something else).

Unlike most filesystem naming schemes, however, Domain Names are written with the innermost name on the left, and progressively higher-level domains to the right, all the way up to the root directory if necessary. The separator used when writing Domain Names is a period, ".".

Like filesystem pathnames, Domain Names can be written in an absolute or relative manner, though there are some differences in detail. For instance, there is no way to indirectly refer to the parent domain like with the UNIX .. directory. Many (but not all) resolvers offer a search path facility, so that partially-specified names can be resolved relative to additional listed sub-domains other than the client's own domain. Names that are completely specified all the way to the root are called Fully Qualified Domain Names or FQDNs. A defining characteristic of an FQDN is that it is written with a terminating period. The same name, without the terminating period, may be considered relative to some other sub-domain. It is rare for this to occur without malicious intent, but in part because of this possibility, FQDNs are required as configuration parameters in some circumstances.

On the Internet, there are some established conventions for the names of the first few levels of the tree, at which point the hierarchy reaches the level of an individual organisation. This organisation is responsible for establishing and maintaining conventions further down the tree, within its own domain.

Resource Records

Resource Records for a domain are stored in a standardised format in an ASCII text file, often called a zone file. The following Resource Records are commonly used (a number of others are defined but not often used, or no longer used). In some cases, there may be multiple RR types associated with a name, and even multiple records of the same type.

Common DNS Resource Records


Using NS records, authority for portions of the DNS namespace below a certain point in the tree can be delegated, and further sub-parts below that delegated again. It is at this point that the distinction between a domain and a zone becomes important. Any name in the DNS is called a domain, and the term applies to that name and to any subordinate names below that one in the tree. The boundaries of a zone are narrower, and are defined by delegations. A zone starts with a delegation (or at the root), and encompasses all names in the domain below that point, excluding names below any subsequent delegations.

This distinction is important for implementation - a zone is a single administrative entity (with a single SOA record), and all data for the zone is referred to by a single file, called a zone file. A zone file may contain more than one period-separated level of the namespace tree, if desired, by including periods in the names in that zone file. In order to simplify administration and prevent overly-large zone files, it is quite legal for a DNS server to delegate to itself, splitting the domain into several zones kept on the same server.

Delegation to multiple servers

For redundancy, it is common (and often administratively required) that there be more than one nameserver providing information on a zone. It is also common that at least one of these servers be located at some distance (in terms of network topology) from the others, so that knowledge of that zone does not become unavailable in case of connectivity failure. Each nameserver will be listed in an NS record bound to the name of the zone, stored in the parent zone on the server responsible for the parent domain. In this way, those searching the name hierarchy from the top down can contact any one of the servers to continue narrowing their search. This is occasionally called walking the tree.

There are a number of nameservers on the Internet which are called root nameservers. These servers provide information on the very top levels of the domain namespace tree. These servers are special in that their addresses must be pre-configured into nameservers as a place to start finding other servers. Isolated networks that cannot access these servers may need to provide their own root nameservers.

Secondaries, Caching, and the SOA record

In order to maintain consistency between these servers, one is usually configured as the primary server, and all administrative changes are made on this server. The other servers are configured as secondaries, and transfer the contents of the zone from the primary. This operational model is not required, and if external considerations require it, multiple primaries can be used instead, but consistency must then be maintained by other means. DNS servers that store Resource Records for a zone, whether they be primary or secondary servers, are said to be authoritative for the zone. A DNS server can be authoritative for several zones.

When nameservers receive responses to queries, they can cache the results. This has a significant beneficial impact on the speed of queries, the query load on high-level nameservers, and network utilisation. It is also a major contributor to the memory usage of the nameserver process.

There are a number of parameters that are important to maintaining consistency amongst the secondaries and caches. The values for these parameters for a particular domain zone file are stored in the SOA record. These fields are:

Fields of the SOA Record

Name Resolution

DNS clients are configured with the addresses of DNS servers. Usually, these are servers which are authoritative for the domain of which they are a member. All requests for name resolution start with a request to one of these local servers. DNS queries can be of two forms:

In some configurations, such as when firewalls prevent direct IP communications between DNS clients and external nameservers, or when a site is connected to the rest of the world via a slow link, a nameserver can be configured with information about a forwarder. This is an external nameserver to which the local nameserver should make requests as a client would, asking the external nameserver to perform the full recursive name lookup, and return the result in a single query (which can then be cached), rather than reply with referrals.

Reverse Resolution

The DNS provides resolution from a textual name to a resource record, such as an A record with an IP address. It does not provide a means, other than exhaustive search, to match in the opposite direction; there is no mechanism to ask which name is bound to a particular RR.

For many RR types, this is of no real consequence, however it is often useful to identify by name the host which owns a particular IP address. Rather than complicate the design and implementation of the DNS database engine by providing matching functions in both directions, the DNS utilises the existing mechanisms and creates a special namespace, populated with PTR records, for IP address to name resolution. Resolving in this manner is often called reverse resolution, despite the inaccurate implications of the term.

The manner in which this is achieved is as follows:

One consequence of this is that it is possible for mismatch to occur. Resolving a name into an A record, and then resolving the name built from the address in that A record to a PTR record, may not result in a PTR record which contains the original name. There is no restriction within the DNS that the "reverse" mapping must coincide with the "forward" mapping. This is a useful feature in some circumstances, particularly when it is required that more than one name has an A record bound to it which contains the same IP address.

While there is no such restriction within the DNS, some application server programs or network libraries will reject connections from hosts that do not satisfy the following test:

This is done as a security precaution, to help detect and prevent malicious sites impersonating other sites by configuring their own PTR records to return the names of hosts belonging to another organisation.

The DNS Files

Now let's look at actually setting up a small DNS enabled network. We will continue to use the examples mentioned in Chapter 24, Setting up TCP/IP on NetBSD in practice, i.e. we assume that:

Our Name Server will be the strider host which 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 /etc/hosts file on "strider" before we have made the alterations to use DNS.

Example strider's /etc/hosts file       localhost     strider     samwise sam     wormtongue worm

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

The other assumption we want to make is that the domain we want to set up is, and that the domain is only known on our internal network, and not worldwide. Proper registration of the nameserver's IP address as primary would be needed in addition to a static IP. These are mostly administrative issues which are left out here.

The NetBSD operating system provides a set of config files for you to use for setting up DNS. Along with a default /etc/named.conf, the following files are stored in the /etc/namedb directory:

You will see modified versions of these files in this section, and I strongly suggest making a backup copy of the original files for reference purposes.

Note: The examples in this chapter refer to BIND major version 8, however, it should be noted that format of the name database and other config files are almost 100% compatible between version. The only difference I noticed was that the $TTL information was not required.


The first file we want to look at is /etc/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 {; };
        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, which our server couldn't resolve itself.

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:


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/namedb as indicated by the "directory" option.

Following are the rest of the params:

The rest of the named.conf file consists of zones. A zone is an area that can have items to resolve attached, e.g. a domain can have hostnames attached to resolve into IP addresses, and a reverse-zone can have IP addresses attached that get resolved back into hostnames. Each zone has a file associated with it, and a table within that file for resolving that particular zone. As is readily apparent, their format in named.conf is strikingly similar, so I will highlight just one of their records:



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:

 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:


This is the reverse lookup file (or zone) to resolve the special IP address back to "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| 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 (PTR) record. The zone used here is "@" again, which got set to the value given in named.conf, i.e. "". This is a special "domain" which is used to do reverse-lookup of IP addresses back into hostnames. For it to work, the four bytes of the IPv4 address are reserved, and the domain "" attached, so to resolve the IP address "", the PTR record of "" is queried, which is what is defined in that line.


This zone file is populated by records for all of our hosts. 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| samwise         IN A
13| www             IN CNAME
14| worm            IN A

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

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


This zone file is the reverse file for all of the host records, to map their IP numbers we use on our private network back into hostnames. The format is similar to that of the "localhost" version with the obvious exception being the addresses are different via the different zone given in the named.conf file, i.e. "" here:

 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


This file contains a list of root name servers for your server to query when it gets requests outside of its own domain that it cannot answer itself. Here are first few lines of a root zone file:

;       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
;       under anonymous FTP as
;           file                /domain/db.cache
;           on server           FTP.INTERNIC.NET
;       -OR-                    RS.INTERNIC.NET
;       last update:    Jan 29, 2004
;       related version of root zone:   2004012900
; 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 in the NetBSD operating system's "etc" set.

This section has described the most important files and settings for a DNS server. Please see the BIND documentation in /usr/src/dist/bind/doc/bog and named.conf(5) for more information.

Using DNS

In this section we will look at how to get DNS going and setup "strider" to use its own DNS services.

Setting up named to start automatically is quite simple. In /etc/rc.conf simply set named=yes. Additional options can be specified in named_flags, 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 command. In a nutshell the ndc command can stop, start or restart the named server process. It can also do a great many other things. Before use, it has to be setup to communicate with the "named" process, see the ndc(8) and named.conf(5) man pages for more details on setting up communication channels between "ndc" and the "named" process.

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 /etc/hosts first, and then DNS. However, on larger networks it is much easier to use DNS. Either way, the file where order of name services used for resolution is determined is /etc/nsswitch.conf (see nsswitch.conf. Here is part of a typical nsswitch.conf:

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

The line we are interested in is the "hosts" line. "files" means the system uses the /etc/hosts file first to determine ip to name translation, and if it can't find an entry, it will try DNS.

The next file to look at is /etc/resolv.conf, which is used to configure DNS lookups ("resolution") on the client side. 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 the "" domain, which means that lookups that contain only a hostname without a "." gets this domain appended to build a FQDN. If that lookup doesn't succeed, the domains in the "search" line are tried next. Finally, the "nameserver" line gives the IP addresses of one or more DNS servers that should be used to resolve DNS queries.

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

# host sam has address

As can be seen, the domain was appended automatically here, using the value from /etc/resolv.conf. Here is another example, the output of running host

$ host is an alias for has address has address has address has address has address has address has address has address

Other commands for debugging DNS besides host(1) are nslookup(8) and dig(1). Note that ping(8) is not useful for debugging DNS, as it will use whatever is configured in /etc/nsswitch.conf to do the name-lookup.

At this point the server is configured properly. The procedure for setting up the client hosts are easier, you only need to setup /etc/nsswitch.conf and /etc/resolv.conf to the same values as on the server.

Setting up a caching only name server

A caching only name server has no local zones; all the queries it receives are forwarded 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, it only needs to be enabled and started and is immediately ready for use! To enable named, put named=yes into /etc/rc.conf, and tell the system to use it adding the following line to the /etc/resolv.conf file:

# cat /etc/resolv.conf

Now we can start named:

# sh /etc/rc.d/named restart

Testing the server

Now that the server is running we can test it using the nslookup(8) program:

$ nslookup
Default server: localhost


Let's try to resolve a host name, for example "":

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(1) and dig(1) commands, which give the following result.

$ host has address
$ dig

; <<>> DiG 8.3 <<>>
;; res options: init recurs defnam dnsrch
;; got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 19409
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 5, ADDITIONAL: 0
;;, type = A, class = IN

;; ANSWER SECTION:         23h32m54s IN A

;; AUTHORITY SECTION:             23h32m54s IN NS             23h32m54s IN NS             23h32m54s IN NS             23h32m54s IN NS             23h32m54s IN NS

;; Total query time: 14 msec
;; FROM: miyu to SERVER:
;; WHEN: Thu Nov 25 22:59:36 2004
;; MSG SIZE  sent: 32  rcvd: 175

As you can see dig(1) gives quite a bit of output, the expected answer can be found in the "ANSWER SECTION". The other data given may be of interest when debugging DNS problems.