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