1NAMED(8)                    System Manager's Manual                   NAMED(8)
2
3
4

NAME

6       named - Internet domain name server
7

SYNOPSIS

9       named [ -d debuglevel ] [ -p port# ] [{-b} bootfile ]
10

DESCRIPTION

12       Named is the Internet domain name server.  See RFC883 for more informa‐
13       tion on the Internet name-domain system.  Without any arguments,  named
14       will  read the default boot file /etc/named.boot, read any initial data
15       and listen for queries.
16
17       Options are:
18
19       -d     Print debugging information.  A number after  the  ``d''  deter‐
20              mines the level of messages printed.
21
22       -p     Use  a  different port number.  The default is the standard port
23              number as listed in /etc/services.
24
25       -b     Use an alternate boot file.  This is optional and allows you  to
26              specify a file with a leading dash.
27
28       Any  additional  argument  is  taken as the name of the boot file.  The
29       boot file contains information about where the name server  is  to  get
30       its  initial data.  If multiple boot files are specified, only the last
31       is used.  Lines in the boot file  cannot  be  continued  on  subsequent
32       lines.  The following is a small example:
33
34         ;
35         ;    boot file for name server
36         ;
37         directory /usr/local/domain
38
39         ; type     domain                source host/file          backup file
40
41         cache      .                                               root.cache
42         primary    Berkeley.EDU          berkeley.edu.zone
43         primary    32.128.IN-ADDR.ARPA   ucbhosts.rev
44         secondary  CC.Berkeley.EDU       128.32.137.8 128.32.137.3 cc.zone.bak
45         secondary  6.32.128.IN-ADDR.ARPA 128.32.137.8 128.32.137.3 cc.rev.bak
46         primary    0.0.127.IN-ADDR.ARPA                            localhost.rev
47         forwarders 10.0.0.78 10.2.0.78
48         ; slave
49
50       The  ``directory''  line causes the server to change its working direc‐
51       tory to the directory specified.  This can be important for the correct
52       processing of $INCLUDE files in primary zone files.
53
54       The  ``cache''  line  specifies  that  data  in ``root.cache'' is to be
55       placed in the backup cache.  Its main use is to specify  data  such  as
56       locations of root domain servers.  This cache is not used during normal
57       operation, but is used as ``hints'' to find the current  root  servers.
58       The file ``root.cache'' is in the same format as ``berkeley.edu.zone''.
59       There can be more than one ``cache'' file specified.  The  cache  files
60       are  processed  in such a way as to preserve the time-to-live's of data
61       dumped out.  Data for the root nameservers is kept  artificially  valid
62       if necessary.
63
64       The  first  ``primary'' line states that the file ``berkeley.edu.zone''
65       contains authoritative data for the ``Berkeley.EDU''  zone.   The  file
66       ``berkeley.edu.zone'' contains data in the master file format described
67       in RFC883.  All domain names are relative to the origin, in this  case,
68       ``Berkeley.EDU'' (see below for a more detailed description).  The sec‐
69       ond ``primary'' line states that  the  file  ``ucbhosts.rev''  contains
70       authoritative  data  for  the  domain ``32.128.IN-ADDR.ARPA,'' which is
71       used to translate addresses in network 128.32 to hostnames.  Each  mas‐
72       ter file should begin with an SOA record for the zone (see below).
73
74       The  first  ``secondary''  line  specifies  that all authoritative data
75       under ``CC.Berkeley.EDU'' is to be transferred from the name server  at
76       128.32.137.8.   If the transfer fails it will try 128.32.137.3 and con‐
77       tinue trying the addresses, up to 10, listed on this  line.   The  sec‐
78       ondary  copy is also authoritative for the specified domain.  The first
79       non-dotted-quad address on this line will be taken  as  a  filename  in
80       which  to  backup  the  transfered zone.  The name server will load the
81       zone from this backup file if it exists when it boots, providing a com‐
82       plete  copy even if the master servers are unreachable.  Whenever a new
83       copy of the domain is received by automatic zone transfer from  one  of
84       the  master  servers,  this  file  will  be updated.  The second ``sec‐
85       ondary'' line states that the address-to-hostname mapping for the  sub‐
86       net  128.32.136 should be obtained from the same list of master servers
87       as the previous zone.
88
89       The ``forwarders'' line specifies the  addresses  of  sitewide  servers
90       that  will  accept  recursive  queries from other servers.  If the boot
91       file specifies one or more forwarders, then the server  will  send  all
92       queries  for  data not in the cache to the forwarders first.  Each for‐
93       warder will be asked in turn until an answer is returned or the list is
94       exhausted.   If  no  answer is forthcoming from a forwarder, the server
95       will continue as it would have without the forwarders line unless it is
96       in  ``slave'' mode.  The forwarding facility is useful to cause a large
97       sitewide cache to be generated on a master, and to reduce traffic  over
98       links  to outside servers.  It can also be used to allow servers to run
99       that do not have access directly to the Internet, but wish  to  act  as
100       though they do.
101
102       The  ``slave''  line (shown commented out) is used to put the server in
103       slave mode.  In this mode, the server will only make  queries  to  for‐
104       warders.   This  option  is normally used on machine that wish to run a
105       server but for physical  or  administrative  reasons  cannot  be  given
106       access  to  the  Internet,  but  have  access  to a host that does have
107       access.
108
109       The ``sortlist'' line can be used to indicate networks that are  to  be
110       preferred  over  other,  unlisted networks.  Queries for host addresses
111       from hosts on the same network as the  server  will  receive  responses
112       with  local  network addresses listed first, then addresses on the sort
113       list, then other addresses.  This line is  only  acted  on  at  initial
114       startup.   When  reloading the nameserver with a SIGHUP, this line will
115       be ignored.
116
117       The master file consists of control information and a list of  resource
118       records for objects in the zone of the forms:
119
120              $INCLUDE <filename> <opt_domain>
121              $ORIGIN <domain>
122              <domain> <opt_ttl> <opt_class> <type> <resource_record_data>
123
124       where domain is "." for root, "@" for the current origin, or a standard
125       domain name. If domain is a standard domain name that does not end with
126       ``.'',  the current origin is appended to the domain. Domain names end‐
127       ing with ``.'' are unmodified.  The opt_domain field is used to  define
128       an  origin for the data in an included file.  It is equivalent to plac‐
129       ing a $ORIGIN statement before the first line  of  the  included  file.
130       The field is optional.  Neither the opt_domain field nor $ORIGIN state‐
131       ments in the included file modify the current  origin  for  this  file.
132       The  opt_ttl  field  is an optional integer number for the time-to-live
133       field.  It defaults to zero, meaning the minimum value specified in the
134       SOA  record  for  the  zone.  The opt_class field is the object address
135       type; currently only one type is supported, IN, for  objects  connected
136       to  the  DARPA  Internet.  The type field contains one of the following
137       tokens; the data expected  in  the  resource_record_data  field  is  in
138       parentheses.
139
140       A        a host address (dotted quad)
141
142       NS       an authoritative name server (domain)
143
144       MX       a mail exchanger (domain)
145
146       CNAME    the canonical name for an alias (domain)
147
148       SOA      marks  the start of a zone of authority (domain of originating
149                host, domain address of maintainer, a serial  number  and  the
150                following  parameters  in  seconds: refresh, retry, expire and
151                minimum TTL (see RFC883))
152
153       MB       a mailbox domain name (domain)
154
155       MG       a mail group member (domain)
156
157       MR       a mail rename domain name (domain)
158
159       NULL     a null resource record (no format or data)
160
161       WKS      a well know service description (not implemented yet)
162
163       PTR      a domain name pointer (domain)
164
165       HINFO    host information (cpu_type OS_type)
166
167       MINFO    mailbox or mail list information (request_domain error_domain)
168
169       Resource records normally end at the end of a line, but may be  contin‐
170       ued across lines between opening and closing parentheses.  Comments are
171       introduced by semicolons and continue to the end of the line.
172
173       Each master zone file should begin with an SOA record for the zone.  An
174       example SOA record is as follows:
175
176       @    IN   SOA  ucbvax.Berkeley.EDU. rwh.ucbvax.Berkeley.EDU. (
177                           2.89 ; serial
178                           10800     ; refresh
179                           3600 ; retry
180                           3600000   ; expire
181                           86400 )   ; minimum
182
183       The  SOA  lists  a serial number, which should be changed each time the
184       master file is changed.  Secondary servers check the serial  number  at
185       intervals  specified by the refresh time in seconds; if the serial num‐
186       ber changes, a zone transfer will be done to load the new data.   If  a
187       master server cannot be contacted when a refresh is due, the retry time
188       specifies the interval at which refreshes  should  be  attempted  until
189       successful.  If a master server cannot be contacted within the interval
190       given by the expire time, all data from the zone is discarded  by  sec‐
191       ondary  servers.  The minimum value is the time-to-live used by records
192       in the file with no explicit time-to-live value.
193

NOTES

195       The boot file directives ``domain'' and ``suffixes''  have  been  obso‐
196       leted  by  a more useful resolver based implementation of suffixing for
197       partially qualified domain names.   The  prior  mechanisms  could  fail
198       under a number of situations, especially when then local nameserver did
199       not have complete information.
200
201       The following signals have the specified effect when sent to the server
202       process using the kill(1) command.
203
204       SIGHUP Causes server to read named.boot and reload database.
205
206       SIGINT Dumps current data base and cache to /usr/tmp/named_dump.db
207
208       SIGIOT Dumps statistics data into /usr/tmp/named.stats if the server is
209              compiled -DSTATS.  Statistics data is appended to the file.
210
211       SIGSYS Dumps the profiling data in /usr/tmp if the server  is  compiled
212              with profiling (server forks, chdirs and exits).
213
214       SIGTERM
215              Dumps  the  primary  and secondary database files.  Used to save
216              modified data on shutdown if the server is compiled with dynamic
217              updating enabled.
218
219       SIGUSR1
220              Turns   on  debugging;  each  SIGUSR1  increments  debug  level.
221              (SIGEMT on older systems without SIGUSR1)
222
223       SIGUSR2
224              Turns off debugging completely.  (SIGFPE on older systems  with‐
225              out SIGUSR2)
226

FILES

228       /etc/named.boot          name server configuration boot file
229       /var/run/named.pid       the process id
230       /usr/tmp/named.run       debug output
231       /usr/tmp/named_dump.db   dump of the name server database
232       /usr/tmp/named.stats     nameserver statistics data
233

SEE ALSO

235       kill(1),  gethostbyname(3),  signal(3), resolver(3), resolver(5), host‐
236       name(7), RFC882, RFC883, RFC973, RFC974, Name Server  Operations  Guide
237       for BIND
238
239
240
2414th Berkeley Distribution      February 28, 1988                      NAMED(8)
Impressum