 |
Click this button to go to the index for this section. |
named(8)
NAME
named - Internet domain name server
SYNOPSIS
named [-d debuglevel] [-p port#[/localport#]]
[{-b} bootfile] [-q] [-r]
FLAGS
-d [debuglevel]
Prints debugging information. The debuglevel variable specifies
the level of messages printed.
-p port# [/localport#]
Specifies a different port number. The default is the standard
port number as listed in the /etc/services file.
You can specify two port numbers separated by a slash (/). In
this case, the first port number is the one used to contact
remote servers and the second port is the service port bound by
the local instance of named. This is used mainly for debugging.
-b Specifies a bootfile with a leading dash. (The -b flag is not
required unless the specified bootfile begins with a dash.)
-q Traces all incoming queries. The boot file directive options
query-log provides the same function and is preferred over the -q
option.
-r Turns recursion off in the server. Answers can come only from
local (primary or secondary) zones. This can be used on root
servers. The boot file directive options no-recursion provides
the same function and is preferred over the -r option.
Any additional argument following the flags and their arguments is taken as
an alternate bootfile. 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 is used. Lines in the boot file cannot be
continued on subsequent lines.
DESCRIPTION
The named daemon is the Internet domain name server. See RFC1034 for more
information on the Internet name-domain system. Without any arguments,
named reads the default boot file /etc/namedb/named.boot, reads any initial
data, and listens for queries.
The following is an example of part of a named.boot file, created by the
network administrator.
;
; boot file for name server
;
directory /etc/namedb
; type domain source host/file backup 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.3 cc.zone.bak
secondary 6.32.128.IN-ADDR.ARPA 128.32.137.8 128.32.137.3 cc.rev.bak
primary 0.0.127.IN-ADDR.ARPA localhost.rev
forwarders 10.0.0.78 10.2.0.78
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 root.cache file should be retrieved periodically from
FTP.RS.INTERNIC.NET since it contains a list of root servers and changes
this list periodically.
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 RFC883. All domain
names are relative to the origin, in this case, Berkeley.EDU (see Master
File section).
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 Master File section).
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 tries 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 is taken as a filename in which
to backup the transferred zone. The name server loads 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. If no file name is specified, a temporary file is used;
the temporary file is deleted after each successful zone transfer. Be sure
to specify a file name to avoid wasting bandwidth. 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, the server sends all queries for data not in the
cache to the forwarders first. Each forwarder is asked in turn until an
answer is returned or the list is exhausted. If no answer is forthcoming
from a forwarder, the server continues as it would have without the
forwarders line unless it is in forward-only 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 (not shown) is allowed for backward compatibility. Its
meaning is identical to options forward-only.
The sortlist (not shown) 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 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 is ignored.
The xfrnets directive (not shown) can be used to implement primitive access
control. If this directive is given, your name server only answers zone
transfer requests from hosts that are on networks listed in your xfrnets
directives. This directive may also be given as tcplist for compatibility
with older, interim servers. For example:
xfrnets 16.0.0.0
The include directive (not shown) can be used to process the contents of
some other file as though they appeared in place of the include directive.
This is useful if you have a lot of zones or if you have logical groupings
of zones which are maintained by different people. The include directive
takes one argument: the name of the file whose contents are to be included.
No quotes are necessary around the file name. For example:
include filename
The bogusns directive (not shown) tells the server that no queries are to
be sent to the specified name server addresses (which are specified as
dotted quads, not as domain names). This is useful when you know that some
popular server has bad data in a zone or cache, and you want to avoid
contamination while the problem is being fixed. For example:
bogusns 16.1.2.3
The max-fetch directive (not shown) can be used to override the default
limit (which is 10) to the number of named-xfer subprocesses that the name
server can spawn at any one time. For example:
max-fetch 5
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> <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 is appended to the domain. Domain names ending with . are
unmodified.
The opt_domain field defines 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 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 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 (domain of originating
host, domain address of maintainer, a serial number and the
following parameters in seconds: refresh, retry, expire and
minimum TTL (see RFC883))
NULL a null resource record (no format or data)
RP a Responsible Person for some domain name (mailbox, TXT-referral)
PTR a domain name pointer (domain)
HINFO host information (cpu_type OS_type)
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.
This is not a complete list of resource record types. See the BIND
Operations Guide for a complete list.
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. (
1989020501 ; 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 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.
The boot file directives domain and suffixes are obsolete because of 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.
Signals
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, reload database, and check
serial numbers on secondary zones.
SIGINT Dumps current data base and cache to /var/tmp/named_dump.db
SIGIOT Dumps statistics data into /var/tmp/named.stats. 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 database files on shutdown.
SIGUSR1 Turns on debugging; each SIGUSR1 increments debug level.
SIGUSR2 Turns off debugging completely.
SIGWINCH Enables or disables the logging of incoming queries to the system
log.
Statistics Legend
The following is an explanation of the statistics given in the
/var/tmp/named.stats file. These apply to global and per-node statistics.
RQ Received a query from a node
RR Received a response from a node
RIQ Received an inverse query from a node
RNXD Received a negative response from a node
RFwdQ Received a query from a node that this node had to forward
RFwdR Received a response from a node that this node had to forward
RDupQ Received a retry from a node
RDupR Received an extra answer from a node
RFail Received a server failed message (SERVFAIL) from a node
RFErr Received a format error message (FORMERR) from a node
RErr Received some other error from a node
RTCP Received a query using TCP from a node
RAXFR Received an zone transfer request message (AXFR) from a node
RLame Received a lame delegation from a node
ROpts Received some IP options from a node
SSysQ Sent a node a system query
SAns Sent a node an answer
SFwdQ Forwarded a query to a node
SFwdR Forwarded a response to a node
SDupQ Sent a node a retry
SFail Sent a node a server failed message (SERVFAIL)
SFErr Sent a node a format error message (FORMERR)
SErr Sent to a node, but the send failed (in sendto)
FILES
/usr/sbin/named
Specifies the command path
/etc/namedb/named.boot
Name server configuration boot file
/var/run/named.pid
Process ID
/var/tmp/named.run
Debug output
/var/tmp/named_dump.db
Dump of the name server database
/var/tmp/named.stats
Nameserver statistics data
RELATED INFORMATION
Commands: hostname(1), kill(1).
Files: resolver(4).
Routines: signal(2), gethostbyname(3).
Specifications: RFC973, RFC974, RFC1033, RFC1034, RFC1035