diff options
Diffstat (limited to 'contrib/bind/doc/bog/files.me')
| -rw-r--r-- | contrib/bind/doc/bog/files.me | 1150 |
1 files changed, 0 insertions, 1150 deletions
diff --git a/contrib/bind/doc/bog/files.me b/contrib/bind/doc/bog/files.me deleted file mode 100644 index ae755ff..0000000 --- a/contrib/bind/doc/bog/files.me +++ /dev/null @@ -1,1150 +0,0 @@ -.\" ++Copyright++ 1986, 1988, 1995 -.\" - -.\" Copyright (c) 1986, 1988, 1995 -.\" The Regents of the University of California. All rights reserved. -.\" -.\" Redistribution and use in source and binary forms, with or without -.\" modification, are permitted provided that the following conditions -.\" are met: -.\" 1. Redistributions of source code must retain the above copyright -.\" notice, this list of conditions and the following disclaimer. -.\" 2. Redistributions in binary form must reproduce the above copyright -.\" notice, this list of conditions and the following disclaimer in the -.\" documentation and/or other materials provided with the distribution. -.\" 3. All advertising materials mentioning features or use of this software -.\" must display the following acknowledgement: -.\" This product includes software developed by the University of -.\" California, Berkeley and its contributors. -.\" 4. Neither the name of the University nor the names of its contributors -.\" may be used to endorse or promote products derived from this software -.\" without specific prior written permission. -.\" -.\" THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND -.\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE -.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE -.\" ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE -.\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL -.\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS -.\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) -.\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT -.\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY -.\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF -.\" SUCH DAMAGE. -.\" - -.\" Portions Copyright (c) 1993 by Digital Equipment Corporation. -.\" -.\" Permission to use, copy, modify, and distribute this software for any -.\" purpose with or without fee is hereby granted, provided that the above -.\" copyright notice and this permission notice appear in all copies, and that -.\" the name of Digital Equipment Corporation not be used in advertising or -.\" publicity pertaining to distribution of the document or software without -.\" specific, written prior permission. -.\" -.\" THE SOFTWARE IS PROVIDED "AS IS" AND DIGITAL EQUIPMENT CORP. DISCLAIMS ALL -.\" WARRANTIES WITH REGARD TO THIS SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES -.\" OF MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL DIGITAL EQUIPMENT -.\" CORPORATION BE LIABLE FOR ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL -.\" DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR -.\" PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS -.\" ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS -.\" SOFTWARE. -.\" - -.\" --Copyright-- -.\" -.\" @(#)files.me 6.8 (Berkeley) 9/19/89 -.\" -.sh 1 "Files -.pp -The name server uses several files to load its data base. -This section covers the files and their formats needed for \fInamed\fP. -.sh 2 "Boot File" -.pp -This is the file that is first read when \fInamed\fP starts up. -This tells the server what type of server it is, -which -zones it has authority over and where to get its initial data. -The default location for this file is \fI/etc\|/named.boot\fP\|. -However this can be changed -by setting the \fIBOOTFILE\fP variable when you compile \fInamed\fP -or by specifying -the location on the command line when \fInamed\fP is started up. -.sh 3 "Domain" -.pp -A default domain may be specified for the name server -using a line such as -.(b l -.ta 0.5i +\w`secondary `u +\w`berkeley.edu `u +.5i +.5i -\fIdomain Berkeley\fP\fB\|.\|\fP\fIEdu\fP -.)b -.re -Older name servers use this information when they receive a query for a name -without a ``\fB.\fP'' that is not known. Newer designs assume that the -resolver library will append its own idea of a ``default domain'' to any -unqualified names. Though the name server can still be compiled with -support for the \fIdomain\fP directive in the boot file, the default is to -leave it out and we strenuously recommend against its use. If you use this -feature, clients outside your local domain which send you requests about -unqualified names will have the implicit qualification of your domain rather -than theirs. The proper place for this function is on the client, in their -\fB/etc/resolv.conf\fP (or equivalent) file. Use of the \fIdomain\fP -directive in your boot file is strongly discouraged. -.sh 3 "Directory" -.pp -The \fIdirectory\fP directive specifies the directory in which the name server -should run, allowing the other file names in the boot file to use relative path -names. There can be only one \fIdirectory\fP directive and it should be given -before any other directives that specify file names. -.(b l -.ta 0.5i +\w`secondary `u +\w`berkeley.edu `u +.5i +.5i -\fIdirectory /var/named\fP -.)b -.re -If you have more than a couple of named files to be maintained, you may wish -to place the named files in a directory such as /var/named and adjust the -directory command properly. The main purposes of this command are to make -sure named is in the proper directory when trying to include files by -relative path names with $INCLUDE and to allow named to run in a location -that is reasonable to dump core if it feels the urge. -.sh 3 "Primary Service" -.pp -The line in the boot file that designates the server as a primary master server -for a zone looks as follows: -.(b l -.ta 0.5i +\w`secondary `u +\w`berkeley.edu `u +.5i +.5i -\fIprimary Berkeley\fP\fB\|.\|\fP\fIEdu ucbhosts\fP -.)b -.re -The first field specifies that the server is a primary one for the zone -stated in the second field. -The third field is the name of the file from which the data is read. -.pp -The above assumes that the zone you are specifying is a class \fIIN\fP -zone. If you wish to designate a different class you can append -\fI/class\fP to the first field, where \fIclass\fP is either the -integer value or the standard mnemonic for the class. For example the line -for a primary server for a hesiod class zone looks as follows: -.(b l -.ta 0.5i +\w`secondary `u +\w`berkeley.edu `u +.5i +.5i -\fIprimary/HS Berkeley\fP\fB\|.\|\fP\fIEdu hesiod.data\fP -.)b -.re -Note that this support for specifying other than class \fIIN\fP zones is a -compile-time option which your vendor may not have enabled when they built -your operating system. -.sh 3 "Secondary Service" -.pp -The line for a secondary server is similar to the primary except -that it lists addresses of other servers (usually primary servers) -from which the zone data will be obtained. -.(b l -.ta 0.5i +\w`secondary `u +\w`berkeley.edu `u +\w`128.32.0.10 `u +\w`128.32.0.10 `u +.5i +.5i -\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 -.)b -.re -The first field specifies that the server is a secondary server for -the zone stated in the second field. -The two network addresses specify the name servers which have data for the -zone. Note that at least one of these will be a \fIprimary\fP, and, unless -you are using some protocol other than \s-1IP/DNS\s+1 for your zone transfer -mechanism, the others will all be other \fIsecondary\fP servers. Having your -secondary server pull data from other secondary servers is usually unwise, -since you can add delay to the propagation of zone updates if your network's -connectivity varies in pathological but common ways. The intended use for -multiple addresses on a \fIsecondary\fP declaration is when the \fIprimary\fP -server has multiple network interfaces and therefore multiple host addresses. -The secondary server gets its data across the network from one of the listed -servers. The server addresses are tried in the order listed. -If a filename is present after the list of primary servers, data for the zone -will be dumped into that file as a backup. -When the server is first started, the data is loaded from the backup file -if possible, and a primary server is then consulted to check that the zone -is still up-to-date. Note that listing your server as a \fIsecondary\fP -server does not necessarily make it one \(em the parent zone must -\fIdelegate\fP authority to your server as well as the primary and the -other secondaries, or you will be transferring a zone over for no reason; -no other server will have a reason to query you for that zone unless the -parent zone lists you as a server for the zone. -.pp -As with primary you may specify a secondary server for a class other than -\fIIN\fP by appending \fI/class\fP to the \fIsecondary\fP keyword, e.g., -\fIsecondary/HS\fP. -.sh 3 "Stub Service" -.pp -The line for a stub server is similar to a secondary. -(This feature is experimental as of 4.9.3.) -.(b l -.ta 0.5i +\w`stub `u +\w`berkeley.edu `u +\w`128.32.0.10 `u +\w`128.32.0.10 `u +.5i +.5i -\fIstub 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 -.)b -.re -The first field specifies that the server is a stub server for the zone stated -in the second field. -.pp -Stub zones are intended to ensure that a primary for a zone always has the -correct \fINS\fP records for children of that zone. If the primary is not -a secondary for a child zone it should be configured with stub zones for -all its children. Stub zones provide a mechanism to allow \fINS\fP records -for a zone to be specified in only one place. -.(b l -.ta 0.5i +\w`primary `u +\w`dms.csiro.au `u +\w`130.155.98.1 `u +.5i +.5i -\fIprimary CSIRO\fP\fB\|.\|\fP\fIAU \fIcsiro.dat\fP -\fIstub dms.CSIRO\fP\fB\|.\|\fP\fIAU 130\fP\fB.\fP\fI155\fP\fB.\fP\fI16\fP\fB.\fP\fI1 \fIdms.stub\fP -\fIstub dap.CSIRO\fP\fB\|.\|\fP\fIAU 130\fP\fB.\fP\fI155\fP\fB.\fP\fI98\fP\fB.\fP\fI1 \fIdap.stub\fP -.)b -.re -.sh 3 "Cache Initialization" -.pp -All servers, including ``caching only'' servers, should have a line as -follows in the boot file to prime the name servers cache: -.(b l -\fIcache \fP\fB.\fP\fI root\fP\fB.\fP\fIcache\fP -.)b -Do not put anything into your \fIcache\fP files other than root server -information. -.pp -All cache files listed will be read in at named boot time and any values -still valid will be reinstated in the cache. -The root name server -information in the cache files will be used until a root query is -actually answered by one of the name servers in the cache file, after -which that answer will be used instead of the cache file until the answer -times out. -.pp -As with \fIprimary\fP and \fIsecondary\fP, you may specify a secondary -server for a class other than \fIIN\fP by appending \fI/class\fP to the -\fIcache\fP keyword, e.g., \fIclass/HS\fP. -.sh 3 "Forwarders" -.pp -Any server can make use of \fIforwarders\fP. A \fIforwarder\fP is another -server capable of processing recursive queries that is willing to try -resolving queries on behalf of other systems. The \fIforwarders\fP -command specifies forwarders by internet address as follows: -.(b l -\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 -.)b -.re -There are two main reasons for wanting to do so. First, some systems may -not have full network access and may be prevented from sending any IP -packets into the rest of the Internet and therefore must rely on a forwarder -which does have access to the full net. The second reason is that the -forwarder sees a union of all queries as they pass through its server and -therefore it builds up a very rich cache of data compared to the cache in a -typical workstation name server. In effect, the \fIforwarder\fP becomes a -meta-cache that all hosts can benefit from, thereby reducing the total -number of queries from that site to the rest of the net. -.pp -The effect of ``forwarders'' is to prepend some fixed addresses to the list -of name servers to be tried for every query. Normally that list is made up -only of higher-authority servers discovered via \fINS\fP record lookups for -the relevant domain. If the forwarders do not answer, then unless the -\fIslave\fP directive was given, the appropriate servers for the domains -will be queried directly. - -.sh 3 "Slave Servers" -.pp -Slave mode is used if the use of forwarders is the only possible way -to resolve queries due to lack of full net access or if you wish to prevent -the name server from using other than the listed forwarders. -Slave mode is activated by placing the simple command -.(b l -\fIoptions forward-only\fP -.)b -in the bootfile. If this option is used, then you must specify forwarders. -When in slave mode, the server will forward each query to each of the -forwarders until an answer is found or the list of forwarders is exhausted. -The server will not try to contact any remote name server other than those -named in the \fIforwarders\fP list. -.pp -So while \fIforwarders\fP prepends addresses to the ``server list'' for each -query, \fIoptions forward-only\fP causes the ``server list'' to contain -\fIonly\fP those addresses listed in the \fIforwarders\fP declarations. -Careless use of the \fIoptions forward-only\fP directive can cause really -horrible forwarding loops, since -you could end up forwarding queries only to some set of hosts which are also -slaves, and one or several of them could be forwarding queries back to you. -.pp -Use of the \fIoptions forward-only\fP directive should be considered very -carefully. Note that this same behaviour can be achieved using the deprecated -directive, \fIslave\fP. - -.sh 3 "Nonrecursive Servers" -.pp -\s-1BIND\s+1's separation of authoritative (zone) and nonauthoritiative (cache) -data has always been somewhat weak, and pollution of the former via the latter -has been known to occur. One way to prevent this, as well as to save memory on -servers carrying a lot of authoritative data (e.g., root servers) is to make -such servers ``nonrecursive.'' This can be achieved via the directive -.(b l -\fIoptions no-recursion\fP -.)b -in the bootfile. A server with this option enabled will not attempt to fetch -data to help answer queries \(em if you ask it for data it does not have, it -will send you a referral to a more authoritative server or, if it is itself -authoritative for the zone of the query, it will send you an negative answer. -.pp -A nonrecursive server can be named in an \s-1NS\ RR\s+1 but it cannot be listed -in the \fIresolv.conf\fP file. - -.sh 3 "Query Logging" -.pp -If the file system containing your \fIsyslog\fP file has quite a bit of space, -you can consider using the -.(b l -\fIoptions query-log\fP -.)b -directive in your bootfile. This will cause your name server to log every -query it receives, which when combined with a Perl or \s-1AWK\s+1 script to -postprocess the logs, can be a useful management tool. - -.sh 3 "Inverse Query Pseudosupport" -.pp -\s-1BIND\s+1 by default does not support inverse queries, and this has been -known to cause problems for certain microcomputer operating systems and for -older versions of \s-1BIND\s+1's \fInslookup\fP tool. You may decide that -rather than answering with ``operation not implemented,'' \fInamed\fP should -detect the most common inverse queries and answer them with bogus information. -It is better to upgrade your clients to stop depending on inverse queries, but -if that is not possible, you should use the -.(b l -\fIoptions fake-iquery\fP -.)b -directive in your bootfile. \fINOTE:\fP the responses are in fact bogus, in -that they contain \s-1ISO\s+18859 square brackets (\fB[\fP and \fB]\fP), so -your clients will not be able to do anything useful with these responses. It -has been observed that no client ever did anything useful with real inverse -query responses, either. - -.sh 3 "Setting Name Server Limits" -.pp -Some name server operations can be quite resource intensive, and in order to -tune your system properly it is sometimes necessary to change \s-1BIND\s+1's -internal quotas. This is accomplished via -.(b l -\fIlimit <name> <value>\fP -.)b -directives in the bootfile. Limits, and their default values, are as follows: -.(b I -\fIlimit transfers-in 10\fP -.)b -This is the number of simultaneous \fInamed-xfer\fP processes \s-1BIND\s+1 is -willing to start. Higher numbers yield faster convergence to primary servers -if your secondary server has hundreds or thousands of zones to maintain, but -setting this number too high can cause thrashing due to starvation of resources -such as network bandwidth or swap space. \fINOTE:\fP this limit can also be -expressed via the deprecated directive \fImax-fetch NN\fP. -.(b I -\fIlimit transfers-per-ns 2\fP -.)b -This is the number of simultaneous \fInamed-xfer\fP processes \s-1BIND\s+1 is -willing to initiate \fIto any given name server\fP. In most cases, you should -not need to change it. If your secondary server is pulling hundreds or -thousands of zones from a single primary server, increasing -\fItransfers-per-ns\fP may speed convergence. It should be kept as -small as possible, to avoid causing thrashing and resource starvation -on the primary server. -.(b I -\fIlimit datasize <system-dependent>\fP -.)b -Most systems have a quota that limits the size of the so-called ``data -segment,'' which is where \s-1BIND\s+1 keeps all of its authority and cache -data. \s-1BIND\s+1 will behave suboptimally (perhaps even exiting) if it runs -up against this quota. If your system supports a system call to change this -quota for a given process, you can ask \s-1BIND\s+1 to use that system call -via the \fIlimit datasize NN\fP directive. The value given here may be scaled -by postfixing \fIk\fP for 1024X, \fIm\fP for (1024^2)X, and \fIg\fP for -(1024^3)X. In 1995, the root servers all use \fIlimit datasize 64m\fP. - -.sh 3 "Zone Transfer Restrictions" -.pp -It may be the case that your organization does not wish to give complete -lists of your hosts to anyone on the Internet who can reach your name servers. -While it is still possible for people to ``iterate'' through your address -range, looking for \fIPTR\fP records, and build a list of your hosts the -``slow'' way, it is still considered reasonable to restrict your export of -zones via the zone transfer protocol. To limit the list of neighbors who -can transfer zones from your server, use the \fIxfrnets\fP directive. -.pp -This directive has the same syntax as \fIforwarders\fP except that you can -list network numbers in addition to host addresses. For example, you could -add the directive -.(b l -\fIxfrnets 16.0.0.0\fP -.)b -.re -if you wanted to permit only hosts on Class A network number 16 to transfer -zones from your server. This is not nearly granular enough, and a future -version of \s-1BIND\s+1 will permit such access-control to be specified on a -per-host basis rather than the current per-net basis. Note that while -addresses without explicit masks are assumed by this directive to be networks, -you can specify a mask which is as granular as you wish, perhaps including -all bits of the address such that only a single host is given transfer -permission. For example, consider -.(b l -\fIxfrnets 16.1.0.2&255.255.255.255\fP -.)b -which would permit only host \fI16.1.0.2\fP to transfer zones from you. Note -that no spaces are allowed surrounding the ``\fI&\fP'' character that -introduces a netmask. -.pp -The \fIxfrnets\fP directive may also be given as \fItcplist\fP for -compatibility with interim releases of \s-1BIND\s+1 4.9. - -.sh 3 "Sorting Addresses" -.pp -If there are multiple addresses available for a name server which \s-1BIND\s+1 -wants to contact, \s-1BIND\s+1 will try the ones it believes are ``closest'' -first. ``Closeness'' is defined in terms of similarity-of-address; that is, -if one address is on the same \fIsubnet\fP as some interface of the local host, -then that address will be tried first. Failing that, an address which is on -the same \fInetwork\fP will be tried first. Failing that, they will be tried -in a more-or-less random order unless the \fIsortlist\fP directive was given -in the \fInamed.boot\fP file. \fIsortlist\fP has a syntax similar to -\fIforwarders\fP, \fIxfrnets\fP, and \fIbogusns\fP \(em you give it a list -of dotted-quad networks and it uses these to ``prefer'' some remote name server -addresses over others. If no explicit mask is provided with each element of -a \fIsortlist\fP, one will be inferred based on the high order address bits. -.pp -If you are on a Class C net which has a Class B net between you and the rest -of the Internet, you could try to improve the name server's luck in getting -answers by listing the Class B network's number in a \fIsortlist\fP -directive. This should have the effect of trying ``closer'' servers before -the more ``distant'' ones. Note that this behaviour is new as of \s-1BIND -4.9\s+1. -.pp -The other and older effect of the \fIsortlist\fP directive is to cause -\s-1BIND\s+1 to sort the \fIA\fP records in any response it generates, so as -to put those which appear on the \fIsortlist\fP earlier than those which do -not. This is not as helpful as you might think, since many clients will -reorder the \fIA\fP records either at random or using \s-1LIFO\s+1; also, -consider the fact that the server won't be able to guess the client's network -topology, and so will not be able to accurately order for ``closeness'' to -all possible clients. Doing the ordering in the resolver is clearly superior. -.pp -In actual practice, this directive is used only rarely since it hardwires -information which changes rapidly; a network which is ``close'' today may -be ``distant'' next month. Since \s-1BIND\s+1 builds up a cache of the -remote name servers' response times, it will quickly converge on -``reasonable'' behaviour, which isn't the same as ``optimal'' but it's -close enough. Future directions for \s-1BIND\s+1 include choosing -addresses based on local interface metrics (on hosts that have more than -one) and perhaps on routing table information. We do not intend to solve -the generalized ``multihomed host'' problem, but we should be able to do a -little better than we're doing now. Likewise, we hope to see a higher -level resolver library that sorts responses using topology information that -only exists on the client's host. - -.sh 3 "Bogus Name Servers" -.pp -It happens occasionally that some remote name server goes ``bad''. You can -tell your name server to refuse to listen to or ask questions of certain -other name servers by listing them in a \fIbogusns\fP directive in your -\fInamed.boot\fP file. Its syntax is the same as \fIforwarders\fP, -\fIxfrnets\fP, and \fIsortlist\fP \(em you just give it a list of dotted-quad -Internet addresses. Note that zones delegated to such servers will not be -reachable from clients of your servers; thus you should use this directive -sparingly or not at all. - -.sh 3 "Segmented Boot Files" -.pp -If you are secondary for a lot of zones, you may find it convenient to split -your \fInamed.boot\fP file into a static portion which hardly ever changes -(directives such as \fIdirectory\fP, \fIsortlist\fP, \fIxfrnets\fP and -\fIcache\fP could go here), and dynamic portions that change frequently -(all of your \fIprimary\fP directives might go in one file, and all of your -\fIsecondary\fP directives might go in another file \(em and either or both -of these might be fetched automatically from some neighbor so that they can -change your list of secondary zones without requiring your active -intervention). You can accomplish this via the \fIinclude\fP directive, -which takes just a single file name as its argument. No quotes are needed -around the file name. The file name will be evaluated after the name server -has changed its working directory to that specified in the \fIdirectory\fP -directive, so you can use relative pathnames if your system supports them. - -.sh 2 "Resolver Configuration" -.pp -The configuration file's name is \fI/etc/resolv.conf\fP. -This file designates the name servers on the network that should -be sent queries. -The resolver will try to contact a name server on the localhost if it cannot -find its configuration file. You should install the configuration file -on every host anyway, since this is the only recommended way to specify a -system-level default domain, and you can still list the local host's address -if it runs a name server. -It is considered reasonable to create this file even if you run a local -server, since its contents will be cached by each client of the resolver -library when the client makes its first call to a resolver routine. -.pp -The \fIresolv.conf\fP file contains directives, one per line, of the -following forms: -.(l I -; comment -# another comment -domain \fIlocal-domain\fP -search \fIsearch-list\fP -nameserver \fIserver-address\fP -sortlist \fIsort-list\fP -options \fIoption-list\fP -.)l -Exactly one of the \fIdomain\fP or \fIsearch\fP directives should be given, -exactly once. -If the \fIsearch\fP directive is given, the first item in the given -\fIsearch-list\fP will override any previously-specified \fIlocal-domain\fP. -The \fInameserver\fP directive may be given up to three times; additional -\fInameserver\fP directives will be ignored. Comments may be given by -starting a line with a ``\fB\|;\|\fP'' or ``\fB\|#\|\fP''; note that -comments were not permitted in versions of the resolver earlier than the one -included with \s-1BIND 4.9\s+1 \(em so if your vendor's resolver supports -comments, you know they are really on the ball. -.pp -The \fIlocal-domain\fP will be appended to any query-name that does not -contain a ``\fB\|.\|\fP''. \fIlocal-domain\fP can be overridden on a -per-process basis by setting the \s-1LOCALDOMAIN\s+1 environment variable. -Note that \fIlocal-domain\fP processing can be disabled by setting an -option in the resolver. -.pp -The \fIsearch-list\fP is a list of domains which are tried, in order, -as qualifying domains for query-names which do not contain a ``\fB\|.\|\fP''. -Note that \fIsearch-list\fP processing can be disabled by setting an -option in the resolver. Also note that the environment variable -``\s-1LOCALDOMAIN\s+1'' can override this \fIsearch-list\fP on a per-process -basis. -.pp -The \fIserver-address\fP\|'s are aggregated and then used as the default -destination of queries generated through the resolver. In other words, -this is the way you tell the resolver which name servers it should use. It -is possible for a given client application to override this list, and this -is often done inside the name server (which is itself a \fIresolver\fP -client) and in test programs such as \fInslookup\fP. -Note that if you wish to list the -local host in your resolver configuration file, you should probably use its -primary Internet address rather than a local-host alias such as 127.0.0.1 or -0.0.0.0. This is due to a bug in the handling of connected \s-1SOCK_DGRAM\s+1 -sockets in some versions of the \s+1BSD\s-1 networking code. If you must use -an address-alias, you should prefer 0.0.0.0 (or simply ``0'') over 127.0.0.1, -though be warned that depending on the vintage of your \s-1BSD\s+1-derived -networking code, both of them are capable of failing in their own ways. -If your host's IP -implementation does not create a short-circuit route between the default -interface and the loopback interface, then you might also want to add a -static route (eg. in \fB/etc/rc.local\fP) to do so: -.(b l -\fIroute add myhost.domain.name localhost 1\fP -.)b -.pp -The \fIsort-list\fP is a list of IP address, netmask pairs. Addresses -returned by gethostbyname are sorted to the order specified by this list. -Any addresses that do not match the address netmask pair will be returned -after those that do. The netmask is optional and the natural netmask will be -used if not specified. -.pp -The \fIoption-list\fP is a list of options which each override some internal -resolver variable. Supported options at this time are: -.ip \fBdebug\fP -sets the \s-1RES_DEBUG\s+1 bit in \fB_res.options\fP. -.ip \fBndots:\fP\fIn\fP -sets the lower threshold (measured in ``number of dots'') on names given to -\fIres_query\fP() such that names with more than this number of dots will be -tried as absolute names before any \fIlocal-domain\fP or \fIsearch-list\fP -processing is done. The default for this internal variable is ``1''. -.\" .pp -.\" Finally, if the environment variable \s-1HOSTALIASES\s+1 is set, it is -.\" taken to contain the name of a file which in turn contains resolver-level -.\" aliases. These aliases are applied only to names which do not contain any -.\" ``\fB\|.\|\fP'' characters, and they are applied to query-names before the -.\" query is generated. Note that the resolver options governing the operation -.\" of \fIlocal-domain\fP and \fIsearch-list\fP do not apply to -.\" \s-1HOSTALIASES\s+1. - -.sh 2 "Cache Initialization File" -.sh 3 root.cache -.pp -The name server needs to know the servers that are the authoritative name -servers for the root domain of the network. To do this we have to prime the -name server's cache with the addresses of these higher authorities. The -location of this file is specified in the boot file. This file uses the -Standard Resource Record Format (aka. Masterfile Format) covered further on -in this paper. - -.sh 2 "Domain Data Files" -.pp -There are two standard files for specifying the data for a -domain. These are \fIhosts\fP and \fIhost.rev\fP. -These files use the Standard Resource Record Format covered later -in this paper. Note that the file names are arbitrary; many network -administrators prefer to name their zone files after the domains they -contain, especially in the average case which is where a given server -is primary and/or secondary for many different zones. -.sh 3 hosts -.pp -This file contains all the data about the machines in this zone. -The location of this file is specified in the boot file. -.sh 3 hosts.rev -.pp -This file specifies the IN-ADDR\|.\|ARPA domain. -This is a special domain for allowing address to name mapping. -As internet host addresses do not fall within domain boundaries, -this special domain was formed to allow inverse mapping. -The IN-ADDR\|.\|ARPA domain has four -labels preceding it. These labels correspond to the 4 octets of -an Internet address. -All four octets must be specified even if an octet contains zero. -The Internet address 128.32.0.4 is located in the domain -4\|.\|0\|.\|32\|.\|128\|.\|IN-ADDR\|.\|ARPA. -This reversal of the address is awkward to read but allows -for the natural grouping of hosts in a network. -.sh 3 named.local -.pp -This file specifies the \fIPTR\fP record for the local loopback interface, -better known as \fIlocalhost\fP, whose network address is 127.0.0.1. The -location of this file is specified in the boot file. It is vitally -important to the proper operation of every name server that the 127.0.0.1 -address have a \fIPTR\fP record pointing back to the name -``\fBlocalhost.\fP''. The name of this \fIPTR\fP record is always -``\fB1.0.0.127.\s-1IN-ADDR.ARPA\s+1\fP''. This is necessary if you want -your users to be able to use hostname-authentication (\fIhosts.equiv\fP or -\fI~/.rhosts\fP) on the name ``\fBlocalhost\fP''. As implied by this -\fIPTR\fP record, there should be a ``\fBlocalhost.\fP\fImy.dom.ain\fP'' -\fIA\fP record (with address 127.0.0.1) in every domain that contains hosts. -``\fBlocalhost.\fP'' will lose its trailing dot when -\fB1.0.0.127.in-addr.arpa\fP is queried for; then, the DEFNAMES and/or -DNSRCH resolver options will cause ``\fBlocalhost\fP'' to be evaluated as a -host name in the local domain, and that means the top domains (or ideally, -every domain) in your resolver's search path had better have something by -that name. -.sh 2 "Standard Resource Record Format" -.pp -The records in the name server data files are called resource records. -The Standard Resource Record Format (RR) is specified in RFC1035. -The following is a general description of these records: -.TS -l l l l l. -\fI{name} {ttl} addr-class Record Type Record Specific data\fP -.TE -Resource records have a standard format shown above. -The first field is always the name of the domain record -and it must always start in column 1. -For all RR's other than the first in a file, the name may be left blank; -in that case it takes on the name of the previous RR. -The second field is an optional time to live field. -This specifies how long this data will be stored in the data base. -By leaving this field blank the default time to live is specified -in the \fIStart Of Authority\fP resource record (see below). -The third field is the address class; currently, only one class is supported: -\fIIN\fP for internet addresses and other internet information. Limited -support is included for the \fIHS\fP class, which is for MIT/Athena ``Hesiod'' -information. -The fourth field states the type of the resource record. -The fields after that are dependent on the type of the RR. -Case is preserved in names and data fields when loaded into the name server. -All comparisons and lookups in the name server data base are case insensitive. -.bl -.b -The following characters have special meanings: -.ip ``\fB.\fP'' -A free standing dot in the name field refers to the root domain. -.ip ``@'' -A free standing @ in the name field denotes the current origin. -.ip "``\eX''" -Where X is any character other than a digit (0-9), -quotes that character so that its special meaning does not apply. -For example, ``\e.'' can be used to place a dot character in a label. -.ip "``\eDDD''" -Where each D is a digit, is the octet corresponding to the -decimal number described by DDD. -The resulting octet is assumed to be text and -is not checked for special meaning. -.ip "``( )''" -Parentheses are used to group data that crosses a line. -In effect, line terminations are not recognized within parentheses. -(At present, this notation only works for SOA RR's and is not optional.) -.ip "``;''" -Semicolon starts a comment; the remainder of the line is ignored. Note -that a completely blank line is also considered a comment, and ignored. -.ip "``*''" -An asterisk signifies wildcarding. Note that this is just another data -character whose special meaning comes about only during internal name -server search operations. Wildcarding is only meaningful for some RR -types (notably \fIMX\fP), and then only in the name field \(em not in -the data fields. -.pp -Anywhere a name appears \(em either in the name field or in some data field -defined to contain names \(em the current origin will be appended if the -name does not end in a ``\fB\|.\|\fP''. -This is useful for appending the current domain name to the data, -such as machine names, but may cause problems where you do not want -this to happen. -A good rule of thumb is that, if the name is not in the domain for which -you are creating the data file, end the name with a ``\fB.\fP''. -.sh 3 $INCLUDE -.pp -An include line begins with $INCLUDE, starting in column 1, -and is followed by a file name, and, optionally, by a new -temporary $ORIGIN to be used while reading this file. -This feature is -particularly useful for separating different types of data into multiple files. -An example would be: -.(b l -$INCLUDE /usr/local/adm/named/data/mail-exchanges -.)b -The line would be interpreted as a request to load the file -\fI/usr/local/adm/named/data/mail-exchanges\fP. The $INCLUDE command does not cause -data to be loaded into a different zone or tree. This is simply a way to -allow data for a given primary zone to be organized in separate files. -Not even the ``temporary $ORIGIN'' feature described above is sufficient -to cause your data to branch out into some other zone \(em zone boundaries -can only be introduced in the boot file. -.pp -A $INCLUDE file must have a name on its first RR. That is, the first -character of the first non-comment line must not be a space. The current -default name in the parent file \fIdoes not\fP carry into the $INCLUDE -file. -.sh 3 $ORIGIN -.pp -The origin is a way of changing the origin in a data file. The line starts -in column 1, and is followed by a domain origin. This seems like it could -be useful for putting more then one zone into a data file, but that's not -how it works. The name server fundamentally requires a given zone to map -entirely to some specific file. You should therefore be very careful to use -$ORIGIN only once at the top of a file, or, within a file, to change to a -``lower'' domain in the zone \(em never to some other zone altogether. -.sh 3 "SOA - Start Of Authority" -.(b L -.TS -l l l l l l. -\fIname {ttl} addr-class SOA Origin Person in charge\fP -@ IN SOA ucbvax\fB.\fPBerkeley\fB.\fPEdu\fB.\fP kjd\fB.\fPucbvax\fB.\fPBerkeley\fB.\fPEdu\fB.\fP ( - 1995122103 ; Serial - 10800 ; Refresh - 1800 ; Retry - 3600000 ; Expire - 259200 ) ; Minimum -.TE -.)b -The \fIStart of Authority, SOA,\fP record designates the start of a zone. -The name is the name of the zone and is often given as ``@'' since this -is always the current $ORIGIN and the SOA RR is usually the first record -of the primary zone file. -Origin is the name of the host on which this data file resides (in other -words, the \fIprimary master\fP server for this zone.) -Person in charge is the e-mail address for the person responsible -for the name server, with ``@'' changed to a ``.''. -The serial number is the version number of this data file and must be a -positive integer. -This number must be incremented whenever a change is made to the data. -Older servers permitted the use of a phantom ``.'' in this and other -numbers in a zone file; the meaning of n.m was ``n000m'' rather than the -more intuitive ``n*1000+m'' (such that 1.234 translated to 1000234 rather -than to 1234). This feature has been deprecated due to its -obscurity, unpredictability, and lack of necessity. -Note that using a ``YYYYMMDDNN'' notation you can still make 100 changes -per day until the year 4294. You should choose a notation that works for -you. If you're a clever \fIperl\fP programmer you could even use \fIRCS\fP -version numbers to help generate your zone serial numbers. -The refresh indicates how often, in seconds, the secondary name servers -are to check with the primary name server to see if an update is needed. -The retry indicates how long, in seconds, a secondary server should wait -before retrying a failed zone transfer. -Expire is the upper limit, in seconds, that a secondary name server -is to use the data before it expires for lack of getting a refresh. -Minimum is the default number of seconds to be used for the Time To Live -field on resource records which do not specify one in the zone file. -It is also an enforced minimum on Time To Live if it is specified on -some resource record (RR) in the zone. -There must be exactly one \fISOA\fP record per zone. -.sh 3 "NS - Name Server" -.TS -l l l l l. -\fI{name} {ttl} addr-class NS Name servers name\fP - IN NS ucbarpa\fB\|.\|\fPBerkeley\fB\|.\|\fPEdu\fB.\fP -.TE -The \fIName Server\fP record, \fINS\fP, lists a name server responsible -for a given domain, creating a \fIdelegation point\fP and a \fIsubzone\fP. -The first name field specifies the zone that is serviced by -the name server specified by the second name. -Every zone needs at least two name servers. -.bp \" ----PLACEMENT HACK---- -.sh 3 "A - Address" -.TS -l l l l l. -\fI{name} {ttl} addr-class A address\fP -ucbarpa IN A 128\fB.\fP32\fB.\fP0\fB.\fP4 - IN A 10\fB.\fP0\fB.\fP0\fB.\fP78 -.TE -The \fIAddress\fP record, \fIA\fP, lists the address for a given machine. -The name field is the machine name and the address is the network address. -There should be one \fIA\fP record for each address of the machine. -.sh 3 "HINFO - Host Information" -.TS -l l l l l l. -\fI{name} {ttl} addr-class HINFO Hardware OS\fP - IN HINFO VAX-11/780 UNIX -.TE -\fIHost Information\fP resource record, \fIHINFO\fP, is for host specific -data. This lists the hardware and operating system that are running at the -listed host. If you want to include a space in the machine name you must -quote the name (using ``"'' characters.) There could be one \fIHINFO\fP -record for each host, though for security reasons most domains don't have -any \fIHINFO\fP records at all. No application depends on them. -.(b L -.sh 3 "WKS - Well Known Services" -.TS -l l l l l l l. -\fI{name} {ttl} addr-class WKS address protocol list of services\fP - IN WKS 128\fB.\fP32\fB.\fP0\fB.\fP10 UDP who route timed domain - IN WKS 128\fB.\fP32\fB.\fP0\fB.\fP10 TCP ( echo telnet - discard sunrpc sftp - uucp-path systat daytime - netstat qotd nntp - link chargen ftp - auth time whois mtp - pop rje finger smtp - supdup hostnames - domain - nameserver ) -.TE -The \fIWell Known Services\fP record, \fIWKS\fP, describes the well known -services supported by a particular protocol at a specified address. The -list of services and port numbers come from the list of services specified -in \fI/etc/services.\fP There should be only one \fIWKS\fP record per -protocol per address. Note that RFC1123 says of \fIWKS\fP records: -.)b -.(l L - 2.2 Using Domain Name Service - ... - An application SHOULD NOT rely on the ability to locate a WKS - record containing an accurate listing of all services at a - particular host address, since the WKS RR type is not often used - by Internet sites. To confirm that a service is present, simply - attempt to use it. - ... - 5.2.12 WKS Use in MX Processing: RFC-974, p. 5 - - RFC-974 [SMTP:3] recommended that the domain system be queried - for WKS ("Well-Known Service") records, to verify that each - proposed mail target does support SMTP. Later experience has - shown that WKS is not widely supported, so the WKS step in MX - processing SHOULD NOT be used. - ... - 6.1.3.6 Status of RR Types - ... - The TXT and WKS RR types have not been widely used by - Internet sites; as a result, an application cannot rely - on the existence of a TXT or WKS RR in most - domains. -.)l -.sh 3 "CNAME - Canonical Name" -.TS -l l l l l. -\fIalias {ttl} addr-class CNAME Canonical name\fP -ucbmonet IN CNAME monet -.TE -The \fICanonical Name\fP resource record, \fICNAME\fP, specifies an -alias or nickname for the official, or canonical, host name. -This record must be the only one associated with the alias name. -All other resource records must be -associated with the canonical name, not with the nickname. -Any resource records that include a domain name as their value -(e.g., NS or MX) \fImust\fP list the canonical name, not the nickname. -Similarly, a CNAME will be followed when searching for A RRs, but not -for MX RRs or NS RRs or most other types of RRs. CNAMEs are allowed -to point to other CNAMEs, but this is considered sloppy. -.pp -Nicknames are useful when a well known host changes its name. In that -case, it is usually a good idea to have a \fICNAME\fP record so that -people still using the old name will get to the right place. -.sh 3 "PTR - Domain Name Pointer" -.TS -l l l l l. -\fIname {ttl} addr-class PTR real name\fP -7.0 IN PTR monet\fB\|.\|\fPBerkeley\fB\|.\|\fPEdu\fB\|.\fP -.TE -A \fIDomain Name Pointer\fP record, \fIPTR\fP, allows special names to point -to some other location in the domain. The above example of a \fIPTR\fP -record is used in setting up reverse pointers for the special -\fIIN-ADDR\fP\fB\|.\|\fP\fIARPA\fP domain. This line is from the example -\fIhosts.rev\fP file. \fIPTR\fP records are needed by the -\fIgethostbyaddr\fP function. Note the trailing ``\fB\|.\|\fP'' which -prevents \s-1BIND\s+1 from appending the current \s-1$ORIGIN\s+1 to that -domain name. -.sh 3 "MX - Mail Exchange" -.TS -l l l l l l. -\fIname {ttl} addr-class MX preference value mail exchange\fP -Munnari\fB\|.\|\fPOZ\fB\|.\|\fPAU\fB\|.\fP IN MX 0 Seismo\fB\|.\|\fPCSS\fB\|.\|\fPGOV\fB\|.\fP -*\fB\|.\|\fPIL\fB\|.\fP IN MX 0 RELAY\fB\|.\|\fPCS\fB\|.\|\fPNET\fB\|.\fP -.TE -\fIMail eXchange\fP records, \fIMX\fP, are used to specify a list of hosts -which are configured to receive mail sent to this domain name. Every name -which receives mail should have an \fIMX\fP since if one is not found at the -time mail is being delivered, an \fIMX\fP will be ``imputed'' with a cost -of 0 and a destination of the host itself. If you want a host to receive -its own mail, you should create an \fIMX\fP for your host's name, pointing -at your host's name. It is better to have this be explicit than to let it -be imputed by remote mailers. -In the first example, above, -Seismo\fB\|.\|\fPCSS\fB\|.\|\fPGOV\fB\|.\fP is a mail gateway that knows how -to deliver mail to Munnari\fB\|.\|\fPOZ\fB\|.\|\fPAU\fB\|.\fP. These two -machines may have a private connection or use a different transport medium. -The preference value is the order that a mailer should follow when there is -more than one way to deliver mail to a single machine. Note that lower -numbers indicate higher precedence, and that mailers are supposed to randomize -same-valued \fIMX\fP hosts so as to distribute the load evenly if the costs -are equal. See RFC974 for more detailed information. -.pp -Wildcard names containing the character ``*'' may be used for mail routing -with \fIMX\fP records. There are likely to be servers on the network that -simply state that any mail to a domain is to be routed through a relay. -Second example, above, all mail to hosts in the domain IL is routed through -RELAY.CS.NET. This is done by creating a wildcard resource record, which -states that *.IL has an \fIMX\fP of RELAY.CS.NET. Wildcard \fIMX\fP records -are not very useful in practice, though, since once a mail message gets to -the gateway for a given domain it still has to be routed \fIwithin\fP that -domain and it is not currently possible to have an apparently-different set -of \fIMX\fP records inside and outside of a domain. If you won't be needing -any Mail Exchanges inside your domain, go ahead and use a wildcard. If you -want to use both wildcard ``top-level'' and specific ``interior'' \fIMX\fP -records, note that each specific record will have to ``end with'' a complete -recitation of the same data that is carried in the top-level record. This -is because the specific \fIMX\fP records will take precedence over the -top-level wildcard records, and must be able to perform the top-level's -if a given interior domain is to be able to receive mail from outside the -gateway. Wildcard \fIMX\fP records are very subtle and you should be careful -with them. -.sh 3 "TXT - Text" -.TS -l l l l l l. -\fIname {ttl} addr-class TXT string\fP -Munnari\fB\|.\|\fPOZ\fB\|.\|\fPAU\fB\|.\fP IN TXT "foo" -.TE -A \fITXT\fP record contains free-form textual data. The syntax of the text -depends on the domain where it is found; many systems use \fITXT\fP records -to encode local data in a stylized format. MIT Hesiod is one such system. -.sh 3 "RP - Responsible Person" -.TS -l l l l l l. -\fIowner {ttl} addr-class RP mbox-domain-name TXT-domain-name\fP -franklin IN RP ben.franklin.berkeley.edu. sysadmins.berkeley.edu. -.TE -.pp -The Responsible Person record, \fIRP\fP, identifies the name or group name of -the responsible person for a host. Often it is desirable to be able to -identify the responsible entity for a particular host. When that host -is down or malfunctioning, you would want to contact those parties -who might be able to repair the host. -.pp -The first field, \fImbox-domain-name\fP, is a domain name that specifies the -mailbox for the responsible person. Its format in a zone file uses -the \s-1DNS\s+1 convention for mailbox encoding, identical to that used for -the \fIPerson-in-charge\fP mailbox field in the SOA record. -In the example above, the \fImbox-domain-name\fP shows the encoding for -``\fB<ben@franklin.berkeley.edu>\fP''. -The root domain name (just ``\fB\|.\|\fP'') may be specified -to indicate that no mailbox is available. -.pp -The second field, \fITXT-domain-name\fP, is a domain name for which -\fITXT\fP records exist. A subsequent query can be performed to retrieve -the associated \fITXT\fP resource records at \fITXT-domain-name\fP. This -provides a level of indirection so that the entity can be referred to from -multiple places in the \s-1DNS\s+1. The root domain name (just -``\fB\|.\|\fP'') may be specified for \fITXT-domain-name\fI to indicate -that no associated \fITXT\fP RR exists. In the example above, -``\fBsysadmins.berkeley.edu.\fP'' is the name of a TXT record that might -contain some text with names and phone numbers. -.pp -The format of the \fIRP\fP record is class-insensitive. -Multiple \fIRP\fP records at a single name may be present in the database, -though they should have identical TTLs. -.pp -The \fIRP\fP record is still experimental; not all name servers implement -or recognize it. -.sh 3 "AFSDB - DCE or AFS Server" -.TS -l l l l l l. -\fIname {ttl} addr-class AFSDB subtype server host name\fP -toaster.com. IN AFSDB 1 jack.toaster.com. -toaster.com. IN AFSDB 1 jill.toaster.com. -toaster.com. IN AFSDB 2 tracker.toaster.com. -.TE -\fIAFSDB\fP records are used to specify the hosts that provide a style of -distributed service advertised under this domain name. A subtype value -(analogous to the ``preference'' value in the \fIMX\fP record) indicates -which style of distributed service is provided with the given name. -Subtype 1 indicates that the named host is an AFS (R) database server for -the AFS cell of the given domain name. Subtype 2 indicates that the -named host provides intra-cell name service for the DCE (R) cell named by -the given domain name. -In the example above, jack\fB\|.\|\fPtoaster\fB\|.\|\fPcom and -jill\fB\|.\|\fPtoaster\fB\|.\|\fPcom are declared to be AFS database -servers for the toaster\fB\|.\|\fPcom AFS cell, so that AFS clients -wishing service from toaster\fB\|.\|\fPcom are directed to those two hosts -for further information. The third record declares that -tracker\fB\|.\|\fPtoaster\fB\|.\|\fPcom houses a directory server for the -root of the DCE cell toaster\fB\|.\|\fPcom, so that DCE clients that wish -to refer to DCE services should consult with the host -tracker\fB\|.\|\fPtoaster\fB\|.\|\fPcom for further information. The -DCE sub-type of record is usually accompanied by a \fITXT\fP record for -other information specifying other details to be used in accessing the -DCE cell. RFC1183 contains more detailed information on the use of -this record type. -.pp -The \fIAFSDB\fP record is still experimental; not all name servers implement -or recognize it. - -.sh 3 "PX - Pointer to X.400/RFC822 mapping information" -.TS -l l l l l l l. -\fIname {ttl} addr-class PX prefer 822-dom X.400-dom\fP -*.ADMD-garr.X42D.it. IN PX 50 it. ADMD-garr.C-it. -*.infn.it. IN PX 50 infn.it. O.PRMD-infn.ADMD-garr.C-it. -*.it. IN PX 50 it. O-gate.PRMD-garr.ADMD-garr.C-it. -.TE -.pp -The \fIPX\fP records (\fIPointer to X.400/RFC822 mapping information\fP) -are used to specify address mapping rules between X.400 O/R addresses and -RFC822 style (domain-style) mail addresses. For a detailed description of the -mapping process please refer to RFC1327. -.pp -Mapping rules are of 3 different types: -.pp -1) mapping from X.400 to RFC822 (defined as "table 1 rules" in RFC1327) -.pp -2) mapping from RFC822 to X.400 (defined as "table 2 rules" in RFC1327) -.pp -3) encoding RFC822 into X.400 (defined as "gate table" in RFC1327) -.pp -All three types of mapping rules are specified using \fIPX\fP Resource -Records in DNS, although the \fIname\fP value is different: for case 1, the -\fIname\fP value is an X.400 domain in DNS syntax, whereas for cases 2 and -3 the \fIname\fP value is an RFC822 domain. Refer to RFC-1664 for details -on specifying an X.400 domain in DNS syntax and for the use of the -\fIX42D\fP keyword in it. Tools are available to convert from RFC1327 -tables format into DNS files syntax. \fIPreference\fP is analogous to the -\fIMX\fP RR Preference parameter: it is currently advised to use a fixed -value of 50 for it. \fI822-dom\fP gives the RFC822 part of the mapping -rules, and \fIX.400-dom\fP gives the X.400 part of the mapping rule (in DNS -syntax). It is currently advised always to use wildcarded \fIname\fP -values, as the RFC1327 tables specifications permit wildcard -specifications only. This is to keep compatibility with existing services -using static RFC1327 tables instead of DNS \fIPX\fP information. -.pp -Specifications of mapping rules from X.400 to RFC822 syntax requires the -creation of an appropriate X.400 domain tree into DNS, including thus specific -\fISOA\fP and \fINS\fP records for the domain itself. Specification of mapping -rules from RFC822 into X.400 can be embedded directly into the normal direct -\fIname\fP tree. -Again, refer to RFC1664 for details about organization of this structure. -.pp -Tools and library routines, based on the standard resolver ones, are available -to retrieve from DNS the appropriate mapping rules in RFC1327 or DNS syntax. -.pp -Once again, refer to RFC1664 to use the \fIPX\fP resource record, and be careful -in coordinating the mapping information you can specify in DNS with the same -information specified into the RFC1327 static tables. -.pp -The \fIPX\fP record is still experimental; not all servers implement or -recognize it. - -.sh 2 "Discussion about the TTL" -.pp -The Time To Live assigned to the records and to the zone via the -Minimum field in the SOA record is very important. High values will -lead to lower BIND network traffic and faster response time. Lower -values will tend to generate lots of requests but will allow faster -propagation of changes. -.pp -Only changes and deletions from the zone are affected by the TTLs. -Additions propagate according to the Refresh value in the SOA. -.pp -Experience has shown that sites use default TTLs for their zones varying -from around 0.5 day to around 7 days. You may wish to consider boosting -the default TTL shown in former versions of this guide from one day -(86400 seconds) to three days (259200 seconds). This will drastically -reduce the number of requests made to your name servers. -.pp -If you need fast propagation of changes and deletions, it might be wise -to reduce the Minimum field a few days before the change, then do the -modification itself and augment the TTL to its former value. -.pp -If you know that your zone is pretty stable (you mainly add new records -without deleting or changing old ones) then you may even wish to consider -a TTL higher than three days. -.pp -Note that in any case, it makes no sense to have records with a TTL -below the SOA Refresh delay, as Delay is the time required for secondaries -to get a copy of the newly modified zone. - -.sh 2 "About ``secure zones'' -.pp -Secure zones implement named security on a zone by zone basis. It is -designed to use a permission list of networks or hosts which may obtain -particular information from the zone. -.pp -In order to use zone security, \fInamed\fP must be compiled with SECURE_ZONES -defined and you must have at least one secure_zone TXT RR. Unless a -\fIsecure_zone\fP record exists for a given zone, no restrictions will be -applied to the data in that zone. The format of the secure_zone TXT RR is: -.lp -secure_zone\h'0.5i'addr-class\h'0.5i'TXT\h'0.5i'string -.pp -The addr-class may be either \fIHS\fP or \fIIN\fP. The syntax for the TXT -string is either ``network address:netmask'' or ``host IP address:H''. -.pp -``network address:netmask'' allows queries from an entire network. If the -netmask is omitted, named will use the default netmask for the network -address specified. -.pp -``host IP address:H'' allows queries from a host. The ``H'' after the ``:'' -is required to differentiate the host address from a network address. -Multiple secure_zone TXT RRs are allowed in the same zone file. -.pp -For example, you can set up a zone to only answer Hesiod requests from the -masked class B network 130.215.0.0 and from host 128.23.10.56 by adding the -following two TXT RR's: -.lp -secure_zone\h'0.5i'HS\h'0.5i'TXT\h'0.5i'``130.215.0.0:255.255.0.0'' -secure_zone\h'0.5i'HS\h'0.5i'TXT\h'0.5i'``128.23.10.56:H'' -.pp -This feature can be used to restrict access to a Hesiod password map or to -separate internal and external internet address resolution on a firewall -machine without needing to run a separate named for internal and external -address resolution. -.pp -Note that you will need to include your loopback interface (127.0.0.1) in -your secure_zone record, or your local clients won't be able to resolve -names. - -.sh 2 "About Hesiod, and HS-class Resource Records -.pp -Hesiod, developed by \s-1MIT\s+1 Project Athena, is an information service -built upon \s-1BIND\s+1. Its intent is similar to that of Sun's -\s-1NIS\s+1: to furnish information about users, groups, network-accessible -file systems, printcaps, and mail service throughout an installation. Aside -from its use of \s-1BIND\s+1 rather than separate server code another -important difference between Hesiod and \s-1NIS\s+1 is that Hesiod is not -intended to deal with passwords and authentication, but only with data that -are not security sensitive. Hesiod servers can be implemented by adding -resource records to \s-1BIND\s+1 servers; or they can be implemented as -separate servers separately administered. -.pp -To learn about and obtain Hesiod make an anonymous \s-1FTP\s+1 connection to -host \s-1ATHENA-DIST.MIT.EDU\s+1 and retrieve the compressed tar file -\fB/pub/ATHENA/hesiod.tar.Z\fP. You will not need the named and resolver -library portions of the distribution because their functionality has already -been integrated into \s-1BIND as of 4.9\s+1. To learn how Hesiod functions -as part of the Athena computing environment obtain the paper -\fB/pub/ATHENA/usenix/athena-changes.PS\fP from the above \s-1FTP\s+1 server -host. There is also a tar file of sample Hesiod resource files. -.pp -Whether one should use Hesiod class is open to question, since the same -services can probably be provided with class IN, type TXT and type -CNAME records. In either case, the code and documents for Hesiod will -suggest how to set up and use the service. -.pp -Note that while \s-1BIND\s+1 includes support for \fIHS\fP-class queries, -the zone transfer logic for non-\fIIN\fP-class zones is still experimental. - -.sh 2 "Sample Files" -.pp -The following section contains sample files for the name server. -This covers example boot files for the different types of servers -and example domain data base files. |
