named(8) System Manager's Manual named(8)
NAME
named - Internet domain name server (DNS)
SYNOPSIS
named [-d debuglevel] [-p port#] [{-b|-c} configfile]
[-f] [-q] [-r] [-w directory] [configfile]
FLAGS
Prints debugging information. The debuglevel variable specifies the level of messages printed. If the value is negative, debuglevel is
set to 1.
This enables you to specify multiple, distinct level of debugging for categories of events (for example, queries and transfers in
and out) by using the logging statement in the named.conf file. See named.conf(4) for more information. Specifies a different
remote port number. This is the port number to which named sends queries. The default is the standard port number for the domain
service as listed in the /etc/services file. Specifies a configfile with a leading dash. (The -b flag is not required unless the
specified configfile begins with a dash.) Runs this process in the foreground instead of executing fork(2) and running as a daemon.
By default, the commands forks another process and runs in the background as a daemon. Traces all incoming queries.
The queries logging_category clause in the configuration file logging statement provides the same function and is preferred over the
-q option. Turns recursion off in the server. Answers can come only from local (primary or secondary) zones. This can be used on
root servers. The default is to use recursion.
The recursion clause in the configuration file options statement provides the same function and is preferred over the -r option.
Sets the working directory of the server. The default working directory is the current directory.
The directory clause of the configuration file options statement overrides any value specified on the command line.
To provide compatibility with previous versions of BIND, any additional argument following the flags and their arguments is considered the
name of the configuration file. This argument overrides any configfile specified with the -b or -c flags. If no argument is given, the
default configuration file, /etc/named.conf, is used.
DESCRIPTION
The named daemon is the Internet domain name server. See RFC 1033, RFC 1034, and RFC 1035 for more information on the Internet name-domain
system. Without any arguments, named reads the default configuration file /etc/named.conf, reads any initial data, and listens for
queries. If you specify a configfile argument at the end of the command line, the value overrides any configuration file specified with
the -b or -c flags.
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 with-
out the forwarders option unless it is in forward-only mode. The forwarding facility is useful to cause a large sitewide cache to be gen-
erated on a master, and to reduce traffic over links to outside servers. The transfers-in option specifies the number of named-xfer sub-
processes 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 specify 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 authoritative data for the Berkeley.EDU zone. The file berkeley.edu.zone
contains data in the master file format described in RFC 883. All domain names are relative to the origin, in this case, Berkeley.EDU (see
Master 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 con-
tain only valid characters. (The default behavior is to allow any characters in the hostname.) For more information on this option, see
the BIND Configuration File Guide on the Tru64 UNIX Documentation CD-ROM. The second 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 authorita-
tive 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 continues 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 unreach-
able. 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 format 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 authenticating 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 quotation 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
listen 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 authentication purposes. See the Network Administration guide or bind_man-
ual_setup(7) for more information about enabling secure DNS updates.
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> $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 ., 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 def_ttl field is an value for the default time-to-live. It specifies how long data will be stored in the cache. The value can be
specified 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 partic-
ular resource record or its corresponding SOA record. The def_ttl value must be in the range of 0 to 2147483647 seconds. The maximum 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 preferences. the canonical name for an alias (domain) 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)) 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 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 Network Administration 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 ucb-
vax.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. Causes the server to read
named.conf, reload database, and check serial numbers on secondary zones. Typically, the serial numbers are checked only at intervals
specified in the SOA record. Dumps current data base and cache to /var/tmp/named_dump.db or the value of _PATH_DUMPFILE. Dumps statistics
data into /var/tmp/named.stats. Statistics data is appended to the file. Dumps the profiling data in /var/tmp. Dumps the primary and
secondary database files on shutdown. Turns on debugging; each SIGUSR1 signal increments debug level. Turns off debugging completely.
Enables or disables the logging of incoming queries to the system log.
FILES
Specifies the command path Default name server configuration file Process ID (_PATH_PIDFILE) Debug output (file: _PATH_DEBUG) Dump of the
name server database (_PATH_DUMPFILE) Nameserver statistics data (file: _PATH_STATS)
RELATED INFORMATION
Commands: hostname(1), kill(1).
Files: named.conf(4), named.stats(4), resolver(4).
Routines: signal(2), gethostbyname(3).
Specifications: RFC973, RFC974, RFC1033, RFC1034, RFC1035
Network Administration, Bind Configuration File Guide delim off
named(8)
