Domain Administrators Operations Guide
RFC 1033

• Status
• IESG evaluation record
• IESG writeups
• Email expansions
• History

• Versions

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