named(1M) named(1M)
NAME
named - Internet domain name server
SYNOPSIS
in.named [-d level] [-p port] [[-b] bootfile]
DESCRIPTION
The named command is the Internet domain name server. It is
used by hosts on the Internet to provide access to the
Internet distributed naming data base. See RFC 1034 and RFC
1035 for more details.
Files
/etc/named.boot name server configuration boot
file
/etc/named.pid the process ID
/var/tmp/named.run debug output
/var/tmp/named_dump.db dump of the name servers data
base
/var/tmp/named.stats nameserver statistics data
USAGE
With no arguments, named reads /etc/named.boot for any initial
data, and listens for queries on a privileged port.
Options
named takes the following options:
-d level print debugging information. level is a number
indicating the level of messages printed. level
is a number from 1 to 9. Higher numbers give more
detailed debugging information.
-p port use a different port number. The default is the
standard port number as listed in /etc/services.
-b bootfile use bootfile rather than /etc/named.boot. This is
optional and allows you to specify a file with a
leading dash.
Any additional arguments are taken as the name of the
bootfile. The bootfile contains information about where the
name server is to get its initial data. If multiple bootfiles
are specified, only the last is used. Lines in the bootfile
cannot be continued on subsequent lines. Note that all domain
names in the bootfile must not contain a trailing ``.'' (dot).
Copyright 1994 Novell, Inc. Page 1
named(1M) named(1M)
Examples
The following is a sample boot file for a name server.
;
;boot file for name server
;
directory /usr/lib/named
; type domain source host/filebackup file
cache . root.cache
primary Berkeley.EDU berkeley.edu.zone
primary 32.128.IN-ADDR.ARPA ucbhosts.rev
secondary CC.Berkeley.EDU 128.32.137.8 128.32.137.3cc.zone.bak
secondary 6.32.128.IN-ADDR.ARPA 128.32.137.8 128.32.137.3cc.rev.bak
primary 0.0.127.IN-ADDR.ARPA localhost.rev
forwarders 10.0.0.78 10.2.0.78
; slave
In the example, 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 in
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. There can be more than one cache
file specified. The cache files are processed in such a way
as to preserve the time-to-live's of data dumped out. Data
for the root nameservers is 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 RFC1035. 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 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).
Copyright 1994 Novell, Inc. Page 2
named(1M) named(1M)
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 the transfer fails it 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, 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 to cause a
large sitewide cache to be generated on a master, and to
reduce 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
machine 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 that 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 local network addresses listed first,
then addresses on the sort list, then other addresses. This
line is only acted on at initial startup. When reloading the
nameserver with a SIGHUP, this line will be ignored.
Copyright 1994 Novell, Inc. Page 3
named(1M) named(1M)
Master File
The master file consists of control information and a list of
resource records for objects in the zone of the forms:
$INCLUDE < filename >
$ORIGIN < domain >
< domain > < opt_ttl > < opt_class > < type >
< resource_record_data >
where domain is . for the 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 is appended to
the domain. Domain names ending with . are unmodified. When
you need to specify a fully qualified domain name (such as
somehost.berkeley.edu.), be sure to include the trailing ``.''
(dot).
The opt_ttl field is an optional integer number for the time-
to-live field. It defaults to zero.
The opt_class field is currently one token, IN for the
Internet.
The type field is one of the following tokens; the data
expected in the resource_record_data field is in 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 (5 numbers:
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).
Copyright 1994 Novell, Inc. Page 4
named(1M) named(1M)
NULL A null resource record (no format or data).
WKS A well know 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:
IN SOA ucbvax.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 each
time the master file is changed. Secondary servers check the
serial number at intervals specified by the refresh file is
changed. Secondary servers 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 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.
Signals
The following signals have the specified effect when sent to
the server process using the kill(1) command.
Copyright 1994 Novell, Inc. Page 5
named(1M) named(1M)
SIGHUP Causes server to read named.boot and reload
data base.
SIGINT Dumps current data base and cache to
/var/tmp/named_dump.db.
SIGIOT Dumps statistics data into
/var/tmp/named.stats if the server is compiled
-DSTATS. Statistics data is appended to the
file.
SIGSYS Dumps the profiling data in /var/tmp if the
server is compiled with profiling (server
forks, chdirs and exits).
SIGTERM Dumps the primary and secondary data base
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.
Warnings
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 then local nameserver did not have complete information.
REFERENCES
hostname(5), kill(1), resolv.conf(4), resolver(3N), signal(2),
signal(3BSD)
RFC 973, RFC 974, RFC 1034, RFC 1035
Copyright 1994 Novell, Inc. Page 6