files.me

早期freebsd实现

The \fIStart of Authority, SOA,\fP record designates the start of a zone.
The name is the name of the zone.  
Origin is the name of the host on which this data file resides.
Person in charge is the mailing address for the person responsible
for the name server.
The serial number is the version number of this data file;
this number should 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 neccessity.
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 an RR.
There should only be 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.
The first name field lists the domain that is serviced by 
the listed name server.
There should be one \fINS\fP record for each name server for the domain,
and every domain should have at least two nameservers.
.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.  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 RFC 1123 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 the existence of a TXT or WKS RR in most
                 domains.
.)l
.sh 3 "CNAME - Canonical Name"
.TS
l l l l l. 
\fIaliases	{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 should be the only one associated with the alias name.
All other resource records should 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.
.pp
Nicknames are also useful when a 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.
.sh 3 "MX - Mail Exchanger"
.TS
l l l l l l. 
\fIname	{ttl}	addr-class	MX	preference value	mail exchanger\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 eXchanger\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 then 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 RFC 974 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 Exchangers 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; several systems use \fITXT\fP records
to encode the local user database (\fI/etc/passwd\fP) and other administrative
data.  MIT Hesiod is one such system, which, though it uses an addr-class of
\fIHS\fP rather than \fIIN\fP, implements its database with \fITXT\fP records
in the \s-1DNS\s+1.
.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 master files 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 mbox domain name shows the encoding for
``\fB<[e-mail]>\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\fP domain name.  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 TXT domain name 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	mail exchanger\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 tracker\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\P record for
other information specifying other details to be used in accessing the
DCE cell.  RFC 1183 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 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 changing regularly 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 "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.