named - Internet domain name server
named [ -d debuglevel ] [ -p port#[/localport#] ] [{-b}bootfile ] [ -q ] [ -r ]
Named is the Internet domain name server. See RFC's 1033,1034, and 1035 for more information on the Internet namedomainsystem. Without any arguments, named will read thedefault boot file /etc/named.boot, read any initial dataand listen for queries.
Options are:
Any additional argument is taken as the name of the bootfile. If multiple boot files are specified, only the lastis used.
The boot file contains information about where the nameserver is to get its initial data. Lines in the boot filecannot be continued on subsequent lines. The following isa small example:
;
; type domain source host/file backup file
cache . root.cacheprimary Berkeley.EDU berkeley.edu.zoneprimary 32.128.IN-ADDR.ARPA ucbhosts.revsecondary CC.Berkeley.EDU 128.32.137.8 128.32.137.3 cc.zone.baksecondary 6.32.128.IN-ADDR.ARPA 128.32.137.8 128.32.137.3 cc.rev.bakprimary 0.0.127.IN-ADDR.ARPA localhost.revforwarders 10.0.0.78 10.2.0.78
The ``directory'' line causes the server to change itsworking directory to the directory specified. This can beimportant for the correct processing of $INCLUDE files inprimary zone files.
The ``cache'' line specifies that data in ``root.cache''is to be placed in the backup cache. Its main use is tospecify data such as locations of root domain servers.This cache is not used during normal operation, but isused as ``hints'' to find the current root servers. Thefile ``root.cache'' is in the same format as ``berkeley.edu.zone''.There can be more than one ``cache'' filespecified. The ``root.cache'' file should be retrievedperiodically from FTP.RS.INTERNIC.NET since it contains alist of root servers, and this list changes periodically.
The first example ``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 thiscase, ``Berkeley.EDU'' (see below for a more detaileddescription). The second ``primary'' line states that thefile ``ucbhosts.rev'' contains authoritative data for thedomain ``32.128.IN-ADDR.ARPA,'' which is used to translateaddresses in network 128.32 to hostnames. Each masterfile should begin with an SOA record for the zone (seebelow).
The first example ``secondary'' line specifies that allauthoritative data under ``CC.Berkeley.EDU'' is to betransferred from the name server at 128.32.137.8. If thetransfer fails it will try 128.32.137.3 and continue tryingthe addresses, up to 10, listed on this line. Thesecondary copy is also authoritative for the specifieddomain. The first non-dotted-quad address on this linewill be taken as a filename in which to backup the transferredzone. The name server will load the zone from thisbackup file if it exists when it boots, providing acomplete copy even if the master servers are unreachable.Whenever a new copy of the domain is received by automaticzone transfer from one of the master servers, this filewill be updated. If no file name is given, a temporaryfile will be used, and will be deleted after each successfulzone transfer. This is not recommended since it is aneedless waste of bandwidth. The second example ``secondary''line states that the address-to-hostname mappingfor the subnet 128.32.136 should be obtained from the samelist of master servers as the previous zone.
The ``forwarders'' line specifies the addresses ofsitewide servers that will accept recursive queries fromother servers. If the boot file specifies one or moreforwarders, then the server will send all queries for datanot in the cache to the forwarders first. Each forwarderwill be asked in turn until an answer is returned or thelist is exhausted. If no answer is forthcoming from aforwarder, the server will continue as it would have withoutthe forwarders line unless it is in ``forward-only''mode. The forwarding facility is useful to cause a largesitewide cache to be generated on a master, and to reducetraffic over links to outside servers. It can also beused to allow servers to run that do not have directaccess to the Internet, but wish to look up exterior namesanyway.
The ``slave'' line (deprecated) is allowed for backwardcompatibility. Its meaning is identical to ``options forward-only''.
The ``sortlist'' line can be used to indicate networksthat are to be preferred over other networks. Queries forhost addresses from hosts on the same network as theserver will receive responses with local network addresseslisted first, then addresses on the sort list, then otheraddresses.
The ``xfrnets'' directive (not shown) can be used toimplement primitive access control. If this directive isgiven, then your name server will only answer zone transferrequests from hosts which are on networks listed inyour ``xfrnets'' directives. This directive may also begiven as ``tcplist'' for compatibility with older, interimservers.
The ``include'' directive (not shown) can be used to processthe contents of some other file as though theyappeared in place of the ``include'' directive. This isuseful if you have a lot of zones or if you have logicalgroupings of zones which are maintained by different people.The ``include'' directive takes one argument, thatbeing the name of the file whose contents are to beincluded. No quotes are necessary around the file name.
The ``bogusns'' directive (not shown) tells BIND that noqueries are to be sent to the specified name serveraddresses (which are specified as dotted quads, not asdomain names). This is useful when you know that somepopular server has bad data in a zone or cache, and youwant to avoid contamination while the problem is beingfixed.
The ``limit'' directive can be used to change BIND'sinternal limits, some of which (datasize, for example) areimplemented by the system and others (like transfers-in)by BIND itself. The number following the limit name canbe scaled by postfixing a ``k,'' ``m,'' or ``g'' for kilobytes,megabytes, and gigabytes respectively. datasize'sargument sets the process data size enforced by the kernel.Note: not all systems provide a call to implementthis -- on such systems, the use of the datasize parameterof ``limit'' will result in a warning message. transfersin'sargument is the number of named-xfer subprocesseswhich BIND will spawn at any one time. transfers-per-ns'sargument is the maximum number of zone transfers to besimultaneously initiated to any given remote name server.
The ``options'' directive introduces a boolean specifierthat changes the behaviour of BIND. More than one optioncan be specified in a single directive. The currentlydefined options are as follows: no-recursion, which willcause BIND to answer with a referral rather than actualdata whenever it receives a query for a name it is notauthoritative for -- don't set this on a server that islisted in any host's resolv.conf file; query-log, whichcauses all queries to be logged via syslog(8) -- this is alot of data, don't turn it on lightly; forward-only, whichcauses the server to query only its forwarders -- thisoption is normally used on machine that wishes to run aserver but for physical or administrative reasons cannotbe given access to the Internet; and fake-iquery, whichtells BIND to send back a useless and bogus reply to``inverse queries'' rather than responding with an error-- this is helpful if you have a lot of microcomputers orSunOS hosts or both.
The ``max-fetch'' directive (not shown) is allowed forbackward compatibility; its meaning is identical to``limit transfers-in''.
The master file consists of control information and a listof 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 domainname that does not end with ``.'', the current origin isappended to the domain. Domain names ending with ``.'' areunmodified. The opt_domain field is used to define anorigin for the data in an included file. It is equivalentto placing a $ORIGIN statement before the first line ofthe included file. The field is optional. Neither theopt_domain field nor $ORIGIN statements in the includedfile modify the current origin for this file. The opt_ttlfield is an optional integer number for the time-to-livefield. It defaults to zero, meaning the minimum valuespecified in the SOA record for the zone. The opt_classfield is the object address type; currently only one typeis supported, IN, for objects connected to the DARPAInternet. The type field contains one of the followingtokens; the data expected in the resource_record_datafield is in parentheses.
Resource records normally end at the end of a line, butmay be continued across lines between opening and closingparentheses. Comments are introduced by semicolons andcontinue to the end of the line.
Note that there are other resource record types, not shownhere. You should consult the BIND Operations Guide(``BOG'') for the complete list. Some resource recordtypes may have been standardized in newer RFC's but notyet implemented in this version of BIND.
Each master zone file should begin with an SOA record forthe zone. An example SOA record is as follows:
The SOA specifies a serial number, which should be changedeach time the master file is changed. Note that theserial number can be given as a dotted number, but this isa very unwise thing to do since the translation to normalintegers is via concatenation rather than multiplicationand addition. You can spell out the year, month, day ofmonth, and 0..99 version number and still fit inside theunsigned 32-bit size of this field. It's true that wewill have to rethink this strategy in the year 4294(Greg.) but we're not worried about it. Secondary serverscheck the serial number at intervals specified by therefresh time in seconds; if the serial number changes, azone transfer will be done to load the new data. If amaster server cannot be contacted when a refresh is due,the retry time specifies the interval at which refreshesshould be attempted. If a master server cannot be contactedwithin the interval given by the expire time, alldata from the zone is discarded by secondary servers. Theminimum value is the time-to-live (``TTL'') used byrecords in the file with no explicit time-to-live value.
The boot file directives ``domain'' and ``suffixes'' havebeen obsoleted by a more useful resolver-based implementationof suffixing for partially qualified domain names.The prior mechanisms could fail under a number of situations,especially when then local nameserver did not havecomplete information.
The following signals have the specified effect when sentto the server process using the kill(1) command.
SIGHUP Causes server to read named.boot and reload thedatabase. If the server is built with theFORCED_RELOAD compile-time option, then SIGHUP willalso cause the server to check the serial number onall secondary zones. Normally the serial numbersare only checked at the SOA-specified intervals.
SIGINT Dumps the current data base and cache to/var/tmp/named_dump.db
SIGIOT Dumps statistics data into /var/tmp/named.stats ifthe server is compiled with -DSTATS. Statisticsdata is appended to the file. Some systems useSIGABRT rather than SIGIOT for this.
SIGSYS Dumps the profiling data in /var/tmp if the serveris compiled with profiling (server forks, chdirsand exits).
SIGUSR1
Turns on debugging; each SIGUSR1 increments debuglevel. (SIGEMT on older systems without SIGUSR1)
SIGUSR2
Turns off debugging completely. (SIGFPE on oldersystems without SIGUSR2)
kill(1), gethostbyname(3), signal(2), resolver(3),resolver(5), hostname(7), RFC 882, RFC 883, RFC 973, RFC974, RFC 1033, RFC 1034, RFC 1035, RFC 1123, Name ServerOperations Guide for BIND