Tech-invite3GPPspaceIETFspace
959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 0883

Domain names: Implementation specification

Pages: 74
Obsoleted by:  10341035
Updated by:  0973
Part 3 of 3 – Pages 50 to 74
First   Prev   None

ToP   noToC   RFC0883 - Page 50   prevText
      field in the new SOA record with the SERIAL field in the SOA
      record of the existing zone copy.  If these values match, the zone
      has not been updated since the last copy and hence there is no
      reason to recopy the zone.  In this case the name server resets
      the times in the existing SOA record and closes the virtual
      circuit to complete the operation.

      If this is initial load, or the SERIAL fields were different, the
      name server requests a copy of the zone by sending the foreign
      name server an AXFR query which specifies the zone by its QCLASS
      and QNAME fields.

      When the foreign name server receives the AXFR request, it sends
      each node from the zone to the requestor in a separate message.
      It begins with the node that contains the SOA record, walks the
      tree in breadth-first order, and completes the transfer by
      resending the node containing the SOA record.

      Several error conditions are possible:

         If the AXFR request cannot be matched to a SOA, the foreign
         name server will return a single message in response that does
         not contain the AXFR request.  (The normal SOA query preceding
         the AXFR is designed to avoid this condition, but it is still
         possible.)

         The foreign name server can detect an internal error or detect
         some other condition (e.g. system going down, out of resources,
         etc.) that forces the transfer to be aborted.  If so, it sends
         a message with the "Server failure" condition set.  If the AXFR
         can be immediately retried with some chance of success, it
         leaves the virtual open; otherwise it initiates a close.

         If the foreign name server doesn't wish to perform the
         operation for policy reasons (i.e. the system administrator
         wishes to forbid zone copies), the foreign server returns a
         "Refused" condition.

      The requestor receives these records and builds a new tree.  This
      tree is not yet in the status table, so its data are not used to
      process queries.  The old copy of the zone, if any, may be used to
      satisfy request while the transfer is in progress.

      When the requestor receives the second copy of the SOA node, it
      compares the SERIAL field in the first copy of the SOA against the
      SERIAL field in the last copy of the SOA record.  If these don't
      match, the foreign server updated its zone while the transfer was
      in progress.  In this case the requestor repeats the AXFR request
      to acquire the newer version.
ToP   noToC   RFC0883 - Page 51
      If the AXFR transfer eventually succeeds, the name server closes
      the virtual circuit and and creates new versions of inversion data
      structures for this zone.  When this operation is complete, the
      name server acquires the main lock in write mode and then replaces
      any old copy of the zone and inversion data structures with new
      ones.  The name server then releases the main lock, and can
      reclaim the storage used by the old copy.

      If an error occurs during the AXFR transfer, the name server can
      copy any partial information into its cache tree if it wishes,
      although it will not normally do so if the zone transfer was a
      refresh rather than an initial load.
ToP   noToC   RFC0883 - Page 52
RESOLVER ALGORITHMS

   Operations

      Resolvers have a great deal of latitude in the semantics they
      allow in user calls.  For example, a resolver might support
      different user calls that specify whether the returned information
      must be from and authoritative name server or not.  Resolvers are
      also responsible for enforcement of any local restrictions on
      access, etc.

      In any case, the resolver will transform the user query into a
      number of shared database accesses and queries to remote name
      servers.  When a user requests a resource associated with a
      particular domain name, the resolver will execute the following
      steps:

      1. The resolver first checks the local shared database, if any,
         for the desired information.  If found, it checks the
         applicable timeout.  If the timeout check succeeds, the
         information is used to satisfy the user request.  If not, the
         resolver goes to step 2.

      2. In this step, the resolver consults the shared database for the
         name server that most closely matches the domain name in the
         user query.  Multiple redundant name servers may be found.  The
         resolver goes to step 3.

      3. In this step the resolver chooses one of the available name
         servers and sends off a query.  If the query fails, it tries
         another name server.  If all fail, an error indication is
         returned to the user.  If a reply is received the resolver adds
         the returned RRs to its database and goes to step 4.

      4. In this step, the resolver interprets the reply.  If the reply
         contains the desired information, the resolver returns the
         information to the user.  The the reply indicates that the
         domain name in the user query doesn't exist, then the resolver
         returns an error to the user.  If the reply contains a
         transient name server failure, the resolver can either wait and
         retry the query or go back to step 3 and try a different name
         server.  If the reply doesn't contain the desired information,
         but does contain a pointer to a closer name server, the
         resolver returns to step 2, where the closer name servers will
         be queried.

      Several modifications to this algorithm are possible.  A resolver
      may not support a local cache and instead only cache information
      during the course of a single user request, discarding it upon
