RFC 2065                DNS Security Extensions             January 1997


3.1 KEY RDATA format

   The RDATA for a KEY RR consists of flags, a protocol octet, the
   algorithm number, and the public key itself.  The format is as
   follows:

                        1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |             flags             |    protocol   |   algorithm   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               /
   /                          public key                           /
   /                                                               /
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|

   The meaning of the KEY RR owner name, flags, and protocol octet are
   described in Sections 3.2, 3.3 and 3.4 below respectively.  The flags
   and algorithm must be examined before any data following the
   algorithm octet as they control the format and even whether there is
   any following data.  The algorithm and public key fields are
   described in Section 3.5.  The format of the public key is algorithm
   dependent.

3.2 Object Types, DNS Names, and Keys

   The public key in a KEY RR belongs to the object named in the owner
   name.

   This DNS name may refer to up to three different categories of
   things.  For example, dee.cybercash.com could be (1) a zone, (2) a
   host or other end entity , and (3) the mapping into a DNS name of the
   user or account dee@cybercash.com.  Thus, there are flags, as
   described below, in the KEY RR to indicate with which of these roles
   the owner name and public key are associated.  Note that an
   appropriate zone KEY RR MUST occur at the apex node of a secure zone
   and at every leaf node which is a delegation point (and thus the same
   owner name as the apex of a subzone) within a secure zone.

   Although the same name can be used for up to all three of these
   categories, such overloading of a name is discouraged.  It is also
   possible to use the same key for different things with the same name
   or even different names, but this is strongly discouraged.  In
   particular, the use of a zone key as a non-zone key will usually
   require that the corresponding private key be kept on line and
   thereby become more vulnerable.






 
RFC 2065                DNS Security Extensions             January 1997


   In addition to the name type bits, there are additional flag bits
   including the "type" field, "experimental" bit, "signatory" field,
   etc., as described below.

3.3 The KEY RR Flag Field

   In the "flags" field:

        Bit 0 and 1 are the key "type" field.  Bit 0 a one indicates
   that use of the key is prohibited for authentication.  Bit 1 a one
   indicates that use of the key is prohibited for confidentiality. If
   this field is zero, then use of the key for authentication and/or
   confidentiality is permitted. Note that DNS security makes use of
   keys for authentication only. Confidentiality use flagging is
   provided for use of keys in other protocols.  Implementations not
   intended to support key distribution for confidentiality MAY require
   that the confidentiality use prohibited bit be on for keys they
   serve.  If both bits of this field are one, the "no key" value, there
   is no key information and the RR stops after the algorithm octet.  By
   the use of this "no key" value, a signed KEY RR can authenticatably
   assert that, for example, a zone is not secured.

        Bit 2 is the "experimental" bit.  It is ignored if the type
   field indicates "no key" and the following description assumes that
   type field to be non-zero.  Keys may be associated with zones,
   entities, or users for experimental, trial, or optional use, in which
   case this bit will be one.  If this bit is a zero, it means that the
   use or availability of security based on the key is "mandatory".
   Thus, if this bit is off for a zone key, the zone should be assumed
   secured by SIG RRs and any responses indicating the zone is not
   secured should be considered bogus.  If this bit is a one for a host
   or end entity, it might sometimes operate in a secure mode and at
   other times operate without security.  The experimental bit, like all
   other aspects of the KEY RR, is only effective if the KEY RR is