named

Internet domain name server

Syntax:

named [-d debug_level] [-p port_number] [[-b]bootfile]

Description:

The named daemon is used to map symbolic names into IP addresses. If you have a registered domain name and wish to allow Internet clients to resolve hostnames on your domain, then you should configure and run named.

If you don't have a registered domain name, then you should either:

For example configuration files, see the /etc/config/socket directory. For an in-depth discussion of DNS, see Hunt's TCP/IP Network Administration. For advanced DNS configuration, see DNS and BIND by Paul Albitz and Cricket Liu, O'Reilly & Associates (ISBN 1-56592-010-4).

Example DNS nameserver

Suppose you wanted to add support for TCP/IP networking to a QNX Ethernet network. Rather than resolve IP addresses by configuring each node to use a local /etc/hosts file, DNS will let you disseminate new host information throughout your network from a single nameserver.

Before you begin...

Most DNS configuration files share the same basic format and use the same type of records to define information. These records are known as resource records or RRs.

RR types

RR type:Text name:Function:
SOAStart Of AuthorityProvides administrative information for the domain
NSName ServerIndicates that this is an authoritative nameserver
AInternet AddressA hostname-to-address mapping
CNAMECanonical NameAn alias
HINFOHost InformationThe host's hardware and OS
WKSWell Known ServicesA list of services supported by the host
MXMail ExchangerThe mail server where mail for a host will be delivered
PTRPointerAn address-to-hostname mapping (for reverse queries)

RR format

All RRs follow this basic format:

name [ttl] IN type data
name
The name of the domain object that the RR applies to — this can be an individual host or an entire domain. If you leave this field blank, the RR applies to the object named in the previous RR.
ttl
Stands for Time To Live. This field specifies, in seconds, how long a domain resolver should cache the RR before it throws it out and asks a domain server again. If you leave this field blank, it defaults to the ttl specified in the SOA record.
IN
Identifies the RR as a DNS record. There are other record classes, but DNS uses only this class.
type
The type of RR (e.g. SOA, NS, etc.).
data
Information specific to this type of RR (e.g. the data for a CNAME record would be an alias).

For more information on RRs, see RFC 1033 and RFC 1035. You could also refer to TCP/IP Network Administration.

Authoritative servers

Let's assume you have a five-node QNX TCP/IP network in which each node boots from its own hard drive:

fig: 5nodenet.gif

We're now going to set up a primary nameserver for this network. A DNS server can be one of three basic types:

Primary and secondary servers are authoritative servers, whereas caching-only servers, which provide only second-hand information, are not authoritative.

Creating the configuration files

Now let's assume your domain is called sample.com and you want node5 to act as the primary nameserver. The following table shows the complete set of named configuration files you need to create on node5. (On the left you see the conventional names of these files; we've chosen filenames that are more meaningful to this example.)

Conventional name:Name in example:Function:
named.bootnamed.bootProvides general parameters and location of remaining config files
named.caroot.cachePoints to cache initialization file
named.locallocalhost.resolveResolves the loopback address
named.hostssample.com.hosts(zone file) Contains most domain information, including hostname-to-address mappings
named.revsample.com.reverse(zone file) Contains address-to-hostname mappings

With the exception of named.boot, all these files share the same basic format.

The named.boot file

Here's the named.boot file:

; @(#)named.boot  5.1 (Berkeley)  6/30/90
directory /etc/namedb

;type     domain                   source host/file

cache     .                        root.cache
primary   sample.com               sample.com.hosts
primary   78.231.198.IN-ADDR.ARPA  sample.com.reverse
primary   0.0.127.IN-ADDR.ARPA     localhost.resolve

This file contains several commands — directory, cache, and primary:

directory /etc/namedb
Tells named that the remaining configuration files (root.cache, sample.com.hosts, ...) reside under the /etc/namedb directory.
cache . root.cache
Tells named to maintain a cache of nameserver responses and to use the root.cache file to initialize the cache.
primary sample.com sample.com.hosts
Declares that this node (node5) is the primary server for the sample.com domain. Also tells named to load the information for this domain from the sample.com.hosts zone file.
primary 78.231.198.IN-ADDR.ARPA sample.com.rev
Declares that this node (node5) is the primary server for the reverse domain 78.231.198.IN_ADDR.ARPA. (The reverse domain converts numeric IP addresses into domain names; you can apply for a reverse domain when you obtain your Internet domain name.) This command also tells named to load the information from the sample.com.rev zone file. This file contains the mappings to convert the IP addresses from 198.231.78.0 to hostnames.
primary 0.0.127.IN-ADDR.ARPA localhost.rev
States that the information for the loopback domain is contained in the localhost.rev file. The loopback domain is an IN-ADDR.ARPA domain that maps the address 127.0.0.1 to the name localhost.

For more information on these and other possible named.boot configuration commands, see TCP/IP Network Administration.

The root.cache file

The named.boot file we just looked at contains a cache statement. This statement points to the cache initialization file (root.cache in our example). This initialization file contains the information needed to begin building a cache of domain data when the server starts.

The cache statement in the named.boot file contains a dot (.). This is the name of the root domain, which sits at the top of the domain hierarchy. At a minimum, the root.cache file contains the names and address of the root servers, which are the nameservers for the root domain. (You should update the information in this file about once a month; see pp. 179-180 in TCP/IP Network Administration.)

Here's the root.cache file:

;   @(#)root.cache  5.1 (Berkeley) 6/30/90

;    Servers for the root domain
; Initial cache data for root domain servers.
.     99999999  IN  NS  NS.INTERNIC.NET.
      99999999  IN  NS  KAVA.NISC.SRI.COM.
      99999999  IN  NS  TERP.UMD.EDU.
      99999999  IN  NS  NS.NIC.DDN.MIL.

;    Root servers by address
; Prep the cache (hotwire the addresses). 
; Order doesn't matter.

NS.INTERNIC.NET.   	99999999  IN A  198.41.0.4
KAVA.NISC.SRI.COM. 	99999999  IN A  192.33.33.24
TERP.UMD.EDU.    	99999999  IN A  128.8.10.90
NS.NIC.DDN.MIL.  	99999999  IN A  192.112.36.4

Near the top of this file, you see NS records that identify the root servers. Next, you see several “A” records that give the address of each root server. Finally, note that the ttl for every record is 99999999 — the largest possible value — so that the root servers are never removed from the cache.

If your system isn't connected to the Internet, it won't be able to communicate with the root servers. In that case, simply create a root.cache that has entries pointing to the major nameservers on your LAN.

localhost.rev

The localhost.rev file is the zone file for the reverse domain 0.0.127.IN_ADDR.ARPA. This file is used to convert the address 127.0.0.1 (the loopback address) to the name localhost.

Here's the localhost.rev file:

@    IN  SOA  	node5.sample.com. node5.sample.com.(
               	950110   ; serial
               	604800   ; refresh (168 hours)
               	3600     ; retry (1 hour)
               	3600000  ; expire (1000 hours)
               	604800 ) ; minimum (168 hours)

     IN  NS	 	node5.sample.com.

1.0  IN  PTR  	localhost.

Note the SOA resource record, which provides administrative information for the domain. This information is important, so let's take a closer look at the record's syntax:


name   [ttl]   IN   SOA   origin   person (
                          serial
                          refresh
                          retry
                          expire
                          minimum )
name
The name of the zone. The at-sign (@) refers back to the primary statement (in named.boot) that points to this zone file.
origin
The name of the host on which the master zone file resides.
person
A mailbox for the person responsible for the zone. This is formatted like a mailing address but the at-sign that normally separates the user from the hostname is replaced with a dot.

Note that this SOA record indicates that node5.sample.com. is both the server responsible for this zone and the email address for any questions regarding the zone.

serial
The version number of the zone file. You should increment this any time you change data in the zone.

For info on the remaining fields, see TCP/IP Network Administration.

After the SOA record, you see an NS record that indicates the computer's hostname (i.e. node5.sample.com.). Since this record is defined in the sample.com.hosts file, it's optional here.

Note the IN PTR localhost. record at the end of the file. Because all systems use 127.0.0.1 as the loopback address, this record can be identical on every server.

sample.com.hosts

The files we covered so far — named.boot, root.cache, and localhost.rev — are the only files required to configure a caching-only server. The remaining files — sample.com.hosts and sample.rev — are more complex and are created only on a primary server.

The sample.com.hosts file contains most of the domain information. It converts hostnames to IP addresses, and consequently contains several A resource records. It also contains NS records to define the domain and its servers, and MX records to define mail servers. It could also contain other record types, such as CNAME and WKS.

Here's the sample.com.hosts file:

;
; Address to host name mappings
;
@  IN  SOA  node5.sample.com. node5.sample.com.(
               	950110   ; serial
               	604800   ; refresh (168 hours)
               	3600     ; retry (1 hour)
               	3600000  ; expire (1000 hours)
               	604800 ) ; minimum (168 hours)

IN  A  198.231.78.5
IN  HINFO  486 "QNX 4.23"

; define the nameservers and the mail servers
   IN  MX 10  node5.sample.com.
   IN  MX 20  node1.sample.com.
   IN  NS     node5.sample.com.

; define the hosts in this zone
node1   	IN A    198.231.78.1
        	IN MX   5 node5.sample.com.
node2   	IN A    198.231.78.2
        	IN MX   5 node5.sample.com.
node3   	IN A    198.231.78.3
        	IN MX   5 node5.sample.com.
node4   	IN A    198.231.78.4
        	IN MX   5 node5.sample.com.
node5   	IN A    198.231.78.5
        	IN MX   5 node5.sample.com.

; define local host
localhost IN A 127.0.0.1

Note the first MX record:

IN  MX 10  node5.sample.com.

This defines a mail server for the entire domain. Specifically, it indicates that node5.sample.com. is the mail server for sample.com with a preference of 10. Similarly, the second MX record indicates that node1.sample.com. is also a mail server, but with a preference of 20. Giving node1.sample.com. a larger preference number effectively makes it a backup mail server. (The host with the lowest preference number is always tried first. If it's unreachable, then the host with the next largest number is tried, and so on.) Keep in mind that you'd have to configure node5.sample.com. and node1.sample.com. as mail servers for the mail to work.

The remaining A records convert hostnames to IP addresses. They also define the mail server for each host, which isn't necessary since we've already defined the default mail servers. However, by adding these MX entries we can do things such as adjust the preference level for each host.

The sample.com.rev file

The last configuration file (sample.com.rev) converts IP addresses to hostnames. As a result, it looks a lot like localhost.rev with its use of PTR records:

;
;  Address to host name mappings
;
@   IN  SOA node5.sample.com. node5.sample.com.(
               	950110   ; serial
               	604800   ; refresh (168 hours)
               	3600     ; retry (1 hour)
               	3600000  ; expire (1000 hours)
               	604800 ) ; minimum (168 hours)

    IN  NS  node5.sample.com.

1       IN      PTR     node1.sample.com.
2       IN      PTR     node2.sample.com.
3       IN      PTR     node3.sample.com.
4       IN      PTR     node4.sample.com.
5       IN      PTR     node5.sample.com.

Configuring the client side

Let's now look at how to set up the client side of DNS on each of the remaining nodes (node1 through node4).

Under QNX, the resolver (i.e. the code that queries the domain) uses the /etc/resolv.conf file to resolve the nameserver's domain and IP address. The resolv.conf file can also define backup servers in case the default server doesn't respond.

The /etc/resolv.conf file contains at least the following entries:

nameserver address
Identifies, by IP address, the server that the resolver will query for domain information. The file can contain more than one nameserver entry. If there's more than one entry, the resolver queries the first server defined; if there's no response, it queries the second server; if there's still no response, it queries the third server, and so on.

If resolv.conf contains no nameserver entries, or if no resolv.conf file exists, all nameserver queries are sent to the local host (i.e. the /etc/hosts file).

domain name
Defines the default domain name. The resolver appends this default name to any host that doesn't end with a dot. It then uses the expanded hostname in the query it sends to the nameserver.

For example, let's say that the resolver receives the hostname node1 (which doesn't contain a dot) and that the value for name is sample.com. In that case, the resolver would query for: node1.sample.com

For our example, resolv.conf could contain the following:

;
;  Domain name resolver configuration file - 
;  '/etc/resolv.conf'
;
domain sample.com
nameserver 198.231.78.5

Debugging

To query a nameserver and retrieve any of the information it knows about, you can use nslookup. This tool is especially handy when you're trying to establish whether or not you've configured your nameserver properly.

Here's a sample nslookup session:

# nslookup -v
Default Server:  node5
Address:  198.231.78.5
  
>> node2
Server:  node5
Address: 198.231.78.5

Non-authoritative answer:
Name:    node2.sample.com
Address: 198.231.78.2

First, nslookup returned the primary server's hostname and IP address. Then, after we entered a query for node2, it returned the server name and IP address again, followed by the hostname and IP address for node2.

By default, nslookup queries for A records, which provide hostname-to-address mappings. To change to another RR type, use nslookup's set type command. For example, the following session contains a query for mail information about node2:

>> set type=mx
>> node2
Server:  node5
Address: 198.231.78.5

Non-authoritative answer:
node2.sample.com  preference = 5, mail exchanger =  
   node5.sample.com

Authoritative answers can be found from:
sample.com  nameserver = node5.sample.com
node5.sample.com  internet address = 198.231.78.5

Now let's look at an example of how nslookup can help you catch errors. Let's assume that one of the IN MX entries in sample.com.hosts ended without a dot:

node1     IN A    198.231.78.1
          IN MX   5 node5.sample.com

Given this error, here's what nslookup would show if you did an MX query for node1:

>> set type=mx
>> node1
Server:  node5
Address: 198.231.78.5

Non-authoritative answer:
node1.sample.com  preference = 5, mail exchanger =
   node5.sample.com.sample.com

Authoritative answers can be found from:
sample.com  nameserver = node5.sample.com
node5.sample.com  internet address = 198.231.78.5

As you can see, the “mail exchanger” hostname is resolved to:

node5.sample.com.sample.com

With no dot at the end of the above IN MX entry, the resolver appended the domain to the host and produced the doubled name.