ToP   noToC   RFC0883 - Page 53
      completion.  The resolver may also find that a datagram reply was
      truncated, and open a virtual circuit so that the complete reply
      can be recovered.

      Inverse and completion queries must be treated in an
      environment-sensitive manner, because the domain system doesn't
      provide a method for guaranteeing that it can locate the correct
      information.  The typical choice will be to configure a resolver
      to use a particular set of known name servers for inverse queries.
ToP   noToC   RFC0883 - Page 54
DOMAIN SUPPORT FOR MAIL

   Introduction

      Mail service is a particularly sensitive issue for users of the
      domain system because of the lack of a consistent system for
      naming mailboxes and even hosts, and the need to support continued
      operation of existing services.  This section discusses an
      evolutionary approach for adding consistent domain name support
      for mail.

      The crucial issue is deciding on the types of binding to be
      supported.  Most mail systems specify a mail destination with a
      two part construct such as X@Y.  The left hand side, X, is an
      string, often a user or account, and Y is a string, often a host.
      This section refers to the part on the left, i.e. X, as the local
      part, and refers to the part on the right, i.e. Y, as the global
      part.

      Most existing mail systems route mail based on the global part; a
      mailer with mail to deliver to X@Y will decide on the host to be
      contacted using only Y.  We refer to this type of binding as
      "agent binding".

         For example, mail addressed to Mockapetris@ISIF is delivered to
         host USC-ISIF (USC-ISIF is the official name for the host
         specified by nickname ISIF).

      More sophisticated mail systems use both the local and global
      parts, i.e. both X and Y to determine which host should receive
      the mail.  These more sophisticated systems usually separate the
      binding of the destination to the host from the actual delivery.
      This allows the global part to be a generic name rather than
      constraining it to a single host.  We refer to this type of
      binding as "mailbox binding".

         For example, mail addressed to Mockapetris@ISI might be bound
         to host F.ISI.ARPA, and subsequently delivered to that host,
         while mail for Cohen@ISI might be bound to host B.ISI.ARPA.

      The domain support for mail consists of two levels of support,
      corresponding to these two binding models.

         The first level, agent binding, is compatible with existing
         ARPA Internet mail procedures and uses maps a global part onto
         one or more hosts that will accept the mail.  This type of
         binding uses the MAILA QTYPE.

         The second level, mailbox binding, offers extended services
ToP   noToC   RFC0883 - Page 55
         that map a local part and a global part onto one or more sets
         of data via the MAILB QTYPE.  The sets of data include hosts
         that will accept the mail, mailing list members  (mail groups),
         and mailboxes for reporting errors or requests to change a mail
         group.

      The domain system encodes the global part of a mail destination as
      a domain name and uses dots in the global part to separate labels
      in the encoded domain name.  The domain system encodes the local
      part of a mail destination as a single label, and any dots in this
      part are simply copied into the label.  The domain system forms a
      complete mail destination as the local label concatenated to the
      domain string for the global part.  We call this a mailbox.

         For example, the mailbox Mockapetris@F.ISI.ARPA has a global
         domain name of three labels, F.ISI.ARPA.  The domain name
         encoding for the whole mailbox is Mockapetris.F.ISI.ARPA.  The
         mailbox Mockapetris.cad@F.ISI.ARPA has the same domain name for
         the global part and a 4 label domain name for the mailbox of
         Mockapetris\.cad.F.ISI.ARPA (the \ is not stored in the label,
         its merely used to denote the "quoted" dot).

      It is anticipated that the Internet system will adopt agent
      binding as part of the initial implementation of the domain
      system, and that mailbox binding will eventually become the
      preferred style as organizations convert their mail systems to the
      new style.  To facilitate this approach, the domain information
      for these two binding styles is organized to allow a requestor to
      determine which types of support are available, and the
      information is kept in two disjoint classes.

   Agent binding

      In agent binding, a mail system uses the global part of the mail
      destination as a domain name, with dots denoting structure.  The
      domain name is resolved using a MAILA query which return MF and MD
      RRs to specify the domain name of the appropriate host to receive
      the mail.  MD (Mail delivery) RRs specify hosts that are expected
      to have the mailbox in question; MF (Mail forwarding) RRs specify
      hosts that are expected to be intermediaries willing to accept the
      mail for eventual forwarding.  The hosts are hints, rather than
      definite answers, since the query is made without the full mail
      destination specification.

      For example, mail for MOCKAPETRIS@F.ISI.ARPA would result in a
      query with QTYPE=MAILA and QNAME=F.ISI.ARPA, which might return
      two RRs:
