named(8)named(8)NAMEnamed - Internet domain name server (DNS)
SYNOPSIS
/usr/sbin/named [-c config-file] [-d debug-level] [-f] [-g] [-n #cpus]
[-p port] [-s] [-t directory] [-u] [-v] [-x cache-file]
OPTIONS
Use config-file as the configuration file instead of the default,
/etc/named.conf. To ensure that reloading the configuration file con‐
tinues to work after the server has changed its working directory due
to a possible directory option in the configuration file, config-file
should be an absolute pathname. Set the daemon's debug level to debug-
level. Debugging traces from named become more verbose as the debug
level increases. Run the server in the foreground (that is, do not
daemonize). Run the server in the foreground and force all logging to
stderr. Create #cpus worker threads to take advantage of multiple
CPUs. If not specified, named will try to determine the number of CPUs
present and create one thread per CPU. If it is unable to determine
the number of CPUs, a single worker thread will be created. Listen
for queries on port port. If not specified, the default is port 53.
Write memory usage statistics to stdout on exit.
Note
This option is mainly of interest to BIND 9 developers and may
be removed or changed in a future release. chroot() to direc‐
tory after processing the command line arguments, but before
reading the configuration file.
Note
This option should be used in conjunction with the -u option, as
chrooting a process running as root does not enhance security on
most systems; the way chroot() is defined allows a process with
root privileges to escape a chroot jail. setuid() to user after
completing privileged operations, such as creating sockets that
listen on privileged ports. Report the version number and exit.
Load data from cache-file into the cache of the default view.
Note
This option must not be used. It is only of interest to BIND
9 developers and may be removed or changed in a future release.
DESCRIPTION
The named daemon is a Domain Name System (DNS) server, part of the BIND
9 distribution from Internet Systems Consortium (ISC). Without any
arguments, named reads the default configuration file /etc/named.conf,
reads any initial data, and listens for queries.
The following is an example of part of a named.conf file, created by
the network administrator:
options {
directory "/etc/namedb";
named-xfer "/usr/sbin/named-xfer"; // _PATH_XFER
dump-file "named_dump.db"; // _PATH_DUMPFILE
pid-file "/var/run/named.pid"; // _PATH_PIDFILE
statistics-file "named.stats"; // _PATH_STATS
forward first;
forwarders { 10.0.0.78; 10.2.0.78;
};
transfers-in 10;
transfer-format one-answer;
allow-transfer { 16.0.0.0;
}; }; zone Berkeley.EDU {
type master; // what used to be called primary
file "berkeley.edu.zone";
check-names fail;
allow-update { any; }; }; zone 32.128.IN-ADDR.ARPA {
type master; // what used to be called primary
file "ucbhost.rev";
check-names fail;
allow-update { any; }; }; zone CC.Berkeley.EDU {
type slave; // what used to be called secondary
file "cc.zone.bak";
masters {
128.32.137.8; // where to zone transfer from
128.32.137.3;
}; }; zone 6.32.128.IN-ADDR.ARPA {
type slave; // what used to be called secondary
file "cc.rev.bak";
masters {
128.32.137.8; // where to zone transfer from
128.32.137.3;
}; }; // // load the cache data last // zone "." {
type hint;
file "named.ca"; };
The options statement aggregates all global options in one place. A
description of each option follows: The directory option 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 named-xfer option specifies the program that
executes the transfers from master servers. This overrides the default
program name. The dump-file option specifies the file or path for dump
of the name server database. This overrides the default file name.
The pid-file option specifies the file or path for Process Id of name
server daemon. This overrides the default file name. The statistics-
file specifies the file or path for name server statistics data. This
overrides the default file name. The forwarders option 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 option
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. The transfers-in option
specifies the number of named-xfer subprocesses that the server can
spawn at any one time. The default is 10. The transfer-format option
specifies the format of outbound zone transfers (from us to them). Two
values are allowed: one-answer and many-answers. If you are doing zone
transfers to old servers, do not specify many-answers. The default is
one-answer. You can specify the transfer format on a host-by-host
basis in the server statement. The allow-transfer option provides a
form of simple access control. If you specify this option with specific
networks, your name server only answers zone transfer requests from
hosts that are on networks listed in the allow-transfer list. To spec‐
ify transfer to any network, specify the option as follows:
allow-transfer { any; };
The zone statement identifies a zone and its attributes. Different
types of zones are identified by the type attribute; for example, mas‐
ter (formerly called primary), slave (formerly called secondary), stub,
and hint. A description of each zone statement follows: The first zone
statement specifies that the file berkeley.edu.zone contains authorita‐
tive data for the Berkeley.EDU zone. The file berkeley.edu.zone con‐
tains data in the master file format described in RFC 883. All domain
names are relative to the origin, in this case, Berkeley.EDU (see Mas‐
ter File section). The allow-update option allows the master server to
accept dynamic updates from new BIND clients for its master data file
without the intervention of the network administrator. The check-names
fail option forces the zone to verify that all hostnames contain only
valid characters. (The default behavior is to allow any characters in
the hostname.) For more information on this option, see the BIND Con‐
figuration File Guide on the Tru64 UNIX Documentation CD-ROM. The sec‐
ond zone statement specifies 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 host names. Each master file
should begin with an SOA record for the zone (see Master File section).
The third zone statement 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 contin‐
ues trying the addresses, up to 10, listed in the masters list.
The file cc.zone.bak is the backup for the transferred zone.
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 fourth zone statement specifies 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 fifth zone statement specifies that data in named.local 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 named.ca is in the same for‐
mat as berkeley.edu.zone. The named.ca file should be updated
periodically from ftp.rs.internic.net since it contains a list
of root servers that are changed periodically.
The include statement (not shown) can be used to process the contents
of some other file as though they appeared in place of the include
statement. 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 statement is also useful for separating information that
you do not want in a publicly-readable named.conf file. For example, on
IPv4 servers, if you want to specify a private key to use for authenti‐
cating dynamic updates from new BIND clients in your domain, you can
create a separate file for the key statement. Set the permissions on
the new file to be readable/writable only by superuser, then use the
include statement to call the file into the named.conf file. This
arrangement allows the named daemon to parse the key configuration
without revealing the key to users.
The include statement requires the name of the file (enclosed by quota‐
tion marks) whose contents are to be included. For example:
include "filename";
The server statement (not shown) allows you to specify options specific
to a particular server. The bogus attribute specifies whether to lis‐
ten to the specific server. If bogus is set to yes, the name server
does not send any queries to the specified name server. This is useful
when you know that some popular name server has bad data in a zone or
cache, and you do not want to avoid contamination while the problem is
fixed. The transfer-format attribute specifies whether the one-answer
or many-answer option should be used for zone transfers. The default
is one-answer, as it will work with all name servers. This option
overrides the global option for the specified server. For example:
server 1.2.3.4 {
bogus no;
transfer-format one-answer; };
The key statement (not shown) defines a private key to use for authen‐
tication purposes. See the Network Administration: Services manual or
bind_manual_setup(7) for more information about enabling secure DNS
updates.
Master Files
The BIND master database files contain the resource records that the
named daemon uses to respond to queries.
When you configure a master server with the SysMan Menu, the utility
optionally creates two master database files from your existing
/etc/hosts database -- /etc/namedb/hosts.db, for forward lookups, and
/etc/namedb/hosts.rev, for reverse lookups. However, you can assign any
names to these files, or create additional database files for other
domains, provided that you update the zone statements in the named.conf
file appropriately.
Database filenames conventionally include a prefix with descriptive
information about the domain followed by the or suffix. For example,
the master database files for the redwood.forest.com domain might be
called redwood.db and redwood.rev to differentiate them from files for
other domains.
The master database consists of control information and a list of
resource records for objects in the zone of the forms: $INCLUDE <file‐
name> <opt_domain> $ORIGIN <domain> $TTL <def_ttl> <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
origin is appended to the domain. Domain names ending with are unmodi‐
fied.
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 def_ttl field is an value for the default time-to-live. It speci‐
fies how long data will be stored in the cache. The value can be spec‐
ified in seconds or in the following format, where you need not specify
all of the fields: weeksWdaysDhoursHminutesMsecondsS
When the time-to-live is specified in the optional $TTL entry, the
limit takes takes effect only if no time-to-live value is specified for
a particular resource record or its corresponding SOA record. The
def_ttl value must be in the range of 0 to 2147483647 seconds. The max‐
imum in the alternative format is 3550W5D3H14M7S, or 3550 weeks, 5
days, 3 hours, 14 minutes, 7 seconds.
The opt_ttl field is an optional integer number for a particular
resource record's time-to-live. When unspecified, the time-to-live for
a resource record defaults to the value specified in the SOA record for
the zone, or ultimately, the value specified in the $TTL entry.
The opt_class field is the object address type; currently only one type
is supported, IN, for objects connected to the Internet.
The type field contains one of the following tokens. The data expected
in the resource_record_data field is in parentheses: a host address
(dotted quad IP address) an authoritative name server (domain) a mail
exchanger (domain), preceded by a preference value (0-32767, inclu‐
sive), with lower numeric values representing higher logical prefer‐
ences. the canonical name for an alias (domain) marks the start of a
zone of authority (domain of originating host, domain address of main‐
tainer, a serial number, and the following parameters in seconds:
refresh, retry, expire and minimum TTL (see RFC883)) a null resource
record (no format or data) a Responsible Person for some domain name
(mailbox, TXT-referral) a domain name pointer (domain) host information
(cpu_type OS_type)
Resource records normally end at the end of a line, but may be contin‐
ued 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 Network
Administration: Services 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 num‐
ber 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 sec‐
ondary 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 com‐
plete information.
Signals
In routine operation, signals should not be used to control the name‐
server; rndc should be used instead. Force a reload of the server.
Shut down the server. The result of sending any other signals to the
server is undefined.
SEE ALSOrndc(8), lwresd(1),
Specifications: RFC 1033, RFC 1034, RFC 1035
Network Administration: Services, BIND 9 Administrator Reference Man‐
ual
named(8)