named(1M)

Requires Optional ARPA Services Software

NAME

named − Internet domain name server

SYNOPSIS

named [−d debuglevel] [−p port_number] [[−b] bootfile]

DESCRIPTION

named is the Internet domain name server. See RFC1034 and RFC1035 for more information on the Domain Name System. Without any arguments, named reads the default boot file /etc/named.boot, reads any initial data, and listens for queries.

Options are:

−d Print debugging information. A number after the d determines the level of messages printed.

−p Use a different port number.

−b Use a boot file other than /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 gets its initial data. If multiple boot files are specified, only the last 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/usr/local/domain

; typedomainhost/filebackup file

cache.db.cache
primaryberkeley.edudb.berkeley
primary32.128.in−addr.arpadb.128.32
secondarycc.berkeley.edu128.32.137.8 db.cc
secondary6.32.128.in−addr.arpa128.32.137.8 db.128.32.6
primary0.0.127.in−addr.arpadb.127.0.0
forwarders10.0.0.78 10.2.0.78
; slave
sortlist10.0.0.0 26.0.0.0

Comments in the boot file start with a ; and end at the end of the line. Comments can start anywhere on the line.

The directory line causes the server to change its working directory to the directory specified. This can be important for the correct processing of $INCLUDE files (described later) in primary servers’ master files. There can be more than one directory line in the boot file if master files are in separate directories.

Files referenced in the boot file contain data in the master file format described in RFC1035.

A server can access information from servers in other domains given a list of root name servers and their addresses. The cache line specifies that data in db.cache is to be placed in the backup cache. Its use is to prime the server with the locations of root domain servers. This information is used to find the current root servers and their addresses. The current root server information is placed in the operating cache. Data for the root nameservers in the backup cache are never discarded. There can be more than one cache file specified.

The first primary line states that the master file db.berkeley contains authoritative data for the berkeley.edu zone. A server authoritative for a zone has the most accurate information for the zone. 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 db.128.32 contains authoritative data for the domain 32.128.in−addr.arpa. This domain is used to translate addresses in network 128.32 to hostnames. The third primary line states that the file db.127.0.0 contains authoritative data for the domain 0.0.127.in−addr.arpa. The domain is used to translate 127.0.0.1 to the name used by the loopback interface. Each master file should begin with an SOA record for the zone (see below).

The first secondary line specifies that all authoritative data in the cc.berkeley.edu zone is to be transferred from the name server at Internet address 128.32.137.8 and will be saved in the backup file db.cc. Up to 10 addresses can be listed on this line. If a transfer fails, it will try the next address in the list. The secondary copy is also authoritative for the specified domain. The first non-Internet 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, 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 is updated.

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 or in its authoritative data 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 to cause a large sitewide cache to be generated on a master, and to reduce traffic over links to outside servers.

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 should only be used in conjunction with using forwarders.

The sortlist line can be used to indicate networks that are preferred over other, unlisted networks. Address sorting only happens when the query is from a host on the same network as the server. The best address is placed first in the response. The address preference is local network addresses, then addresses on the sort list, then other addresses.

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

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

where domain is . for root domain, @ for the current origin (where current origin is the domain from the boot file or the origin from an $ORIGIN line), or a standard domain name. If domain is a standard domain name that does not end with ., the current origin is appended to the domain. Domain names ending with . are 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. The field is optional. Neither the opt_domain field nor $ORIGIN statements in the included file 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 two types are supported: IN and HS. IN is for objects connected to the DARPA Internet and HS is for objects in the Hesiod class. The type field contains one of the following tokens; the data expected in the resource_record_data field is in parentheses:

A A host address (dotted quad)

CNAME Canonical name for an alias (domain)

GID Group ID (integer)

HINFO host information (cpu_type OS_type )

MB a mailbox domain name (domain)

MG a mail group member (domain)

MINFO mailbox or mail list information (request_domain error_domain)

MR a mail rename domain name (domain)

MX a mail exchanger (domain)

NS an authoritative name server (domain)

PTR a domain name pointer (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)

TXT text data (string)

UID user ID (integer)

UINFO user information (string)

WKS a well known service description ( IP address followed by a list of services)

Not all of the data types are used during normal operation. The following data types are for experimental use and are subject to change: GID, MB, MG, MR, UID, UINFO.

Resource records normally end at the end of a line, but can be continued across lines between opening and closing parentheses. (The continuation is currently only implemented for SOA and WKS records.) 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. root.ucbvax.berkeley.edu. (
89; Serial
10800; Refresh every 3 hours
3600; Retry every hour
604800; Expire after a week
86400 ); Minimum ttl of 1 day

The SOA lists a serial number, which should be increased each time the master file is changed. Secondary servers check the serial number at intervals specified by the refresh time in seconds; if the serial number increases, a zone transfer is done to load the new data. If a master server cannot be contacted when a refresh is due, the retry time specifies 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 the zone is discarded by secondary servers. The minimum value is the time-to-live used by records in the file with no explicit time-to-live value.

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

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

SIGINT Dumps current data base and cache to /usr/tmp/named_dump.db.

SIGIOT Dumps statistics data into /usr/tmp/named.stats. Statistics data is appended to the file.

SIGUSR1 Turns on debugging; each SIGUSR1 increments debug level.

SIGUSR2 Turns off debugging completely.

sig_named(1M) can also be used for sending signals to the server process.

DIAGNOSTICS

Any errors encountered by named(1m) in the boot file, master files, or in normal operation are logged with syslog and in the debug file, /usr/tmp/named.run, if debugging is on.

AUTHOR

named was developed by the University of California, Berkeley.

FILES

/etc/named.boot name server configuration boot file

/etc/named.pid process ID

/usr/tmp/named.run debug output

/usr/tmp/named_dump.db dump of the name server database

/usr/tmp/named.stats nameserver statistics data

Museum

Related Articles