ToP   noToC   RFC0883 - Page 56
                      F.ISI.ARPA MD IN F.ISI.ARPA
                      F.ISI.ARPA MF IN A.ISI.ARPA

      The mailer would interpret these to mean that the mail agent on
      F.ISI.ARPA should be able to deliver the mail directly, but that
      A.ISI.ARPA is willing to accept the mail for probable forwarding.

      Using this system, an organization could implement a system that
      uses organization names for global parts, rather than the usual
      host names, but all mail for the organization would be routed the
      same, regardless of its local part.  Hence and organization with
      many hosts would expect to see many forwarding operations.

   Mailbox binding

      In mailbox binding, the mailer uses the entire mail destination
      specification to construct a domain name.  The encoded domain name
      for the mailbox is used as the QNAME field in a QTYPE=MAILB query.

      Several outcomes are possible for this query:

      1. The query can return a name error indicating that the mailbox
         does not exist as a domain name.

         In the long term this would indicate that the specified mailbox
         doesn't exist.  However, until the use of mailbox binding is
         universal, this error condition should be interpreted to mean
         that the organization identified by the global part does not
         support mailbox binding.  The appropriate procedure is to
         revert to agent binding at this point.

      2. The query can return a Mail Rename (MR) RR.

         The MR RR carries new mailbox specification in its RDATA field.
         The mailer should replace the old mailbox with the new one and
         retry the operation.

      3. The query can return a MB RR.

         The MB RR carries a domain name for a host in its RDATA field.
         The mailer should deliver the message to that host via whatever
         protocol is applicable, e.g. SMTP.

      4. The query can return one or more Mail Group (MG) RRs.

         This condition means that the mailbox was actually a mailing
         list or mail group, rather than a single mailbox.  Each MG RR
         has a RDATA field that identifies a mailbox that is a member of
ToP   noToC   RFC0883 - Page 57
         the group.  The mailer should deliver a copy of the message to
         each member.

      5. The query can return a MB RR as well as one or more MG RRs.

         This condition means the the mailbox was actually a mailing
         list.  The mailer can either deliver the message to the host
         specified by the MB RR, which will in turn do the delivery to
         all members, or the mailer can use the MG RRs to do the
         expansion itself.

      In any of these cases, the response may include a Mail Information
      (MINFO) RR.  This RR is usually associated with a mail group, but
      is legal with a MB.  The MINFO RR identifies two mailboxes.  One
      of these identifies a responsible person for the original mailbox
      name.  This mailbox should be used for requests to be added to a
      mail group, etc.  The second mailbox name in the MINFO RR
      identifies a mailbox that should receive error messages for mail
      failures.  This is particularly appropriate for mailing lists when
      errors in member names should be reported to a person other than
      the one who sends a message to the list.  New fields may be added
      to this RR in the future.
ToP   noToC   RFC0883 - Page 58
Appendix 1 - Domain Name Syntax Specification

   The preferred syntax of domain names is given by the following BNF
   rules.  Adherence to this syntax will result in fewer problems with
   many applications that use domain names (e.g., mail, TELNET).  Note
   that some applications use domain names containing binary information
   and hence do not follow this syntax.

      <domain> ::=  <subdomain> | " "

      <subdomain> ::=  <label> | <subdomain> "." <label>

      <label> ::= <letter> [ [ <ldh-str> ] <let-dig> ]

      <ldh-str> ::= <let-dig-hyp> | <let-dig-hyp> <ldh-str>

      <let-dig-hyp> ::= <let-dig> | "-"

      <let-dig> ::= <letter> | <digit>

      <letter> ::= any one of the 52 alphabetic characters A through Z
      in upper case and a through z in lower case

      <digit> ::= any one of the ten digits 0 through 9

   Note that while upper and lower case letters are allowed in domain
   names no significance is attached to the case.  That is, two names
   with the same spelling but different case are to be treated as if
   identical.

   The labels must follow the rules for ARPANET host names.  They must
   start with a letter, end with a letter or digit, and have as interior
   characters only letters, digits, and hyphen.  There are also some
   restrictions on the length.  Labels must be 63 characters or less.

   For example, the following strings identify hosts in the ARPA
   Internet:

      F.ISI.ARPA     LINKABIT-DCN5.ARPA     UCL-TAC.ARPA
