Flatten bind9 vendor work area

1 files changed, 1229 insertions, 0 deletions

diff --git a/doc/rfc/rfc1033.txt b/doc/rfc/rfc1033.txt
new file mode 100644
index 0000000..37029fd
--- /dev/null
+++ b/doc/rfc/rfc1033.txt
@@ -0,0 +1,1229 @@
+Network Working Group                                         M. Lottor
+Request For Comments:  1033                           SRI International
+                                                          November 1987
+
+
+                 DOMAIN ADMINISTRATORS OPERATIONS GUIDE
+
+
+
+STATUS OF THIS MEMO
+
+   This RFC provides guidelines for domain administrators in operating a
+   domain server and maintaining their portion of the hierarchical
+   database.  Familiarity with the domain system is assumed.
+   Distribution of this memo is unlimited.
+
+ACKNOWLEDGMENTS
+
+   This memo is a formatted collection of notes and excerpts from the
+   references listed at the end of this document.  Of particular mention
+   are Paul Mockapetris and Kevin Dunlap.
+
+INTRODUCTION
+
+   A domain server requires a few files to get started.  It will
+   normally have some number of boot/startup files (also known as the
+   "safety belt" files).  One section will contain a list of possible
+   root servers that the server will use to find the up-to-date list of
+   root servers.  Another section will list the zone files to be loaded
+   into the server for your local domain information.  A zone file
+   typically contains all the data for a particular domain.  This guide
+   describes the data formats that can be used in zone files and
+   suggested parameters to use for certain fields.  If you are
+   attempting to do anything advanced or tricky, consult the appropriate
+   domain RFC's for more details.
+
+   Note:  Each implementation of domain software may require different
+   files.  Zone files are standardized but some servers may require
+   other startup files.  See the appropriate documentation that comes
+   with your software.  See the appendix for some specific examples.
+
+ZONES
+
+   A zone defines the contents of a contiguous section of the domain
+   space, usually bounded by administrative boundaries.  There will
+   typically be a separate data file for each zone.  The data contained
+   in a zone file is composed of entries called Resource Records (RRs).
+
+
+
+
+Lottor                                                          [Page 1]
+
+RFC 1033                DOMAIN OPERATIONS GUIDE            November 1987
+
+
+   You may only put data in your domain server that you are
+   authoritative for.  You must not add entries for domains other than
+   your own (except for the special case of "glue records").
+
+   A domain server will probably read a file on start-up that lists the
+   zones it should load into its database.  The format of this file is
+   not standardized and is different for most domain server
+   implementations.  For each zone it will normally contain the domain
+   name of the zone and the file name that contains the data to load for
+   the zone.
+
+ROOT SERVERS
+
+   A resolver will need to find the root servers when it first starts.
+   When the resolver boots, it will typically read a list of possible
+   root servers from a file.
+
+   The resolver will cycle through the list trying to contact each one.
+   When it finds a root server, it will ask it for the current list of
+   root servers.  It will then discard the list of root servers it read
+   from the data file and replace it with the current list it received.
+
+   Root servers will not change very often.  You can get the names of
+   current root servers from the NIC.
+
+   FTP the file NETINFO:ROOT-SERVERS.TXT or send a mail request to
+   NIC@SRI-NIC.ARPA.
+
+   As of this date (June 1987) they are:
+
+           SRI-NIC.ARPA       10.0.0.51    26.0.0.73
+           C.ISI.EDU          10.0.0.52
+           BRL-AOS.ARPA       192.5.25.82  192.5.22.82   128.20.1.2
+           A.ISI.EDU          26.3.0.103
+
+RESOURCE RECORDS
+
+   Records in the zone data files are called resource records (RRs).
+   They are specified in RFC-883 and RFC-973.  An RR has a standard
+   format as shown:
+
+           <name>   [<ttl>]   [<class>]   <type>   <data>
+
+   The record is divided into fields which are separated by white space.
+
+      <name>
+
+         The name field defines what domain name applies to the given
+
+
+
+Lottor                                                          [Page 2]
+
+RFC 1033                DOMAIN OPERATIONS GUIDE            November 1987
+
+
+         RR.  In some cases the name field can be left blank and it will
+         default to the name field of the previous RR.
+
+      <ttl>
+
+         TTL stands for Time To Live.  It specifies how long a domain
+         resolver should cache the RR before it throws it out and asks a
+         domain server again.  See the section on TTL's.  If you leave
+         the TTL field blank it will default to the minimum time
+         specified in the SOA record (described later).
+
+      <class>
+
+         The class field specifies the protocol group.  If left blank it
+         will default to the last class specified.
+
+      <type>
+
+         The type field specifies what type of data is in the RR.  See
+         the section on types.
+
+      <data>
+
+         The data field is defined differently for each type and class
+         of data.  Popular RR data formats are described later.
+
+   The domain system does not guarantee to preserve the order of
+   resource records.  Listing RRs (such as multiple address records) in
+   a certain order does not guarantee they will be used in that order.
+
+   Case is preserved in names and data fields when loaded into the name
+   server.  All comparisons and lookups in the name server are case
+   insensitive.
+
+   Parenthesis ("(",")") are used to group data that crosses a line
+   boundary.
+
+   A semicolon (";") starts a comment; the remainder of the line is
+   ignored.
+
+   The asterisk ("*") is used for wildcarding.
+
+   The at-sign ("@") denotes the current default domain name.
+
+
+
+
+
+
+
+
+Lottor                                                          [Page 3]
+
+RFC 1033                DOMAIN OPERATIONS GUIDE            November 1987
+
+
+NAMES
+
+   A domain name is a sequence of labels separated by dots.
+
+   Domain names in the zone files can be one of two types, either
+   absolute or relative.  An absolute name is the fully qualified domain
+   name and is terminated with a period.  A relative name does not
+   terminate with a period, and the current default domain is appended
+   to it.  The default domain is usually the name of the domain that was
+   specified in the boot file that loads each zone.
+
+   The domain system allows a label to contain any 8-bit character.
+   Although the domain system has no restrictions, other protocols such
+   as SMTP do have name restrictions.  Because of other protocol
+   restrictions, only the following characters are recommended for use
+   in a host name (besides the dot separator):
+
+           "A-Z", "a-z", "0-9", dash and underscore
+
+TTL's  (Time To Live)
+
+   It is important that TTLs are set to appropriate values.  The TTL is
+   the time (in seconds) that a resolver will use the data it got from
+   your server before it asks your server again.  If you set the value
+   too low, your server will get loaded down with lots of repeat
+   requests.  If you set it too high, then information you change will
+   not get distributed in a reasonable amount of time.  If you leave the
+   TTL field blank, it will default to what is specified in the SOA
+   record for the zone.
+
+   Most host information does not change much over long time periods.  A
+   good way to set up your TTLs would be to set them at a high value,
+   and then lower the value if you know a change will be coming soon.
+   You might set most TTLs to anywhere between a day (86400) and a week
+   (604800).  Then, if you know some data will be changing in the near
+   future, set the TTL for that RR down to a lower value (an hour to a
+   day) until the change takes place, and then put it back up to its
+   previous value.
+
+   Also, all RRs with the same name, class, and type should have the
+   same TTL value.
+
+CLASSES
+
+   The domain system was designed to be protocol independent.  The class
+   field is used to identify the protocol group that each RR is in.
+
+   The class of interest to people using TCP/IP software is the class
+
+
+
+Lottor                                                          [Page 4]
+
+RFC 1033                DOMAIN OPERATIONS GUIDE            November 1987
+
+
+   "Internet".  Its standard designation is "IN".
+
+   A zone file should only contain RRs of the same class.
+
+TYPES
+
+   There are many defined RR types.  For a complete list, see the domain
+   specification RFCs.  Here is a list of current commonly used types.
+   The data for each type is described in the data section.
+
+                Designation                Description
+              ==========================================
+               SOA                 Start Of Authority
+               NS                  Name Server
+
+               A                   Internet Address
+               CNAME               Canonical Name (nickname pointer)
+               HINFO               Host Information
+               WKS                 Well Known Services
+
+               MX                  Mail Exchanger
+
+               PTR                 Pointer
+
+SOA  (Start Of Authority)
+
+           <name>  [<ttl>]  [<class>]  SOA  <origin>  <person>  (
+                           <serial>
+                           <refresh>
+                           <retry>
+                           <expire>
+                           <minimum> )
+
+   The Start Of Authority record designates the start of a zone.  The
+   zone ends at the next SOA record.
+
+   <name> is the name of the zone.
+
+   <origin> is the name of the host on which the master zone file
+   resides.
+
+   <person> is a mailbox for the person responsible for the zone.  It is
+   formatted like a mailing address but the at-sign that normally
+   separates the user from the host name is replaced with a dot.
+
+   <serial> is the version number of the zone file.  It should be
+   incremented anytime a change is made to data in the zone.
+
+
+
+
+Lottor                                                          [Page 5]
+
+RFC 1033                DOMAIN OPERATIONS GUIDE            November 1987
+
+
+   <refresh> is how long, in seconds, a secondary name server is to
+   check with the primary name server to see if an update is needed.  A
+   good value here would be one hour (3600).
+
+   <retry> is how long, in seconds, a secondary name server is to retry
+   after a failure to check for a refresh.  A good value here would be
+   10 minutes (600).
+
+   <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.
+   You want this to be rather large, and a nice value is 3600000, about
+   42 days.
+
+   <minimum> is the minimum number of seconds to be used for TTL values
+   in RRs.  A minimum of at least a day is a good value here (86400).
+
+   There should only be one SOA record per zone.  A sample SOA record
+   would look something like:
+
+           @   IN   SOA   SRI-NIC.ARPA.   HOSTMASTER.SRI-NIC.ARPA. (
+                           45         ;serial
+                           3600       ;refresh
+                           600        ;retry
+                           3600000    ;expire
+                           86400 )    ;minimum
+
+
+NS  (Name Server)
+
+           <domain>   [<ttl>] [<class>]   NS   <server>
+
+   The NS record lists the name of a machine that provides domain
+   service for a particular domain.  The name associated with the RR is
+   the domain name and the data portion is the name of a host that
+   provides the service.  If machines SRI-NIC.ARPA and C.ISI.EDU provide
+   name lookup service for the domain COM then the following entries
+   would be used:
+
+           COM.    NS      SRI-NIC.ARPA.
+                   NS      C.ISI.EDU.
+
+   Note that the machines providing name service do not have to live in
+   the named domain.  There should be one NS record for each server for
+   a domain.  Also note that the name "COM" defaults for the second NS
+   record.
+
+   NS records for a domain exist in both the zone that delegates the
+   domain, and in the domain itself.
+
+
+
+Lottor                                                          [Page 6]
+
+RFC 1033                DOMAIN OPERATIONS GUIDE            November 1987
+
+
+GLUE RECORDS
+
+   If the name server host for a particular domain is itself inside the
+   domain, then a 'glue' record will be needed.  A glue record is an A
+   (address) RR that specifies the address of the server.  Glue records
+   are only needed in the server delegating the domain, not in the
+   domain itself.  If for example the name server for domain SRI.COM was
+   KL.SRI.COM, then the NS record would look like this, but you will
+   also need to have the following A record.
+
+           SRI.COM.	NS	KL.SRI.COM.
+           KL.SRI.COM.  A	10.1.0.2
+
+
+A  (Address)
+
+           <host>   [<ttl>] [<class>]   A   <address>
+
+   The data for an A record is an internet address in dotted decimal
+   form.  A sample A record might look like:
+
+           SRI-NIC.ARPA.           A       10.0.0.51
+
+   There should be one A record for each address of a host.
+
+CNAME ( Canonical Name)
+
+           <nickname>   [<ttl>] [<class>]   CNAME   <host>
+
+   The CNAME record is used for nicknames.  The name associated with the
+   RR is the nickname.  The data portion is the official name.  For
+   example, a machine named SRI-NIC.ARPA may want to have the nickname
+   NIC.ARPA.  In that case, the following RR would be used:
+
+           NIC.ARPA.       CNAME   SRI-NIC.ARPA.
+
+   There must not be any other RRs associated with a nickname of the
+   same class.
+
+   Nicknames are also useful when a host changes it's name.  In that
+   case, it is usually a good idea to have a CNAME pointer so that
+   people still using the old name will get to the right place.
+
+
+
+
+
+
+
+
+
+Lottor                                                          [Page 7]
+
+RFC 1033                DOMAIN OPERATIONS GUIDE            November 1987
+
+
+HINFO (Host Info)
+
+           <host>   [<ttl>] [<class>]   HINFO   <hardware>   <software>
+
+   The HINFO record gives information about a particular host.  The data
+   is two strings separated by whitespace.  The first string is a
+   hardware description and the second is software.  The hardware is
+   usually a manufacturer name followed by a dash and model designation.
+   The software string is usually the name of the operating system.
+
+   Official HINFO types can be found in the latest Assigned Numbers RFC,
+   the latest of which is RFC-1010.  The Hardware type is called the
+   Machine name and the Software type is called the System name.
+
+   Some sample HINFO records:
+
+           SRI-NIC.ARPA.           HINFO   DEC-2060 TOPS20
+           UCBARPA.Berkeley.EDU.   HINFO   VAX-11/780 UNIX
+
+
+WKS (Well Known Services)
+
+           <host> [<ttl>] [<class>] WKS <address> <protocol> <services>
+
+   The WKS record is used to list Well Known Services a host provides.
+   WKS's are defined to be services on port numbers below 256.  The WKS
+   record lists what services are available at a certain address using a
+   certain protocol.  The common protocols are TCP or UDP.  A sample WKS
+   record for a host offering the same services on all address would
+   look like:
+
+   Official protocol names can be found in the latest Assigned Numbers
+   RFC, the latest of which is RFC-1010.
+
+           SRI-NIC.ARPA.   WKS  10.0.0.51  TCP  TELNET FTP SMTP
+                           WKS  10.0.0.51  UDP  TIME
+                           WKS  26.0.0.73  TCP  TELNET FTP SMTP
+                           WKS  26.0.0.73  UDP  TIME
+
+MX (Mail Exchanger)  (See RFC-974 for more details.)
+
+           <name>   [<ttl>] [<class>]   MX   <preference>   <host>
+
+   MX records specify where mail for a domain name should be delivered.
+   There may be multiple MX records for a particular name.  The
+   preference value specifies the order a mailer should try multiple MX
+   records when delivering mail.  Zero is the highest preference.
+   Multiple records for the same name may have the same preference.
+
+
+
+Lottor                                                          [Page 8]
+
+RFC 1033                DOMAIN OPERATIONS GUIDE            November 1987
+
+
+   A host BAR.FOO.COM may want its mail to be delivered to the host
+   PO.FOO.COM and would then use the MX record:
+
+           BAR.FOO.COM.    MX      10      PO.FOO.COM.
+
+   A host BAZ.FOO.COM may want its mail to be delivered to one of three
+   different machines, in the following order:
+
+           BAZ.FOO.COM.    MX      10      PO1.FOO.COM.
+                           MX      20      PO2.FOO.COM.
+                           MX      30      PO3.FOO.COM.
+
+   An entire domain of hosts not connected to the Internet may want
+   their mail to go through a mail gateway that knows how to deliver
+   mail to them.  If they would like mail addressed to any host in the
+   domain FOO.COM to go through the mail gateway they might use:
+
+           FOO.COM.        MX       10     RELAY.CS.NET.
+           *.FOO.COM.      MX       20     RELAY.CS.NET.
+
+   Note that you can specify a wildcard in the MX record to match on
+   anything in FOO.COM, but that it won't match a plain FOO.COM.
+
+IN-ADDR.ARPA
+
+   The structure of names in the domain system is set up in a
+   hierarchical way such that the address of a name can be found by
+   tracing down the domain tree contacting a server for each label of
+   the name.  Because of this 'indexing' based on name, there is no easy
+   way to translate a host address back into its host name.
+
+   In order to do the reverse translation easily, a domain was created
+   that uses hosts' addresses as part of a name that then points to the
+   data for that host.  In this way, there is now an 'index' to hosts'
+   RRs based on their address.  This address mapping domain is called
+   IN-ADDR.ARPA.  Within that domain are subdomains for each network,
+   based on network number.  Also, for consistency and natural
+   groupings, the 4 octets of a host number are reversed.
+
+   For example, the ARPANET is net 10.  That means there is a domain
+   called 10.IN-ADDR.ARPA.  Within this domain there is a PTR RR at
+   51.0.0.10.IN-ADDR that points to the RRs for the host SRI-NIC.ARPA
+   (who's address is 10.0.0.51).  Since the NIC is also on the MILNET
+   (Net 26, address 26.0.0.73), there is also a PTR RR at 73.0.0.26.IN-
+   ADDR.ARPA that points to the same RR's for SRI-NIC.ARPA.  The format
+   of these special pointers is defined below along with the examples
+   for the NIC.
+
+
+
+
+Lottor                                                          [Page 9]
+
+RFC 1033                DOMAIN OPERATIONS GUIDE            November 1987
+
+
+PTR
+
+           <special-name>   [<ttl>] [<class>]   PTR   <name>
+
+   The PTR record is used to let special names point to some other
+   location in the domain tree.  They are mainly used in the IN-
+   ADDR.ARPA records for translation of addresses to names.  PTR's
+   should use official names and not aliases.
+
+   For example, host SRI-NIC.ARPA with addresses 10.0.0.51 and 26.0.0.73
+   would have the following records in the respective zone files for net
+   10 and net 26:
+
+           51.0.0.10.IN-ADDR.ARPA.  PTR   SRI-NIC.ARPA.
+           73.0.0.26.IN-ADDR.ARPA.  PTR   SRI-NIC.ARPA.
+
+GATEWAY PTR's
+
+   The IN-ADDR tree is also used to locate gateways on a particular
+   network.  Gateways have the same kind of PTR RRs as hosts (as above)
+   but in addition they have other PTRs used to locate them by network
+   number alone.  These records have only 1, 2, or 3 octets as part of
+   the name depending on whether they are class A, B, or C networks,
+   respectively.
+
+   Lets take the SRI-CSL gateway for example.  It connects 3 different
+   networks, one class A, one class B and one class C.  It will have the
+   standard RR's for a host in the CSL.SRI.COM zone:
+
+           GW.CSL.SRI.COM.    A    10.2.0.2
+                              A    128.18.1.1
+                              A    192.12.33.2
+
+   Also, in 3 different zones (one for each network), it will have one
+   of the following number to name translation pointers:
+
+           2.0.2.10.IN-ADDR.ARPA.      PTR   GW.CSL.SRI.COM.
+           1.1.18.128.IN-ADDR.ARPA.    PTR   GW.CSL.SRI.COM.
+           1.33.12.192.IN-ADDR.ARPA.   PTR   GW.CSL.SRI.COM.
+
+   In addition, in each of the same 3 zones will be one of the following
+   gateway location pointers:
+
+           10.IN-ADDR.ARPA.            PTR   GW.CSL.SRI.COM.
+           18.128.IN-ADDR.ARPA.        PTR   GW.CSL.SRI.COM.
+           33.12.192.IN-ADDR.ARPA.     PTR   GW.CSL.SRI.COM.
+
+
+
+
+
+Lottor                                                         [Page 10]
+
+RFC 1033                DOMAIN OPERATIONS GUIDE            November 1987
+
+
+INSTRUCTIONS
+
+   Adding a subdomain.
+
+      To add a new subdomain to your domain:
+
+         Setup the other domain server and/or the new zone file.
+
+         Add an NS record for each server of the new domain to the zone
+         file of the parent domain.
+
+         Add any necessary glue RRs.
+
+   Adding a host.
+
+      To add a new host to your zone files:
+
+         Edit the appropriate zone file for the domain the host is in.
+
+         Add an entry for each address of the host.
+
+         Optionally add CNAME, HINFO, WKS, and MX records.
+
+         Add the reverse IN-ADDR entry for each host address in the
+         appropriate zone files for each network the host in on.
+
+   Deleting a host.
+
+      To delete a host from the zone files:
+
+         Remove all the hosts' resource records from the zone file of
+         the domain the host is in.
+
+         Remove all the hosts' PTR records from the IN-ADDR zone files
+         for each network the host was on.
+
+   Adding gateways.
+
+         Follow instructions for adding a host.
+
+         Add the gateway location PTR records for each network the
+         gateway is on.
+
+   Deleting gateways.
+
+         Follow instructions for deleting a host.
+
+         Also delete the gateway location PTR records for each network
+
+
+
+Lottor                                                         [Page 11]
+
+RFC 1033                DOMAIN OPERATIONS GUIDE            November 1987
+
+
+         the gateway was on.
+
+COMPLAINTS
+
+   These are the suggested steps you should take if you are having
+   problems that you believe are caused by someone else's name server:
+
+
+   1.  Complain privately to the responsible person for the domain.  You
+   can find their mailing address in the SOA record for the domain.
+
+   2.  Complain publicly to the responsible person for the domain.
+
+   3.  Ask the NIC for the administrative person responsible for the
+   domain.  Complain.  You can also find domain contacts on the NIC in
+   the file NETINFO:DOMAIN-CONTACTS.TXT
+
+   4.  Complain to the parent domain authorities.
+
+   5.  Ask the parent authorities to excommunicate the domain.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Lottor                                                         [Page 12]
+
+RFC 1033                DOMAIN OPERATIONS GUIDE            November 1987
+
+
+EXAMPLE DOMAIN SERVER DATABASE FILES
+
+   The following examples show how zone files are set up for a typical
+   organization.  SRI will be used as the example organization.  SRI has
+   decided to divided their domain SRI.COM into a few subdomains, one
+   for each group that wants one.  The subdomains are CSL and ISTC.
+
+   Note the following interesting items:
+
+      There are both hosts and domains under SRI.COM.
+
+      CSL.SRI.COM is both a domain name and a host name.
+
+      All the domains are serviced by the same pair of domain servers.
+
+      All hosts at SRI are on net 128.18 except hosts in the CSL domain
+      which are on net 192.12.33.  Note that a domain does not have to
+      correspond to a physical network.
+
+      The examples do not necessarily correspond to actual data in use
+      by the SRI domain.
+
+                       SRI Domain Organization
+
+                               +-------+
+                               |  COM  |
+                               +-------+
+                                   |
+                               +-------+
+                               |  SRI  |
+                               +-------+
+                                   |
+                        +----------++-----------+
+                        |           |           |
+                    +-------+    +------+   +-------+
+                    |  CSL  |    | ISTC |   | Hosts |
+                    +-------+    +------+   +-------+
+                        |           |
+                    +-------+    +-------+
+                    | Hosts |    | Hosts |
+                    +-------+    +-------+
+
+
+
+
+
+
+
+
+
+
+Lottor                                                         [Page 13]
+
+RFC 1033                DOMAIN OPERATIONS GUIDE            November 1987
+
+
+   [File "CONFIG.CMD".  Since bootstrap files are not standardized, this
+   file is presented using a pseudo configuration file syntax.]
+
+   load root server list             from file ROOT.SERVERS
+   load zone SRI.COM.                from file SRI.ZONE
+   load zone CSL.SRI.COM.            from file CSL.ZONE
+   load zone ISTC.SRI.COM.           from file ISTC.ZONE
+   load zone 18.128.IN-ADDR.ARPA.    from file SRINET.ZONE
+   load zone 33.12.192.IN-ADDR.ARPA. from file SRI-CSL-NET.ZONE
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Lottor                                                         [Page 14]
+
+RFC 1033                DOMAIN OPERATIONS GUIDE            November 1987
+
+
+   [File "ROOT.SERVERS".  Again, the format of this file is not
+   standardized.]
+
+   ;list of possible root servers
+   SRI-NIC.ARPA       10.0.0.51    26.0.0.73
+   C.ISI.EDU          10.0.0.52
+   BRL-AOS.ARPA       192.5.25.82  192.5.22.82   128.20.1.2
+   A.ISI.EDU          26.3.0.103
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Lottor                                                         [Page 15]
+
+RFC 1033                DOMAIN OPERATIONS GUIDE            November 1987
+
+
+   [File "SRI.ZONE"]
+
+   SRI.COM.        IN      SOA     KL.SRI.COM. DLE.STRIPE.SRI.COM. (
+                                   870407  ;serial
+                                   1800    ;refresh every 30 minutes
+                                   600     ;retry every 10 minutes
+                                   604800  ;expire after a week
+                                   86400   ;default of an hour
+                                   )
+
+   SRI.COM.        NS      KL.SRI.COM.
+                   NS      STRIPE.SRI.COM.
+                   MX      10      KL.SRI.COM.
+
+   ;SRI.COM hosts
+
+   KL              A       10.1.0.2
+                   A       128.18.10.6
+                   MX      10      KL.SRI.COM.
+
+   STRIPE          A       10.4.0.2
+   STRIPE          A       128.18.10.4
+                   MX      10      STRIPE.SRI.COM.
+
+   NIC             CNAME   SRI-NIC.ARPA.
+
+   Blackjack       A       128.18.2.1
+                   HINFO   VAX-11/780      UNIX
+                   WKS     128.18.2.1      TCP TELNET FTP
+
+   CSL             A       192.12.33.2
+                   HINFO   FOONLY-F4       TOPS20
+                   WKS     192.12.33.2     TCP TELNET FTP SMTP FINGER
+                   MX      10      CSL.SRI.COM.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Lottor                                                         [Page 16]
+
+RFC 1033                DOMAIN OPERATIONS GUIDE            November 1987
+
+
+   [File "CSL.ZONE"]
+
+   CSL.SRI.COM.    IN      SOA     KL.SRI.COM. DLE.STRIPE.SRI.COM. (
+                                   870330  ;serial
+                                   1800    ;refresh every 30 minutes
+                                   600     ;retry every 10 minutes
+                                   604800  ;expire after a week
+                                   86400   ;default of a day
+                                   )
+
+   CSL.SRI.COM.    NS              KL.SRI.COM.
+                   NS              STRIPE.SRI.COM.
+                   A               192.12.33.2
+
+   ;CSL.SRI.COM hosts
+
+   A               CNAME   CSL.SRI.COM.
+   B               A       192.12.33.3
+                   HINFO   FOONLY-F4       TOPS20
+                   WKS     192.12.33.3     TCP TELNET FTP SMTP
+   GW              A       10.2.0.2
+                   A       192.12.33.1
+                   A       128.18.1.1
+                   HINFO   PDP-11/23       MOS
+   SMELLY          A       192.12.33.4
+                   HINFO   IMAGEN          IMAGEN
+   SQUIRREL        A       192.12.33.5
+                   HINFO   XEROX-1100      INTERLISP
+   VENUS           A       192.12.33.7
+                   HINFO   SYMBOLICS-3600  LISPM
+   HELIUM          A       192.12.33.30
+                   HINFO   SUN-3/160       UNIX
+   ARGON           A       192.12.33.31
+                   HINFO   SUN-3/75        UNIX
+   RADON           A       192.12.33.32
+                   HINFO   SUN-3/75        UNIX
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Lottor                                                         [Page 17]
+
+RFC 1033                DOMAIN OPERATIONS GUIDE            November 1987
+
+
+   [File "ISTC.ZONE"]
+
+   ISTC.SRI.COM.   IN  SOA     KL.SRI.COM. roemers.JOYCE.ISTC.SRI.COM. (
+                               870406      ;serial
+                               1800        ;refresh every 30 minutes
+                               600         ;retry every 10 minutes
+                               604800      ;expire after a week
+                               86400       ;default of a day
+                               )
+
+   ISTC.SRI.COM.   NS              KL.SRI.COM.
+                   NS              STRIPE.SRI.COM.
+                   MX              10      SPAM.ISTC.SRI.COM.
+
+   ; ISTC hosts
+
+   joyce           A       128.18.4.2
+                   HINFO   VAX-11/750 UNIX
+   bozo            A       128.18.0.6
+                   HINFO   SUN UNIX
+   sundae          A       128.18.0.11
+                   HINFO   SUN UNIX
+   tsca            A       128.18.0.201
+                   A       10.3.0.2
+                   HINFO   VAX-11/750 UNIX
+                   MX      10  TSCA.ISTC.SRI.COM.
+   tsc             CNAME   tsca
+   prmh            A       128.18.0.203
+                   A       10.2.0.51
+                   HINFO   PDP-11/44 UNIX
+   spam            A       128.18.4.3
+                   A       10.2.0.107
+                   HINFO   VAX-11/780 UNIX
+                   MX      10  SPAM.ISTC.SRI.COM.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Lottor                                                         [Page 18]
+
+RFC 1033                DOMAIN OPERATIONS GUIDE            November 1987
+
+
+   [File "SRINET.ZONE"]
+
+   18.128.IN-ADDR.ARPA.    IN  SOA  KL.SRI.COM  DLE.STRIPE.SRI.COM. (
+                               870406  ;serial
+                               1800    ;refresh every 30 minutes
+                               600     ;retry every 10 minutes
+                               604800  ;expire after a week
+                               86400   ;default of a day
+                               )
+
+   18.128.IN-ADDR.ARPA.    NS      KL.SRI.COM.
+                           NS      STRIPE.SRI.COM.
+                           PTR     GW.CSL.SRI.COM.
+
+   ; SRINET [128.18.0.0] Address Translations
+
+   ; SRI.COM Hosts
+   1.2.18.128.IN-ADDR.ARPA.        PTR     Blackjack.SRI.COM.
+
+   ; ISTC.SRI.COM Hosts
+   2.4.18.128.IN-ADDR.ARPA.        PTR     joyce.ISTC.SRI.COM.
+   6.0.18.128.IN-ADDR.ARPA.        PTR     bozo.ISTC.SRI.COM.
+   11.0.18.128.IN-ADDR.ARPA.       PTR     sundae.ISTC.SRI.COM.
+   201.0.18.128.IN-ADDR.ARPA.      PTR     tsca.ISTC.SRI.COM.
+   203.0.18.128.IN-ADDR.ARPA.      PTR     prmh.ISTC.SRI.COM.
+   3.4.18.128.IN-ADDR.ARPA.        PTR     spam.ISTC.SRI.COM.
+
+   ; CSL.SRI.COM Hosts
+   1.1.18.128.IN-ADDR.ARPA.        PTR     GW.CSL.SRI.COM.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Lottor                                                         [Page 19]
+
+RFC 1033                DOMAIN OPERATIONS GUIDE            November 1987
+
+
+   [File "SRI-CSL-NET.ZONE"]
+
+   33.12.192.IN-ADDR.ARPA. IN  SOA KL.SRI.COM  DLE.STRIPE.SRI.COM. (
+                               870404  ;serial
+                               1800    ;refresh every 30 minutes
+                               600     ;retry every 10 minutes
+                               604800  ;expire after a week
+                               86400   ;default of a day
+                               )
+
+   33.12.192.IN-ADDR.ARPA. NS      KL.SRI.COM.
+                           NS      STRIPE.SRI.COM.
+                           PTR     GW.CSL.SRI.COM.
+
+   ; SRI-CSL-NET [192.12.33.0] Address Translations
+
+   ; SRI.COM Hosts
+   2.33.12.192.IN-ADDR.ARPA.       PTR     CSL.SRI.COM.
+
+   ; CSL.SRI.COM Hosts
+   1.33.12.192.IN-ADDR.ARPA.       PTR     GW.CSL.SRI.COM.
+   3.33.12.192.IN-ADDR.ARPA.       PTR     B.CSL.SRI.COM.
+   4.33.12.192.IN-ADDR.ARPA.       PTR     SMELLY.CSL.SRI.COM.
+   5.33.12.192.IN-ADDR.ARPA.       PTR     SQUIRREL.CSL.SRI.COM.
+   7.33.12.192.IN-ADDR.ARPA.       PTR     VENUS.CSL.SRI.COM.
+   30.33.12.192.IN-ADDR.ARPA.      PTR     HELIUM.CSL.SRI.COM.
+   31.33.12.192.IN-ADDR.ARPA.      PTR     ARGON.CSL.SRI.COM.
+   32.33.12.192.IN-ADDR.ARPA.      PTR     RADON.CSL.SRI.COM.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Lottor                                                         [Page 20]
+
+RFC 1033                DOMAIN OPERATIONS GUIDE            November 1987
+
+
+APPENDIX
+
+   BIND (Berkeley Internet Name Domain server) distributed with 4.3 BSD
+   UNIX
+
+   This section describes two BIND implementation specific files; the
+   boot file and the cache file.  BIND has other options, files, and
+   specifications that are not described here.  See the Name Server
+   Operations Guide for BIND for details.
+
+   The boot file for BIND is usually called "named.boot".  This
+   corresponds to file "CONFIG.CMD" in the example section.
+
+           --------------------------------------------------------
+           cache         .                         named.ca
+           primary       SRI.COM                   SRI.ZONE
+           primary       CSL.SRI.COM               CSL.ZONE
+           primary       ISTC.SRI.COM              ISTC.ZONE
+           primary       18.128.IN-ADDR.ARPA       SRINET.ZONE
+           primary       33.12.192.IN-ADDR.ARPA    SRI-CSL-NET.ZONE
+           --------------------------------------------------------
+
+   The cache file for BIND is usually called "named.ca".  This
+   corresponds to file "ROOT.SERVERS" in the example section.
+
+           -------------------------------------------------
+           ;list of possible root servers
+           .       1          IN   NS   SRI-NIC.ARPA.
+                                   NS   C.ISI.EDU.
+                                   NS   BRL-AOS.ARPA.
+                                   NS   C.ISI.EDU.
+           ;and their addresses
+           SRI-NIC.ARPA.           A    10.0.0.51
+                                   A    26.0.0.73
+           C.ISI.EDU.              A    10.0.0.52
+           BRL-AOS.ARPA.           A    192.5.25.82
+                                   A    192.5.22.82
+                                   A    128.20.1.2
+           A.ISI.EDU.              A    26.3.0.103
+           -------------------------------------------------
+
+
+
+
+
+
+
+
+
+
+
+Lottor                                                         [Page 21]
+
+RFC 1033                DOMAIN OPERATIONS GUIDE            November 1987
+
+
+REFERENCES
+
+   [1]  Dunlap, K., "Name Server Operations Guide for BIND", CSRG,
+        Department of Electrical Engineering and Computer Sciences,
+        University of California, Berkeley, California.
+
+   [2]  Partridge, C., "Mail Routing and the Domain System", RFC-974,
+        CSNET CIC BBN Laboratories, January 1986.
+
+   [3]  Mockapetris, P., "Domains Names - Concepts and Facilities",
+        RFC-1034, USC/Information Sciences Institute, November 1987.
+
+   [4]  Mockapetris, P., "Domain Names - Implementations Specification",
+        RFC-1035, USC/Information Sciences Institute, November 1987.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Lottor                                                         [Page 22]
+