1149 lines
57 KiB
Plaintext
1149 lines
57 KiB
Plaintext
.\" $NetBSD: files.me,v 1.3 2003/08/07 09:20:54 agc Exp $
|
|
.\"
|
|
.\" ++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. 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 than 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.
|