ToP   noToC   RFC0883 - Page 59
Appendix 2 - Field formats and encodings

           +-----------------------------------------------+
           |                                               |
           |             *****  WARNING  *****             |
           |                                               |
           |  The following formats are preliminary and    |
           | are included for purposes of explanation only.|
           | In particular, new RR types will be added,    |
           | and the size, position, and encoding of       |
           | fields are subject to change.                 |
           |                                               |
           +-----------------------------------------------+

   TYPE values

      TYPE fields are used in resource records.  Note that these types
      are not the same as the QTYPE fields used in queries, although the
      functions are often similar.

      TYPE value meaning

      A      1   a host address

      NS     2   an authoritative name server

      MD     3   a mail destination

      MF     4   a mail forwarder

      CNAME  5   the canonical name for an alias

      SOA    6   marks the start of a zone of authority

      MB     7   a mailbox domain name

      MG     8   a mail group member

      MR     9   a mail rename domain name

      NULL  10   a null RR

      WKS   11   a well known service description

      PTR   12   a domain name pointer

      HINFO 13   host information

      MINFO 14   mailbox or mail list information
ToP   noToC   RFC0883 - Page 60
   QTYPE values

      QTYPE fields appear in the question part of a query.  They include
      the values of TYPE with the following additions:

      AXFR   252 A request for a transfer of an entire zone of authority

      MAILB  253 A request for mailbox-related records (MB, MG or MR)

      MAILA  254 A request for mail agent RRs (MD and MF)

      *      255 A request for all records

   CLASS values

      CLASS fields appear in resource records

      CLASS value meaning

      IN      1   the ARPA Internet

      CS      2   the computer science network (CSNET)

   QCLASS values

      QCLASS fields appear in the question section of a query.  They
      include the values of CLASS with the following additions:

      *        255 any class
ToP   noToC   RFC0883 - Page 61
   Standard resource record formats

      All RRs have the same top level format shown below:

                                           1  1  1  1  1  1 
             0  1  2  3  4  5  6  7  8  9  0  1  2  3  4  5 
           +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
           |                                               |
           /                                               /
           /                      NAME                     /
           |                                               |
           +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
           |                      TYPE                     |
           +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
           |                     CLASS                     |
           +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
           |                      TTL                      |
           +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
           |                   RDLENGTH                    |
           +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--|
           /                     RDATA                     /
           /                                               /
           +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

         where:

         NAME    - a compressed domain name to which this resource
                   record pertains.

         TYPE    - two octets containing one of the RR type codes
                   defined in Appendix 2.  This field specifies the
                   meaning of the data in the RDATA field.

         CLASS   - two octets which specifies the class of the data in
                   the RDATA field.

         TTL     - a 16 bit signed integer that specifies the time
                   interval that the resource record may be cached
                   before the source of the information should again be
                   consulted.  Zero values are interpreted to mean that
                   the RR can only be used for the transaction in
                   progress, and should not be cached.  For example, SOA
                   records are always distributed with a zero TTL to
                   prohibit caching.  Zero values can also be used for
                   extremely volatile data.

         RDLENGTH- an unsigned 16 bit integer that specifies the length
                   in octets of the RDATA field.
ToP   noToC   RFC0883 - Page 62
         RDATA  - a variable length string of octets that describes the
                   resource.  The format of this information varies
                   according to the TYPE and CLASS of the resource
                   record.

      The format of the RDATA field is standard for all classes for the
      RR types NS, MD, MF, CNAME, SOA, MB, MG, MR, PTR, HINFO, MINFO and
      NULL.  These formats are shown below together with the appropriate
      additional section RR processing.

      CNAME RDATA format

           +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
           /                     CNAME                     /
           /                                               /
           +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

         where:

         CNAME   - A compressed domain name which specifies that the
                   domain name of the RR is an alias for a canonical
                   name specified by CNAME.

         CNAME records cause no additional section processing.  The
         RDATA section of a CNAME line in a master file is a standard
         printed domain name.

      HINFO RDATA format

           +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
           /                      CPU                      /
           +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
           /                       OS                      /
           +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

         where:

         CPU   - A character string which specifies the CPU type.  The
                   character string is represented as a single octet
                   length followed by that number of characters.    The
                   following standard strings are defined:.

            PDP-11/70   C/30        C/70        VAX-11/780   
            H-316       H-516       DEC-2060    DEC-1090T    
            ALTO        IBM-PC      IBM-PC/XT   PERQ         
            IBM-360/67  IBM-370/145                          

         OS   - A character string which specifies the operating system
         type.  The character string is represented as a single octet
