named(1M) — ADMINISTRATOR COMMANDS

NAME

named, in.named − Internet domain name server

SYNOPSIS

in.named [−d debug_level] [−p port#] [−b bootfile]

DESCRIPTION

The named command is the Internet domain name server. See RFC 1035 for more information on the Internet name-domain system. Without any arguments, named will read the default boot file /etc/named.boot, read any initial data, and then listen for queries.

The available options are:

−d debug_level
Print debugging information; the debug_level will determine the level of messages printed.

−p port# Use a different port number, port#; the default is the standard port number as listed in /etc/services.

−b bootfile Use the alternate boot file bootfile. This is optional and will allow you to specify a file with a leading dash. The default value is /etc/named.boot.

Any additional argument is taken as the name of the boot file. The boot file contains information about where the name server is to get its initial data. If multiple boot files are specified, only the last one is used. Lines in the boot file cannot be continued on subsequent lines.

The following is a small example:

;
;boot file for name server
;
directory/var/named
; typedomainsource host/filebackup file
cache.root.cache
primaryBerkeley.EDUberkeley.edu.zone
primary32.128.IN-ADDR.ARPAucbhosts.rev
secondaryCC.Berkeley.EDU128.32.137.8 128.32.137.3cc.zone.bak
secondary6.32.128.IN-ADDR.ARPA128.32.137.8 128.32.137.3cc.rev.bak
primary0.0.127.IN-ADDR.ARPAlocalhost.rev
forwarders10.0.0.78 10.2.0.78
; slave

The directory line causes the server to change its working directory to the specified directory. This can be important for the correct processing of $INCLUDE files in the primary zone files.

The cache line specifies that data in root.cache is to be placed in the backup cache. Its main use is to specify data such as locations of root domain servers. This cache is not used during normal operation, but is used as “hints” to find the current root servers. The file root.cache is in the same format as berkeley.edu.zone.

More than one cache file can be specified. The cache files are processed to preserve the time-to-live (TTL) values for all the data dumped out. The data for the root nameservers will be kept artificially valid if necessary.

The first primary line states that the file berkeley.edu.zone contains authoritative data for the Berkeley.EDU zone. The file berkeley.edu.zone contains data in the master file format described in RFC 1035. All domain names are relative to the origin, in this case, Berkeley.EDU (see below for a more detailed description).

The second primary line states that the file ucbhosts.rev contains authoritative data for the domain 32.128.IN-ADDR.ARPA, which is used to translate addresses in network 128.32 to hostnames. Each master file should begin with an SOA record for the zone (see below).

The first secondary line specifies that all authoritative data under CC.Berkeley.EDU is to be transferred from the name server at 128.32.137.8. If this transfer fails, the system will try 128.32.137.3 and continue trying the addresses, up to 10, listed on this line. The secondary copy is also authoritative for the specified domain. The first non-dotted-quad address on this line will be taken as a filename in which to backup the transferred zone. The name server will load the zone from this backup file if it exists when it boots, thus providing a complete copy even if the master servers are unreachable. Whenever a new copy of the domain is received by automatic zone transfer from one of the master servers, this file will be updated. The second “secondary” line states that the address-to-hostname mapping for the subnet 128.32.136 should be obtained from the same list of master servers as the previous zone.

The forwarders line specifies the addresses of sitewide servers that will accept recursive queries from other servers. If the boot file specifies one or more forwarders, then the server will send all queries for data not in the cache to the forwarders first. Each forwarder will be asked in turn until an answer is returned or the list is exhausted. If no answer is forthcoming from a forwarder, the server will continue as it would have without the forwarders line unless it is in slave mode. The forwarding facility is useful for generating a large site-wide cache on a master, as well as for reducing traffic over links to outside servers. It can also be used to allow servers to run that do not have access directly to the Internet, but wish to act as though they do.

The slave line (shown commented out) is used to put the server in slave mode. In this mode, the server will only make queries to forwarders. This option is normally used on machines that wish to run a server, but for physical or administrative reasons cannot be given access to the Internet, but have access to a host which does have access.

The sortlist line can be used to indicate networks that are to be preferred over other, unlisted, networks. Queries for host addresses from hosts on the same network as the server will receive responses with the local network addresses listed first, then the addresses on the sort list, and then the other addresses. This line is only acted on at initial startup. This line will be ignored when reloading the nameserver with a SIGHUP.

The master file consists of control information and a list of resource records for objects in the zone using the following formats:

$INCLUDE <filename> <opt_domain>
$ORIGIN <domain>
<domain> <opt_ttl> <opt_class> <type> <resource_record_data>

where domain is “.” for root, “@” for the current origin, or a standard domain name. If domain is a standard domain name that does not end with “.”, the current origin will be appended to the domain. Domain names ending with “.” will remain unmodified. The opt_domain field is used to define an origin for the data in an included file. It is equivalent to placing a $ORIGIN statement before the first line of the included file. (This field is optional.) Neither the opt_domain field nor the $ORIGIN statements in the included file will modify the current origin for this file. The opt_ttl field is an optional integer number for the time-to-live field. It defaults to zero, meaning the minimum value specified in the SOA record for the zone. The opt_class field is the object address type; currently only one type is supported, IN, for objects connected to the DARPA Internet. The type field contains one of the following tokens (the data expected in the resource_record_data field is shown within parentheses).

A a host address (dotted quad)

NS an authoritative name server (domain)

MX a mail exchanger (domain)

CNAME
the canonical name for an alias (domain)

SOA marks the start of a zone of authority (domain of originating host, domain address of maintainer, a serial number and the following parameters in seconds: refresh, retry, expire and minimum TTL [see RFC 1035])

MB a mailbox domain name (domain)

MG a mail group member (domain)

MR a mail rename domain name (domain)

NULL a null resource record (no format or data)

WKS a well-known service description (not implemented yet)

PTR a domain name pointer (domain)

HINFO host information (cpu_type OS_type)

MINFO mailbox or mail list information (request_domain error_domain)

Resource records normally end at the end of a line, but may be continued across lines between opening and closing parentheses. Comments are introduced by semicolons and continue to the end of the line.

Each master zone file should begin with an SOA record for the zone. An example SOA record is as follows:

@INSOAucbvax.Berkeley.EDU. rwh.ucbvax.Berkeley.EDU. (
2.89; serial
10800; refresh
3600; retry
3600000; expire
86400 ); minimum

The SOA lists a serial number which should be changed whenever the master file is changed. Secondary servers will check the serial number at intervals specified by the refresh time in seconds; if the serial number changes, a zone transfer will be done to load the new data. If a master server cannot be contacted when a refresh is due, the retry time will specify the interval at which refreshes should be attempted until successful. If a master server cannot be contacted within the interval given by the expire time, all data from that zone will be discarded by the secondary servers. The minimum value is the “time-to-live” used by records in the file which contain no explicit “time-to-live” value.

NOTES

The boot file directives “domain” and “suffixes” have been obsoleted by a more useful resolver-based implementation of suffixing for partially qualified domain names. The prior mechanisms could fail under a number of situations, especially when the local nameserver did not have complete information. The following signals have the specified effect when sent to the server process using the kill(1) command:

SIGHUP
Causes the server to read named.boot and to reload the database.

SIGINT
Dumps the the contents of the current data base and cache to /var/tmp/named_dump.db.

SIGIOT
Will dump statistics data into /var/tmp/named.stats if the server is compiled with the −DSTATS flag. The statistics data will be appended to this file.

SIGSYS
Will dump the profiling data in /var/tmp if the server is compiled with profiling (server forks, chdirs and exits).

SIGTERM
Will dump 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 will increment the debug level. (SIGEMT on older systems without SIGUSR1.)

SIGUSR2
Turns off debugging completely. (SIGFPE on older systems without SIGUSR2.)

FILES

/etc/named.bootname server configuration boot file
/etc/named.pidthe process id
/var/tmp/named.rundebug output
/var/tmp/named_dump.dbdump of the name server database
/var/tmp/named.statsstatistical data for nameserver

Museum