named

Internet domain name server

Syntax:

named [-(b|c) config_file] [-d debug_level] [-f]
      [-g group_name] [-p portnum] [-q] [-r]
      [-t directory] [-u user_name] [-w directory]
      [config_file]

Runs on:

Neutrino

Options:

-b|-c config_file
Use this alternate config_file; this argument is overridden by any config_file which is specified at the end of the command line (default value is /etc/named.conf).
-d debug_level
Print debugging information. The debug_level is a number that determines the level of messages printed. If negative, debug_level is set to 1.

Note: The new debugging framework is considerably more sophisticated than it was in older versions of named. The configuration file's logging statement allows for multiple, distinct levels of debugging for each of a large set of categories of events (such as queries, transfers in or out, and so on). See the description of /etc/named.conf configuration file for further information about these extensive new capabilities.

-f
Run this process in the foreground; don't fork() and daemonize (default is to daemonize).
-g group_name
Specifies the group the server should run as after it initializes. The value specified may be either a group name or a numeric group ID.
-p portnum
Use the specified remote port server. This is the port number to which named sends queries. The default value is the standard port number, that is, the port number returned by getservbyname() for service domain.

Note: Previously, the syntax -pportnum[/localportnum] was supported; the first port was used when contacting remote servers, and the second one was the service port bound by the local instance of named. The current usage is equivalent to the old usage without the localportnum specified; you can specify this functionality with the listen-on clause of the configuration file's options statement.

-q
Trace all incoming queries.
-r
Turn recursion off in the server (default is to use recursion). Answers can come only from local (primary or secondary) zones. You can use this on root servers.

Note: The -r option is deprecated; you can replace or override it with the recursion clause of the /etc/named.conf configuration file's options statement.

-t directory
Specifies the directory the server should chroot into as soon as it's finished processing command line arguments.
-u user_name
Specifies the user the server should run as after it initializes. The value specified may be either a username or a numeric userid. If the -g flag isn't specified, then the group ID used is the group of the user specified.
-w directory
Sets the working directory of the server (the default working directory is the current directory "."). The directory clause of the configuration file's options statement overrides any value specified on the command line.
config_file
Use this configuration file (default file is /etc/named.conf). A config_file argument given at the end of the command line overrides any config_file specified with the -b or -c flags.

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:


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

Sample DNS nameserver

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

Resource records (RRs)

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 type Text name Function
A Internet Address A hostname-to-address mapping
CNAME Canonical Name An alias
HINFO Host Information The host's hardware and OS
MX Mail Exchanger The mail server where mail for a host is delivered
NS Name Server Indicates that this is an authoritative nameserver
PTR Pointer An address-to-hostname mapping (for reverse queries)
SOA Start Of Authority Provides administrative information for the domain
WKS Well Known Services A list of services supported by the host

All RRs follow this basic format:

name [ttl] IN type data

The fields are:

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 TCP/IP network in which each node boots from its own hard drive:


Figure showing a 5-node Ethernet network


A 5-node Ethernet network.

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

Primary and secondary servers are authoritative servers, whereas caching-only servers, which provide only second-hand information, aren't 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.conf named.conf Provides general parameters and location of remaining config files
named.ca root.cache Cache initialization file
named.local localhost.resolve Resolves the loopback address
named.hosts sample.com.hosts (zone file) Contains most domain information, including hostname-to-address mappings
named.rev sample.com.reverse (zone file) Contains address-to-hostname mappings

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

named.conf

Here's the named.conf file:

options {
            directory "/etc/namedb";
    };
    
    zone "." {
            type hint;
            file "root.cache";
    };
    
    zone "sample.com" {
            type master;
            file "sample.com.hosts";
    };
    
    zone "78.231.198.IN-ADDR.ARPA" {
            type master;
            file "sample.com.reverse";
    };
    
    zone "0.0.127.IN-ADDR.ARPA" {
            type master;
            file "localhost.resolve";
    };

The named daemon is much more configurable than in the previous release. There are entirely new areas of configuration, such as access control lists and categorized logging. Many options that previously applied to all zones can now be used selectively. These features, plus a consideration of future configuration needs, led to the creation of a new configuration file format.

For more information, see the /etc/named.conf configuration file.

root.cache

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.resolve

The localhost.resolve 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.resolve 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 )

where:

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, refer to 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.conf, root.cache, and localhost.resolve -- are the only files required to configure a caching-only server. The remaining files -- sample.com.hosts and sample.com.reverse -- 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 hostname 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 Neutrino 6.3.0"

; 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.

sample.com.reverse

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

;
;  Address to hostname 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

For the rules on setting up the client side of DNS see /etc/resolv.conf.

For our example, your resolv.conf should set the nameserver to 198.231.78.5 and the domain name to sample.com.

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.

Diagnostics

The following signals have the specified effect when sent to the server process using the kill() command:

SIGHUP
Causes server to read named.conf and reload the database.
SIGINT
Dumps the current data base and cache to named_dump.db.
SIGILL
Dumps statistics data into named.stats.
SIGTERM
Dumps the primary and secondary database files. Used to save modified data on shutdown if the server is compiled with dynamic updating enabled.
SIGUSR1
Turns on debugging; each SIGUSR1 increments debug level.
SIGUSR2
Turns off debugging completely. (SIGFPE on older systems without SIGUSR2.)
SIGWINCH
Toggles logging of all incoming queries via syslog(). In order to capture the log messages, you need to have syslogd running.

Files:

/etc/named.conf
Default name server configuration file.
/etc/namedb/named.pid
The process ID.
named_dump.db
Dump of the name server database.
named.run
Debug output.
named.stats
Nameserver statistics data.

See also:

hostname, kill, /etc/named.conf, named-xfer, syslogd

gethostbyname(), signal() in the Library Reference

RFC 882, RFC 883, RFC 973, RFC 974, RFC 1033