ToP   noToC   RFC0883 - Page 63
         length followed by that number of characters.    The following
         standard types are defined:.

            ASP         AUGUST      BKY         CCP          
            DOS/360     ELF         EPOS        EXEC-8       
            GCOS        GPOS        ITS         INTERCOM     
            KRONOS      MCP         MOS         MPX-RT       
            MULTICS     MVT         NOS         NOS/BE       
            OS/MVS      OS/MVT      RIG         RSX11        
            RSX11M      RT11        SCOPE       SIGNAL       
            SINTRAN     TENEX       TOPS10      TOPS20       
            TSS         UNIX        VM/370      VM/CMS       
            VMS         WAITS                                

         HINFO records cause no additional section processing.

         HINFO records are used to acquire general information about a
         host.  The main use is for protocols such as FTP that can use
         special procedures when talking between machines or operating
         systems of the same type.

      MB RDATA format

           +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
           /                   MADNAME                     /
           /                                               /
           +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

         where:

         MADNAME - A compressed domain name which specifies a host which
                   has the specified mailbox.

         MB records cause additional section processing which looks up
         an A type record corresponding to MADNAME.  The RDATA section
         of a MB line in a master file is a standard printed domain
         name.

      MD RDATA format

           +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
           /                   MADNAME                     /
           /                                               /
           +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

         where:

         MADNAME - A compressed domain name which specifies a host which
ToP   noToC   RFC0883 - Page 64
                   has a mail agent for the domain which should be able
                   to deliver mail for the domain.

         MD records cause additional section processing which looks up
         an A type record corresponding to MADNAME.  The RDATA section
         of a MD line in a master file is a standard printed domain
         name.

      MF RDATA format

           +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
           /                   MADNAME                     /
           /                                               /
           +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

         where:

         MADNAME - A compressed domain name which specifies a host which
                   has a mail agent for the domain which will accept
                   mail for forwarding to the domain.

         MF records cause additional section processing which looks up
         an A type record corresponding to MADNAME.  The RDATA section
         of a MF line in a master file is a standard printed domain
         name.

      MG RDATA format

           +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
           /                   MGMNAME                     /
           /                                               /
           +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

         where:

         MGMNAME - A compressed domain name which specifies a mailbox
                   which is a member of the mail group specified by the
                   domain name.

         MF records cause no additional section processing.  The RDATA
         section of a MF line in a master file is a standard printed
         domain name.
ToP   noToC   RFC0883 - Page 65
      MINFO RDATA format

           +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
           /                    RMAILBX                    /
           +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
           /                    EMAILBX                    /
           +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

         where:

         RMAILBX - A compressed domain name which specifies a mailbox
                   which is responsible for the mailing list or mailbox.
                   If this domain name names the root, the owner of the
                   MINFO RR is responsible for itself.  Note that many
                   existing mailing lists use a mailbox X-request for
                   the RMAILBX field of mailing list X, e.g.
                   Msgroup-request for Msgroup.  This field provides a
                   more general mechanism.

         EMAILBX - A compressed domain name which specifies a mailbox
                   which is to receive error messages related to the
                   mailing list or mailbox specified by the owner of the
                   MINFO RR (similar to the ERRORS-TO: field which has
                   been proposed).  If this domain name names the root,
                   errors should be returned to the sender of the
                   message.

         MINFO records cause no additional section processing.  Although
         these records can be associated with a simple mailbox, they are
         usually used with a mailing list.  The MINFO section of a MF
         line in a master file is a standard printed domain name.

      MR RDATA format

           +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
           /                   NEWNAME                     /
           /                                               /
           +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

         where:

         NEWNAME - A compressed domain name which specifies a mailbox
                   which is the proper rename of the specified mailbox.

         MR records cause no additional section processing.  The RDATA
         section of a MR line in a master file is a standard printed
         domain name.
ToP   noToC   RFC0883 - Page 66
      NULL RDATA format

           +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
           /                  <anything>                   /
           /                                               /
           +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

         Anything at all may be in the RDATA field so long as it is
         65535 octets or less.

         NULL records cause no additional section processing.  NULL RRs
         are not allowed in master files.

      NS RDATA format

           +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
           /                   NSDNAME                     /
           /                                               /
           +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

         where:

         NSDNAME - A compressed domain name which specifies a host which
                   has a name server for the domain.

         NS records cause both the usual additional section processing
         to locate a type A record, and a special search of the zone in
         which they reside.  The RDATA section of a NS line in a master
         file is a standard printed domain name.

      PTR RDATA format

           +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
           /                   PTRDNAME                    /
           +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

         where:

         PTRDNAME - A compressed domain name which points to some
                   location in the domain name space.

         PTR records cause no additional section processing.  These RRs
         are used in special domains to point to some other location in
         the domain space.  These records are simple data, and don't
         imply any special processing similar to that performed by
         CNAME, which identifies aliases.  Appendix 3 discusses the use
         of these records in the ARPA Internet address domain.
