|
|
1.1 root 1: .\" Copyright (c) 1986, 1988 Regents of the University of California.
2: .\" All rights reserved.
3: .\"
4: .\" Redistribution and use in source and binary forms are permitted
5: .\" provided that this notice is preserved and that due credit is given
6: .\" to the University of California at Berkeley. The name of the University
7: .\" may not be used to endorse or promote products derived from this
8: .\" software without specific prior written permission. This software
9: .\" is provided ``as is'' without express or implied warranty.
10: .\"
11: .\" @(#)files.me 6.8 (Berkeley) 9/19/89
12: .\"
13: .sh 1 "Files
14: .pp
15: The name server uses several files to load its data base.
16: This section covers the files and their formats needed for \fInamed\fP.
17: .sh 2 "Boot File"
18: .pp
19: This is the file that is first read when \fInamed\fP starts up.
20: This tells the server what type of server it is,
21: which
22: zones it has authority over and where to get its initial data.
23: The default location for this file is \fI/\|etc\|/\|named\|.\|boot\fP\|.
24: However this can be changed
25: by setting the \fIBOOTFILE\fP variable when you compile \fInamed\fP
26: or by specifying
27: the location on the command line when \fInamed\fP is started up.
28: .sh 3 "Domain"
29: .pp
30: A default domain may be specified for the nameserver
31: using a line such as
32: .(b l
33: .ta 0.5i +\w`secondary `u +\w`berkeley.edu `u +.5i +.5i
34: \fIdomain Berkeley\fP\fB\|.\|\fP\fIEdu\fP
35: .)b
36: .re
37: The name server uses this information when it receives a query for a
38: name without a ``\fB.\fP'' that is not known.
39: When it receives one of these queries, it appends the name in the second
40: field to the query name.
41: This is an obsolete facility which will be removed from future releases.
42: .sh 3 "Directory"
43: .pp
44: The directory line specifies the directory in which the nameserver should
45: run, allowing the other file names in the boot file to use relative
46: path names.
47: .(b l
48: .ta 0.5i +\w`secondary `u +\w`berkeley.edu `u +.5i +.5i
49: \fIdirectory /usr/local/domain\fP
50: .)b
51: .re
52: If you have more than a couple of named files to be maintained,
53: you may wish to place the named files in a directory such as
54: /usr/local/domain and adjust the directory command properly.
55: The main purposes of this command are to make sure named is
56: in the proper directory when trying to include files by relative
57: path names with $Include and to allow named to run in a location
58: that is reasonable to dump core if it feels the urge.
59: .sh 3 "Primary Master"
60: .pp
61: The line in the boot file that designates the server as a primary server
62: for a zone looks as follows:
63: .(b l
64: .ta 0.5i +\w`secondary `u +\w`berkeley.edu `u +.5i +.5i
65: \fIprimary Berkeley\fP\fB\|.\|\fP\fIEdu ucbhosts\fP
66: .)b
67: .re
68: The first field specifies that the server is a primary one for the zone
69: stated in the second field.
70: The third field is the name of the file from which the data is read.
71: .sh 3 "Secondary Master"
72: .pp
73: The line for a secondary server is similar to the primary except
74: that it lists addresses of other servers (usually primary servers)
75: from which the zone data will be obtained.
76: .(b l
77: .ta 0.5i +\w`secondary `u +\w`berkeley.edu `u +.5i +.5i
78: \fIsecondary Berkeley\fP\fB\|.\|\fP\fIEdu 128\fP\fB.\fP\fI32\fP\fB.\fP\fI0\fP\fB.\fP\fI10 \fP\fI128\fP\fB.\fP\fI32\fP\fB.\fP\fI0\fP\fB.\fP\fI4\fP \fIucbhosts.bak\fP
79: .)b
80: .re
81: The first field specifies that the server is a secondary master server for
82: the zone stated in the second field.
83: The two network addresses
84: specify the name servers that are primary for the zone.
85: The secondary server gets its data across the network from the listed servers.
86: Each server is tried in the order listed until it successfully receives the data
87: from a listed server.
88: If a filename is present after the list of primary servers, data for the zone
89: will be dumped into that file as a backup.
90: When the server is first started, the data are loaded from the backup file
91: if possible, and a primary server is then consulted to check that the zone
92: is still up-to-date.
93: .sh 3 "Caching Only Server"
94: .pp
95: You do not need a special line to designate that a server is a caching server.
96: What denotes a caching only server is the absence of authority
97: lines, such as \fIsecondary\fP or \fIprimary\fP in the boot file.
98: .pp
99: All servers should have a line as follows in the boot file to
100: prime the name servers cache:
101: .(b l
102: \fIcache \fP\fB.\fP\fI root\fP\fB.\fP\fIcache\fP
103: .)b
104: All cache files listed will be read in at named boot time and
105: any values still valid will be reinstated in the cache and the root
106: nameserver information in the cache files will always be used.
107: For information on cache file see section on \fICache Initialization\fP.
108: .sh 3 "Forwarders"
109: Any server can make use of \fIforwarders\fP. A \fIforwarder\fP is another
110: server capable of processing recursive queries that is willing to try
111: resolving queries on behalf of other systems. The \fIforwarders\fP
112: command specifies forwarders by internet address as follows:
113: .(b l
114: \fIforwarders \fI128\fP\fB.\fP\fI32\fP\fB.\fP\fI0\fP\fB.\fP\fI10 \fP\fI128\fP\fB.\fP\fI32\fP\fB.\fP\fI0\fP\fB.\fP\fI4\fP
115: .)b
116: .re
117: There are two main reasons
118: for wanting to do so. First, the other systems may not have full network
119: access and may be prevent from sending any IP packets into the rest of
120: the network and therefore must rely on a forwarder which does have
121: access to the full net. The second reason is that the forwarder sees
122: a union of all queries as they pass through his server and therefore he
123: builds up a very rich cache of data compared to the cache in a typical
124: workstation nameserver. In effect, the \fIforwarder\fP becomes a meta-cache
125: that all hosts can benefit from, thereby reducing the total number of queries
126: from that site to the rest of the net.
127: .sh 3 "Slave Mode"
128: .pp
129: Slave mode is used if the use of forwarders is the only possible way
130: to resolve queries due to lack of full net access or if you wish to prevent
131: the nameserver from using other than the listed forwarders.
132: Slave mode is activated by placing the simple command
133: .(b l
134: \fIslave\fP
135: .)b
136: in the bootfile. If \fIslave\fP is used, then you must specify forwarders.
137: When in slave mode, the server will forward each query to each of the
138: the forwarders until an answer is found or the list of forwarders is
139: exhausted.
140: .sh 3 "Remote Server"
141: .pp
142: To set up a host that will use a remote server instead of a local
143: server to answer queries, the file \fI/\|etc/\|resolv\|.\|conf\fP
144: needs to be created.
145: This file designates the name servers on the network that should
146: be sent queries.
147: It is not advisable to create this file if you have a local server
148: running. If this file exists it is read almost every time
149: \fIgethostbyname\|()\fP or \fIgethostbyaddr\|()\fP is called.
150: .sh 2 "Cache Initialization"
151: .sh 3 root.cache
152: .pp
153: The name server needs to know the servers that are the authoritative
154: name servers for the root domain of the network.
155: To do this we have to prime the name server's cache with the addresses
156: of these higher authorities.
157: The location of this file is specified in the boot file.
158: This file uses the Standard Resource Record Format (aka. Masterfile Format)
159: covered further on
160: in this paper.
161: .sh 2 "Domain Data Files"
162: .pp
163: There are three standard files for specifying the data for a
164: domain. These are \fInamed\|.\|local\fP, \fIhosts\fP and \fIhost\|.\|rev\fP.
165: These files use the Standard Resource Record Format covered later
166: in this paper.
167: .sh 3 named\|.\|local
168: .pp
169: This file specifies the address for the local loopback interface,
170: better known as \fIlocalhost\fP with the network address 127.0.0.1.
171: The location of this file is specified in the boot file.
172: .sh 3 hosts
173: .pp
174: This file contains all the data about the machines in this zone.
175: The location of this file is specified in the boot file.
176: .sh 3 hosts\|.\|rev
177: .pp
178: This file specifies the IN-ADDR\|.\|ARPA domain.
179: This is a special domain for allowing address to name mapping.
180: As internet host addresses do not fall within domain boundaries,
181: this special domain was formed to allow inverse mapping.
182: The IN-ADDR\|.\|ARPA domain has four
183: labels preceding it. These labels correspond to the 4 octets of
184: an Internet address.
185: All four octets must be specified even if an octets is zero.
186: The Internet address 128.32.0.4 is located in the domain
187: 4\|.\|0\|.\|32\|.\|128\|.\|IN-ADDR\|.\|ARPA.
188: This reversal of the address is awkward to read but allows
189: for the natural grouping of hosts in a network.
190: .sh 2 "Standard Resource Record Format"
191: .pp
192: The records in the name server data files are called resource records.
193: The Standard Resource Record Format (RR) is specified in RFC1035.
194: The following is a general description of these records:
195: .TS
196: l l l l l.
197: \fI{name} {ttl} addr-class Record Type Record Specific data\fP
198: .TE
199: Resource records have a standard format shown above.
200: The first field is always the name of the domain record
201: and it must always start in column 1.
202: For some RR's the name may be left blank;
203: in that case it takes on the name of the previous RR.
204: The second field is an optional time to live field.
205: This specifies how long this data will be stored in the data base.
206: By leaving this field blank the default time to live is specified
207: in the \fIStart Of Authority\fP resource record (see below).
208: The third field is the address class; currently, only one class is supported:
209: \fIIN\fP for internet addresses and other information.
210: The fourth field states the type of the resource record.
211: The fields after that are dependent on the type of the RR.
212: Case is preserved in names and data fields when loaded into the name server.
213: All comparisons and lookups in the name server data base are case insensitive.
214: .bl
215: .b
216: The following characters have special meanings:
217: .ip \fB.\fP
218: A free standing dot in the name field refers to the current domain.
219: .ip @
220: A free standing @ in the name field denotes the current origin.
221: .ip "\fB.\|.\fP"
222: Two free standing dots represent the null domain name of the root when used in
223: the name field.
224: .ip "\\\X"
225: Where X is any character other than a digit (0-9),
226: quotes that character so that its special meaning does not apply.
227: For example, ``\e.'' can be used to place a dot character in a label.
228: .ip "\\\DDD"
229: Where each D is a digit, is the octet corresponding to the
230: decimal number described by DDD.
231: The resulting octet is assumed to be text and
232: is not checked for special meaning.
233: .ip "( )"
234: Parentheses are used to group data that crosses a line.
235: In effect, line terminations are not recognized within parentheses.
236: .ip ";"
237: Semicolon starts a comment; the remainder of the line is ignored.
238: .ip "*"
239: An asterisk signifies wildcarding.
240: .pp
241: Most resource records will have the current origin appended to names if they
242: are not terminated by a ``\fB.\fP''.
243: This is useful for appending the current domain name to the data,
244: such as machine names, but may cause problems where you do not want
245: this to happen.
246: A good rule of thumb is that, if the name is not in of the domain for which
247: you are creating the data file, end the name with a ``\fB.\fP''.
248: .sh 3 $INCLUDE
249: .pp
250: An include line begins with $INCLUDE, starting in column 1,
251: and is followed by a file name.
252: This feature is
253: particularly useful for separating different types of data into multiple files.
254: An example would be:
255: .(b l
256: $INCLUDE /usr/named/data/mailboxs
257: .)b
258: The line would be interpreted as a request to load the file
259: \fI/usr/named/data/mailboxes\fP.
260: The $INCLUDE command does not cause data to be loaded into a
261: different zone or tree. This is simply a way to allow data for a
262: given zone to be organized in separate files. For example,
263: mailbox data might be kept separately from host data using this
264: mechanism.
265: .sh 3 $ORIGIN
266: .pp
267: The origin is a way of changing the origin in a data file.
268: The line starts in column 1, and is followed by a domain origin.
269: This is useful for putting more then one domain in a data file.
270: .sh 3 "SOA - Start Of Authority"
271: .(b L
272: .TS
273: l l l l l l.
274: \fIname {ttl} addr-class SOA Origin Person in charge\fP
275: @ IN SOA ucbvax\fB.\fPBerkeley\fB.\fPEdu\fB.\fP kjd\fB.\fPucbvax\fB.\fPBerkeley\fB.\fPEdu\fB.\fP (
276: 1\|.\|1 ; Serial
277: 10800 ; Refresh
278: 1800 ; Retry
279: 3600000 ; Expire
280: 86400 ) ; Minimum
281: .TE
282: .)b
283: The \fIStart of Authority, SOA,\fP record designates the start of a zone.
284: The name is the name of the zone.
285: Origin is the name of the host on which this data file resides.
286: Person in charge is the mailing address for the person responsible
287: for the name server.
288: The serial number is the version number of this data file,
289: this number should be incremented whenever a change is made to the data.
290: The name server cannot handle numbers over 9999 after the decimal point.
291: The refresh indicates how often, in seconds, a secondary name servers
292: is to check with the primary name server to see if an update is needed.
293: The retry indicates how long, in seconds, a secondary server is to retry
294: after a failure to check for a refresh.
295: Expire is the upper limit, in seconds, that a secondary name server
296: is to use the data before it expires for lack of getting a refresh.
297: Minimum is the default number of seconds to be used for the time to live
298: field on resource records.
299: There should only be one \fISOA\fP record per zone.
300: .sh 3 "NS - Name Server"
301: .TS
302: l l l l l.
303: \fI{name} {ttl} addr-class NS Name servers name\fP
304: IN NS ucbarpa\fB\|.\|\fPBerkeley\fB\|.\|\fPEdu\fB.\fP
305: .TE
306: The \fIName Server\fP record, \fINS\fP, lists a name server responsible
307: for a given domain.
308: The first name field lists the domain that is serviced by
309: the listed name server.
310: There should be one \fINS\fP record for each Primary Master
311: server for the domain.
312: .sh 3 "A - Address"
313: .TS
314: l l l l l.
315: \fI{name} {ttl} addr-class A address\fP
316: ucbarpa IN A 128\fB.\fP32\fB.\fP0\fB.\fP4
317: IN A 10\fB.\fP0\fB.\fP0\fB.\fP78
318: .TE
319: The \fIAddress\fP record, \fIA\fP, lists the address for a given machine.
320: The name field is the machine name and the address is the network address.
321: There should be one \fIA\fP record for each address of the machine.
322: .sh 3 "HINFO - Host Information"
323: .TS
324: l l l l l l.
325: \fI{name} {ttl} addr-class HINFO Hardware OS\fP
326: IN HINFO VAX-11/780 UNIX
327: .TE
328: \fIHost Information\fP resource record, \fIHINFO\fP, is for host specific data.
329: This lists the hardware and operating system that are running at
330: the listed host.
331: It should be noted that only a single space separates the hardware info
332: and the operating system info.
333: If you want to include a space in the machine name you must quote the name.
334: There should be one \fIHINFO\fP record for each host.
335: .(b L
336: .sh 3 "WKS - Well Known Services"
337: .TS
338: l l l l l l l.
339: \fI{name} {ttl} addr-class WKS address protocol list of services\fP
340: IN WKS 128\fB.\fP32\fB.\fP0\fB.\fP10 UDP who route timed domain
341: IN WKS 128\fB.\fP32\fB.\fP0\fB.\fP10 TCP ( echo telnet
342: discard sunrpc sftp
343: uucp-path systat daytime
344: netstat qotd nntp
345: link chargen ftp
346: auth time whois mtp
347: pop rje finger smtp
348: supdup hostnames
349: domain
350: nameserver )
351: .TE
352: The \fIWell Known Services\fP record, \fIWKS\fP,
353: describes the well known services
354: supported by a particular protocol at a specified address.
355: The list of services and port numbers come from the list of services
356: specified in \fI/etc/services.\fP
357: There should be only one \fIWKS\fP record per protocol per address.
358: .)b
359: .sh 3 "CNAME - Canonical Name"
360: .TS
361: l l l l l.
362: \fIaliases {ttl} addr-class CNAME Canonical name\fP
363: ucbmonet IN CNAME monet
364: .TE
365: \fICanonical Name\fP resource record, \fICNAME\fP, specifies an
366: alias for a canonical name.
367: An alias should be the only record associated with the alias name;
368: all other resource records should be
369: associated with the canonical name and not with the alias.
370: Any resource records that include a domain name as their value (e.g. NS or MX)
371: should list the canonical name, not the alias.
372: .sh 3 "PTR - Domain Name Pointer"
373: .TS
374: l l l l l.
375: \fIname {ttl} addr-class PTR real name\fP
376: 7.0 IN PTR monet\fB\|.\|\fPBerkeley\fB\|.\|\fPEdu\fB\|.\fP
377: .TE
378: A \fIDomain Name Pointer\fP record, \fIPTR\fP, allows special names
379: to point to some other location in the domain.
380: The above example of a \fIPTR\fP record is used in setting up reverse pointers
381: for the special \fIIN-ADDR\fP\fB\|.\|\fP\fIARPA\fP domain. This line is from the example
382: \fIhosts.rev\fP file.
383: \fIPTR\fP names should be unique to the zone.
384: .sh 3 "MB - Mailbox"
385: .TS
386: l l l l l.
387: \fIname {ttl} addr-class MB Machine \fP
388: miriam IN MB vineyd\fB.\fPDEC\fB.\fPCOM\fB.\fP
389: .TE
390: \fIMB\fP is the \fIMailbox\fP record.
391: This lists the machine where a user wants to receive mail.
392: The name field is the users login; the machine field denotes the machine
393: to which mail is to be delivered.
394: Mail Box names should be unique to the zone.
395: (These records are currently for experimental use only.)
396: .sh 3 "MR - Mail Rename Name"
397: .TS
398: l l l l l.
399: \fIname {ttl} addr-class MR corresponding MB\fP
400: Postmistress IN MR miriam
401: .TE
402: \fIMain Rename, MR,\fP can be used to list aliases for a user.
403: The name field lists the alias for the name listed in the fourth field,
404: which should have a corresponding \fIMB\fP record.
405: (These records are currently for experimental use only.)
406: .sh 3 "MINFO - Mailbox Information"
407: .TS
408: l l l l l l.
409: \fIname {ttl} addr-class MINFO requests maintainer\fP
410: BIND IN MINFO BIND-REQUEST kjd\fB\|.\|\fPBerkeley\fB\|.\|\fPEdu\fB\|.\fP
411: .TE
412: \fIMail Information\fP record, \fIMINFO\fP, creates a mail
413: group for a mailing list.
414: This resource record is usually associated with a mail group \fIMail Group\fP,
415: but may be used with a \fIMail Box\fP record.
416: The \fIname\fP specifies the name of the mailbox.
417: The \fIrequests\fP field
418: is where mail such as requests to be added to a mail group should be sent.
419: The \fImaintainer\fP is a mailbox that should receive error messages.
420: This is particularly appropriate for mailing lists when
421: errors in members names should be reported to a person other than
422: the sender.
423: (These records are currently for experimental use only.)
424: .sh 3 "MG - Mail Group Member"
425: .TS
426: l l l l l l.
427: \fI{mail group name} {ttl} addr-class MG member name\fP
428: IN MG Bloom
429: .TE
430: \fIMail Group, MG\fP lists members of a mail group.
431: (These records are currently for experimental use only.)
432:
433: An example for setting up a mailing list is as follows:
434: .TS
435: l l l l l l.
436: Bind IN MINFO Bind-Request kjd\fB\|.\|\fPBerkeley\fB\|.\|\fPEdu\fB\|.\fP
437: IN MG Ralph\fB\|.\|\fPBerkeley\fB\|.\|\fPEdu\fB\|.\fP
438: IN MG Zhou\fB\|.\|\fPBerkeley\fB\|.\|\fPEdu\fB\|.\fP
439: IN MG Painter\fB\|.\|\fPBerkeley\fB\|.\|\fPEdu\fB\|.\fP
440: IN MG Riggle\fB\|.\|\fPBerkeley\fB\|.\|\fPEdu\fB\|.\fP
441: IN MG Terry\fB\|.\|\fPpa\fB\|.\|\fPXerox\fB\|.\|\fPCom\fB\|.\fP
442: .TE
443: .sh 3 "MX - Mail Exchanger"
444: .TS
445: l l l l l l.
446: \fIname {ttl} addr-class MX preference value mailer exchanger\fP
447: Munnari\fB\|.\|\fPOZ\fB\|.\|\fPAU\fB\|.\fP IN MX 0 Seismo\fB\|.\|\fPCSS\fB\|.\|\fPGOV\fB\|.\fP
448: *\fB\|.\|\fPIL\fB\|.\fP IN MX 0 RELAY\fB\|.\|\fPCS\fB\|.\|\fPNET\fB\|.\fP
449: .TE
450: \fIMain Exchanger\fP records, \fIMX\fP, are used to specify a
451: machine that knows how to deliver
452: mail to a machine that is not directly connected to the network.
453: In the first example, above, Seismo\fB\|.\|\fPCSS\fB\|.\|\fPGOV\fB\|.\fP is a mail gateway
454: that knows how to
455: deliver mail to Munnari\fB\|.\|\fPOZ\fB\|.\|\fPAU\fB\|.\fP but other machines
456: on the network can not deliver mail directly to Munnari.
457: These two machines may have a private connection or use a different
458: transport medium.
459: The preference value is the order that a mailer should follow
460: when there is more then one way to deliver mail to a single machine.
461: See RFC974 for more detailed information.
462: .pp
463: Wildcard names containing the character ``*'' may be
464: used for mail routing with \fIMX\fP records.
465: There are likely to be servers on the network
466: that simply state that any mail to a domain is to be routed through a relay.
467: Second example, above, all mail to hosts in the domain IL is routed through RELAY.CS.NET.
468: This is done by creating a wildcard resource record,
469: which states that *.IL has an \fIMX\fP
470: of RELAY.CS.NET.
471: .sh 2 "Sample Files"
472: .pp
473: The following section contains sample files for the name server.
474: This covers example boot files for the different types of servers
475: and example domain data base files.
This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.