0   x   1   Specified protocols insecure, others may be secure.
        x   0   0   Useless.  Gives key but no protocols to use it.
        x   0   1   Useless.  Denies key but for no protocols.
        x   x   0   Specifies key for protocols and asserts that
                      those protocols are implemented with security.
        x   x   1   Algorithm not understood for protocol.

      (remember, in reference to the above table, that a protocol
       byte of 255 means all protocols with protocol byte values
       assigned)

3.7 KEY RRs in the Construction of Responses

   An explicit request for KEY RRs does not cause any special additional
   information processing except, of course, for the corresponding SIG
   RR from a security aware server.

   Security aware DNS servers MUST include KEY RRs as additional
   information in responses where appropriate including the following:

   (1) On the retrieval of NS RRs, the zone key KEY RR(s) for the zone
   served by these name servers MUST be included as additional
   information if space is avilable.  There will always be at least one
   such KEY RR in a secure zone, even if it has the no-key type value to
   indicate that the subzone is insecure.  If not all additional
   information will fit, the KEY RR(s) have higher priority than type A
   or AAAA glue RRs.  If such a KEY RR does not fit on a retrieval, the
   retrieval must be considered truncated.

   (2) On retrieval of type A or AAAA RRs, the end entity KEY RR(s) MUST
   be included if space is available.  On inclusion of A or AAAA RRs as
   additional information, their KEY RRs will also be included but with
   lower priority than the relevant A or AAAA RRs.









 
RFC 2065                DNS Security Extensions             January 1997


3.8 File Representation of KEY RRs

   KEY RRs may appear as lines in a zone data master file.

   The flag field, protocol, and algorithm number octets are then
   represented as unsigned integers.  Note that if the type field has
   the "no key" value or the algorithm specified is 253, nothing appears
   after the algorithm octet.

   The remaining public key portion is represented in base 64 (see
   Appendix) and may be divided up into any number of white space
   separated substrings, down to single base 64 digits, which are
   concatenated to obtain the full signature.  These substrings can span
   lines using the standard parenthesis.

   Note that the public key may have internal sub-fields but these do
   not appear in the master file representation.  For example, with
   algorithm 1 there is a public exponent size, then a public exponent,
   and then a modulus.  With algorithm 254, there will be an OID size,
   an OID, and algorithm dependent information. But in both cases only a
   single logical base 64 string will appear in the master file.

4. The SIG Resource Record

   The SIG or "signature" resource record (RR) is the fundamental way
   that data is authenticated in the secure Domain Name System (DNS). As
   such it is the heart of the security provided.

   The SIG RR unforgably authenticates other RRs of a particular type,
   class, and name and binds them to a time interval and the signer's
   domain name.  This is done using cryptographic techniques and the
   signer's private key.  The signer is frequently the owner of the zone
   from which the RR originated.



















 
RFC 2065                DNS Security Extensions             January 1997