ToP   noToC   RFC0883 - Page 67
      SOA RDATA format

           +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
           /                     MNAME                     /
           /                                               /
           +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
           /                     RNAME                     /
           +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
           |                    SERIAL                     |
           +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
           |                    REFRESH                    |
           |                                               |
           +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
           |                     RETRY                     |
           |                                               |
           +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
           |                    EXPIRE                     |
           |                                               |
           +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
           |                    MINIMUM                    |
           +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

         where:

         MNAME   - The domain name of the name server that was the
                   original source of data for this zone.

         RNAME   - A domain name which specifies the mailbox of the
                   person responsible for this zone.

         SERIAL  - The unsigned 16 bit version number of the of the
                   original copy of the zone.  This value wraps and
                   should be compared using sequence space arithmetic.

         REFRESH - The unsigned 32 bit time interval before the zone
                   should be refreshed.

         RETRY   - The unsigned 32 bit time interval that should elapse
                   before a failed refresh should be retried.

         EXPIRE  - A 32 bit time value that specifies the upper limit on
                   the time interval that can elapse before the zone is
                   no longer authoritative.

         MINIMUM - The unsigned 16 bit minimum TTL field that should be
                   exported with any RR from this zone (other than the
                   SOA itself).

         SOA records cause no additional section processing.  The RDATA
ToP   noToC   RFC0883 - Page 68
         section of a SOA line in a master file is a standard printed
         domain name for MNAME, a standard X@Y mailbox specification for
         RNAME, and decimal numbers for the remaining parameters.

         All times are in units of seconds.

         Most of these fields are pertinent only for name server
         maintenance operations.  However, MINIMUM is used in all query
         operations that retrieve RRs from a zone.  Whenever a RR is
         sent in a response to a query, the TTL field is set to the
         maximum of the TTL field from the RR and the MINIMUM field in
         the appropriate SOA.  Thus MINIMUM is a lower bound on the TTL
         field for all RRs in a zone.  RRs in a zone are never discarded
         due to timeout unless the whole zone is deleted.  This prevents
         partial copies of zones.
ToP   noToC   RFC0883 - Page 69
Appendix 3 - Internet specific field formats and operations

   Message transport

      The Internet supports name server access using TCP [10] on server
      port 53 (decimal) as well as datagram access using UDP [11] on UDP
      port 53 (decimal).  Messages sent over TCP virtual circuits are
      preceded by an unsigned 16 bit length field which describes the
      length of the message, excluding the length field itself.

           +-----------------------------------------------+
           |                                               |
           |             *****  WARNING  *****             |
           |                                               |
           |  The following formats are preliminary and    |
           | are included for purposes of explanation only.|
           | In particular, new RR types will be added,    |
           | and the size, position, and encoding of       |
           | fields are subject to change.                 |
           |                                               |
           +-----------------------------------------------+

   A RDATA format

           +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
           |                    ADDRESS                    |
           +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

      where:

      ADDRESS   - A 32 bit ARPA internet address

      Hosts that have multiple ARPA Internet addresses will have
      multiple A records.

      A records cause no additional section processing.  The RDATA
      section of an A line in a master file is an Internet address
      expressed as four decimal numbers separated by dots without any
      imbedded spaces (e.g., "10.2.0.52" or "192.0.5.6").
ToP   noToC   RFC0883 - Page 70
   WKS RDATA format

           +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
           |                    ADDRESS                    |
           +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
           |       PROTOCOL        |                       |
           +--+--+--+--+--+--+--+--+                       |
           |                                               |
           /                   <BIT MAP>                   /
           /                                               /
           +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

      where:

      ADDRESS   - An 32 bit ARPA Internet address

      PROTOCOL  - An 8 bit IP protocol number

      <BIT MAP> - A variable length bit map.  The bit map must be a
                multiple of 8 bits long.

      The WKS record is used to describe the well known services
      supported by a particular protocol on a particular internet
      address.  The PROTOCOL field specifies an IP protocol number, and
      the bit map has one bit per port of the specified protocol.  The
      first bit corresponds to port 0, the second to port 1, etc.  If
      less than 256 bits are present, the remainder are assumed to be
      zero.  The appropriate values for ports and protocols are
      specified in [13].

      For example, if PROTOCOL=TCP (6), the 26th bit corresponds to TCP
      port 25 (SMTP).  If this bit is set, a SMTP server should be
      listening on TCP port 25; if zero, SMTP service is not supported
      on the specified address.

      The anticipated use of WKS RRs is to provide availability
      information for servers for TCP and UDP.  If a server supports
      both TCP and UDP, or has multiple Internet addresses, then
      multiple WKS RRs are used.

      WKS RRs cause no additional section processing.  The RDATA section
      of a WKS record consists of a decimal protocol number followed by
      mnemonic identifiers which specify bits to be set to 1.

   IN-ADDR special domain

      The ARPA internet uses a special domain to support gateway
      location and ARPA Internet address to host mapping.  The intent of
      this domain is to allow queries to locate all gateways on a
