GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc1033

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.
  1. ——————————————————-

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.
  1. ————————————————

;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]

/data/webs/external/dokuwiki/data/pages/rfc/rfc1033.txt · Last modified: 1987/11/11 23:27 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki