files.me

早期freebsd实现

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 and \fIxfrnets\fP; you give it a list of networks and it
uses these to ``prefer'' some remote name server addresses over others.  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 in \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.
.pp
In actual practice, noone uses this directive 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 which have more than one) and perhaps on routing table information.  We
do not intend to solve the generalized ``multi-homed 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 \(em
you just give it a list of dotted-quad Internet addresses.
.pp
Note that \fIbogusns\fP support is a compile-time option which your vendor
may not have enabled when they built your operating system.
.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 resolver will try to contact a nameserver on the localhost if it cannot
find its configuration file.  You should install the configuration file
on every host anyway, since you can list the local host's address if the
localhost runs a nameserver, and there is no other recommended way to
specify a system-level default domain.  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 localhost 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.
.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.
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.  If
you run a name server locally, list it in your \fIresolv.conf\fP file.
.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.  This is, in other
words, 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.
.pp
The \fIsort-list\fP is a list of IP address, netmask pairs. Addresses
returned by gethostbyname are sorted to the order specifed by this list.
Any addresses that do not match the address netmask pair will 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"
.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 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\fImy.dom.ain\fP''.  The name of this \fIPTR\fP
record is always ``\fB1.0.0.127.\s-1IN-ADDR.ARPA\s+1\fP''.  This
is neccessary 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 an \fIA\fP record
in your domain specifying that ``\fBlocalhost.\fP\fImy.dom.ain\fP'' has
the Internet address 127.0.0.1.

.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 octets is 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 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 current domain.
.ip ``@''
A free standing @ in the name field denotes the current origin.
.ip "``\fB.\|.\fP''"
Two free standing dots represent the null domain name of the root when used in 
the name field.
.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.
.ip "``;''"
Semicolon starts a comment; the remainder of the line is 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-exchangers
.)b
The line would be interpreted as a request to load the file
\fI/usr/named/data/mail-exchangers\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.
.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 that a given zone 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 (
			1993041403	; Serial
			10800	; Refresh
			1800	; Retry
			3600000	; Expire
			259200 )	; Minimum
.TE
.)b