ToP   noToC   RFC0883 - Page 71
      particular network in the ARPA Internet, and also to provide a
      guaranteed method to perform host address to host name mapping.

      Note that both of these services are similar to functions that
      could be performed by inverse queries; the difference is that this
      part of the domain name space is structured according to address,
      and hence can guarantee that the appropriate data can be located
      without an exhaustive search of the domain space.  It is
      anticipated that the special tree will be used by ARPA Internet
      resolvers for all gateway location services, but that address to
      name resolution will be performed by first trying the inverse
      query on the local name server database followed by a query in the
      special space if the inverse query fails.

      The domain is a top level domain called IN-ADDR whose substructure
      follows the ARPA Internet addressing structure.

      Domain names in the IN-ADDR domain are defined to have up to four
      labels in addition to the IN-ADDR label.  Each label is a
      character string which expresses a decimal value in the range
      0-255 (with leading zeros omitted except in the case of a zero
      octet which is represented by a single zero).  These labels
      correspond to the 4 octets of an ARPA Internet address.

      Host addresses are represented by domain names that have all four
      labels specified.  Thus data for ARPA Internet address 10.2.0.52
      is located at domain name 52.0.2.10.IN-ADDR.  The reversal, though
      awkward to read,  allows zones to follow the natural grouping of
      hosts within networks.  For example, 10.IN-ADDR can be a zone
      containing data for the ARPANET, while 26.IN-ADDR can be a
      separate zone for MILNET.  Address nodes are used to hold pointers
      to primary host names in the normal domain space.

      Network addresses correspond to some of the non-terminal nodes in
      the IN-ADDR tree, since ARPA Internet network numbers are either
      1, 2, or 3 octets.  Network nodes are used to hold pointers to
      primary host names (which happen to be gateways) in the normal
      domain space.  Since a gateway is, by definition, on more than one
      network, it will typically have two or more network nodes that
      point at the gateway.  Gateways will also have host level pointers
      at their fully qualified addresses.

      Both the gateway pointers at network nodes and the normal host
      pointers at full address nodes use the PTR RR to point back to the
      primary domain names of the corresponding hosts.

      For example, part of the IN-ADDR domain will contain information
      about the ISI to MILNET and MIT gateways, and hosts F.ISI.ARPA and
      MULTICS.MIT.ARPA.  Assuming that ISI gateway has addresses
ToP   noToC   RFC0883 - Page 72
      10.2.0.22 and 26.0.0.103, and a name MILNET-GW.ISI.ARPA, and the
      MIT gateway has addresses 10.0.0.77 and 18.10.0.4 and a name
      GW.MIT.ARPA, the domain database would contain:

           10.IN-ADDR           PTR  IN MILNET-GW.ISI.ARPA   
           10.IN-ADDR           PTR  IN GW.MIT.ARPA          
           18.IN-ADDR           PTR  IN GW.MIT.ARPA          
           26.IN-ADDR           PTR  IN MILNET-GW.ISI.ARPA   
           22.0.2.10.IN-ADDR    PTR  IN MILNET-GW.ISI.ARPA   
           103.0.0.26.IN-ADDR   PTR  IN MILNET-GW.ISI.ARPA   
           77.0.0.10.IN-ADDR    PTR  IN GW.MIT.ARPA          
           4.0.10.18.IN-ADDR    PTR  IN GW.MIT.ARPA          
           52.0.2.10.IN-ADDR    PTR  IN F.ISI.ARPA           
           6.0.0.10.IN-ADDR     PTR  IN MULTICS.MIT.ARPA     

      Thus a program which wanted to locate gateways on net 10 would
      originate a query of the form QTYPE=PTR, QCLASS=IN,
      QNAME=10.IN-ADDR.  It would receive two RRs in response:

           10.IN-ADDR           PTR  IN MILNET-GW.ISI.ARPA   
           10.IN-ADDR           PTR  IN GW.MIT.ARPA          

      The program could then originate QTYPE=A, QCLASS=IN queries for
      MILNET-GW.ISI.ARPA and GW.MIT.ARPA to discover the ARPA Internet
      addresses of these gateways.

      A resolver which wanted to find the host name corresponding to
      ARPA Internet host address 10.0.0.6 might first try an inverse
      query on the local name server, but find that this information
      wasn't available.  It could then try a query of the form
      QTYPE=PTR, QCLASS=IN, QNAME=6.0.0.10.IN-ADDR, and would receive:

           6.0.0.10.IN-ADDR     PTR  IN MULTICS.MIT.ARPA     

      Several cautions apply to the use of these services:

         Since the IN-ADDR special domain and the normal domain for a
         particular host or gateway will be in different zones, the
         possibility exists that that the data may be inconsistent.

         Gateways will often have two names in separate domains, only
         one of which can be primary.

         Systems that use the domain database to initialize their
         routing tables must start with enough gateway information to
         guarantee that they can access the appropriate name server.

         The gateway data only reflects the existence of a gateway in a
