*** UNIX MANUAL PAGE BROWSER ***

named(8) System Manager's Manual named(8) NAME named - Internet domain name server SYNOPSIS named [-d debuglevel] [-p port#[/localport#]] [{-b} bootfile] [-q] [-r] FLAGS Prints debugging information. The debuglevel variable specifies the level of messages printed. Specifies a different port number. The de- fault 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 re- mote servers and the second port is the service port bound by the local instance of named. This is used mainly for debugging. Specifies a bootfile with a leading dash. (The -b flag is not required unless the specified bootfile begins with a dash.) Traces all incoming queries. The boot file directive options query-log 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 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 argu- ments, 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 ; di- rectory /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 pro- cessing 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 periodi- cally 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 berke- ley.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 au- thoritative 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 con- tinue 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 suc- cessful zone transfer. Be sure to specify a file name to avoid wasting bandwidth. The second secondary line states that the address-to-host- name 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 an- swer 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 ad- dresses 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 ig- nored. The xfrnets directive (not shown) can be used to implement primitive access control. If this directive is given, your name server only an- swers 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 di- rective. This is useful if you have a lot of zones or if you have log- ical groupings of zones which are maintained by different people. The include directive takes one argument: the name of the file whose con- tents 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_do- main field nor $ORIGIN statements in the included file modify the cur- rent 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 host address (dotted quad) an authoritative name server (domain) a mail exchanger (domain) 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: re- fresh, 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 BIND Op- erations 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.Berke- ley.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 The following signals have the specified effect when sent to the server process using the kill(1) command. Causes the server to read named.boot, reload database, and check serial numbers on secondary zones. Dumps current data base and cache to /var/tmp/named_dump.db Dumps statistics data into /var/tmp/named.stats. Statistics data is appended to the file. Dumps the profiling data in /var/tmp if the server is compiled with profiling (server forks, chdirs and exits). Dumps the primary and secondary database files on shutdown. Turns on debugging; each SIGUSR1 increments debug level. Turns off debugging completely. 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 statis- tics. Received a query from a node Received a response from a node Re- ceived an inverse query from a node Received a negative response from a node Received a query from a node that this node had to forward Re- ceived a response from a node that this node had to forward Received a retry from a node Received an extra answer from a node Received a server failed message (SERVFAIL) from a node Received a format error message (FORMERR) from a node Received some other error from a node Re- ceived a query using TCP from a node Received an zone transfer request message (AXFR) from a node Received a lame delegation from a node Re- ceived some IP options from a node Sent a node a system query Sent a node an answer Forwarded a query to a node Forwarded a response to a node Sent a node a retry Sent a node a server failed message (SERVFAIL) Sent a node a format error message (FORMERR) Sent to a node, but the send failed (in sendto) FILES Specifies the command path Name server configuration boot file Process ID Debug output Dump of the name server database Nameserver statistics data RELATED INFORMATION Commands: hostname(1), kill(1). Files: resolver(4). Routines: signal(2), gethostbyname(3). Specifications: RFC973, RFC974, RFC1033, RFC1034, RFC1035 delim off named(8)