named(1M)

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:

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:

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. If no file name is given, a temporary file will be used and will be deleted after each successful zone transfer. This is not recommended because it causes a needless waste of bandwidth.

A stub line (not shown) is similar to a secondary. Stub zones are intended to ensure that a primary for a zone always has the correct NS records for children of that zone. If the primary is not a secondary for a child zone, it should be configured with stub zones for all its children. Stub zones provide a mechanism to allow NS records for a zone to be specified in only one place.

This feature is experimental as of release 4.9.6 of BIND.

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 forward-only (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 noforward line specifies that the DNS server will not forward any request for something in or below the listed domains, even if the forwarders directive exists.

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 xfrnets directive (not shown) can be used to implement primitive access control. If this directive is given, then your name server will only answer zone transfer requests from hosts which are on networks listed in your xfrnets directives.

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 may be useful if you have many zones or have logical groupings of zones maintained by different people. The directive takes one argument, that being the name of the file whose contents are to be included. No quotation marks are necessary around the file name.

The bogusns directive (not shown) tells the server that no queries are to be sent to the specified name server addresses (specified as dotted quads, not as domain names). This may be useful if you know that a popular server has bad data in a zone or cache and you wish to avoid contamination while the problem is being fixed.

The limit directive can be used to change the servers' internal limits.

The transfers-in argument is the number of named-xfer subprocesses which the server will spawn at any one time. The transfers-per-ns argument is the maximum number of zone transfers to be simultaneously initiated to any given remote name server. The files argument sets the number of filedescriptors available to the process.

The options directive introduces a boolean specifier that changes the server behaviour. More than one option can be specified in a single directive. The options are as follows:

The max-fetch directive (not shown) is allowed for backward compatibility; its meaning is identical to limit transfers-in.

The slave directive (not shown) is allowed for backward compatibility; its meaning is identical to options forward-only.

The check-names directive tells BIND to check names in either primary or secondary zone files, or in response received during recursive name resolution. For each type of name, BIND can be told to fail such that a zone would not be loaded or a response would not be cached or forwarded, or merely warn which would cause a message to be emitted in the system operation logs, or to ignore the badness of a name and process it in the traditional fashion. Names are considered good if they confirm to RFC 952 for hostnames or if they consist only of printable ASCII characters, for names which are not hostnames.

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

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, to a limited extent, 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:

Not all of the data types are used during normal operation. The following data types are for experimental use and are subject to change: AFSDB, PX.

Resource records normally end at the end of a line, but can 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:

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.

NOTES

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 following signals have the specified effect when sent to the server process using the kill(1) command:

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

DIAGNOSTICS

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

AUTHOR

named was developed by the University of California, Berkeley.

FILES

SEE ALSO

kill(1), hosts_to_named(1M), named-xfer(1M), sig_named(1M), signal(2), gethostent(3N), resolver(3N), resolver(4), hostname(5),

RFC 882, RFC 883, RFC 973, RFC 974, RFC 1032, RFC 1033, RFC 1034, RFC 1035, RFC 1123.