ToP   noToC   RFC0883 - Page 73
         manner equivalent to the current HOSTS.TXT file.  It doesn't
         replace the dynamic availability information from GGP or EGP.
ToP   noToC   RFC0883 - Page 74
   [1]  E. Feinler, K. Harrenstien, Z. Su, and V. White, "DOD Internet
        Host Table Specification", RFC 810, Network Information Center,
        SRI International, March 1982.

   [2]  J. Postel, "Computer Mail Meeting Notes", RFC 805,
        USC/Information Sciences Institute, February 1982.

   [3]  Z. Su, and J. Postel, "The Domain Naming Convention for Internet
        User Applications", RFC 819, Network Information Center, SRI
        International, August 1982.

   [4]  Z. Su, "A Distributed System for Internet Name Service",
        RFC 830, Network Information Center, SRI International,
        October 1982.

   [5]  K. Harrenstien, and V. White, "NICNAME/WHOIS", RFC 812, Network
        Information Center, SRI International, March 1982.

   [6]   M. Solomon, L. Landweber, and D. Neuhengen, "The CSNET Name
        Server", Computer Networks, vol 6, nr 3, July 1982.

   [7]  K. Harrenstien, "NAME/FINGER", RFC 742, Network Information
        Center, SRI International, December 1977.

   [8]  J. Postel, "Internet Name Server", IEN 116, USC/Information
        Sciences Institute, August 1979.

   [9]  K. Harrenstien, V. White, and E. Feinler, "Hostnames Server",
        RFC 811, Network Information Center, SRI International,
        March 1982.

   [10] J. Postel, "Transmission Control Protocol", RFC 793,
        USC/Information Sciences Institute, September 1981.

   [11] J. Postel, "User Datagram Protocol", RFC 768, USC/Information
        Sciences Institute, August 1980.

   [12] J. Postel, "Simple Mail Transfer Protocol", RFC 821,
        USC/Information Sciences Institute, August 1980.

   [13] J. Reynolds, and J. Postel, "Assigned Numbers", RFC 870,
        USC/Information Sciences Institute, October 1983.

   [14] P. Mockapetris, "Domain names - Concepts and Facilities,"
        RFC 882, USC/Information Sciences Institute, November 1983.

   
ToP   noToC   RFC0883 - Page 75
INDEX
    
   * usage........................................................37, 57
    
   A RDATA format.....................................................67
    
   byte order..........................................................6
    
   cache queue....................................................35, 42
   character case..................................................7, 31
   CLASS...........................................................9, 58
   completion.........................................................19
   compression........................................................31
   CNAME RR...........................................................60
    
   header format......................................................26
   HINFO RR...........................................................60
    
   include files......................................................43
   inverse queries....................................................17
    
   mailbox names......................................................53
   master files.......................................................43
   MB RR..............................................................61
   MD RR..............................................................61
   message format.....................................................13
   MF RR..............................................................62
   MG RR..............................................................62
   MINFO RR...........................................................63
   MR RR..............................................................63
    
   NULL RR............................................................64
   NS RR..............................................................64
    
   PTR RR.........................................................64, 69
    
   QCLASS.............................................................58
   QTYPE..............................................................57
   queries (standard).................................................15
    
   recursive service..................................................24
   RR format..........................................................59
    
   SOA RR.............................................................65
   Special domains....................................................68
    
   TYPE...............................................................57
    
   WKS type RR........................................................68