document.

2.  Overview of the DNS Extensions

   The Domain Name System (DNS) protocol security extensions provide
   three distinct services: key distribution as described in Section 2.2
   below, data origin authentication as described in Section 2.3 below,
   and transaction and request authentication, described in Section 2.4
   below.

   Special considerations related to "time to live", CNAMEs, and
   delegation points are also discussed in Section 2.3.

2.1 Services Not Provided

   It is part of the design philosophy of the DNS that the data in it is
   public and that the DNS gives the same answers to all inquirers.

   Following this philosophy, no attempt has been made to include any
   sort of access control lists or other means to differentiate
   inquirers.





 
RFC 2065                DNS Security Extensions             January 1997


   In addition, no effort has been made to provide for any
   confidentiality for queries or responses.  (This service may be
   available via IPSEC [RFC 1825].)

2.2 Key Distribution

   Resource records (RRs) are defined to associate keys with DNS names.
   This permits the DNS to be used as a public key distribution
   mechanism in support of the DNS data origin authentication and other
   security services.

   The syntax of a KEY resource record (RR) is described in Section 3.
   It includes an algorithm identifier, the actual public key
   parameters, and a variety of flags including those indicating the
   type of entity the key is associated with and/or asserting that there
   is no key associated with that entity.

   Under conditions described in Section 3.7, security aware DNS servers
   will automatically attempt to return KEY resources as additional
   information, along with those resource records actually requested, to
   minimize the number of queries needed.

2.3 Data Origin Authentication and Integrity

   Authentication is provided by associating with resource records in
   the DNS cryptographically generated digital signatures.  Commonly,
   there will be a single private key that signs for an entire zone. If
   a security aware resolver reliably learns the public key of the zone,
   it can verify, for signed data read from that zone, that it was
   properly authorized and is reasonably current.  The expected
   implementation is for the zone private key to be kept off-line and
   used to re-sign all of the records in the zone periodically.

   This data origin authentication key belongs to the zone and not to
   the servers that store copies of the data.  That means compromise of
   a server or even all servers for a zone will not necessarily affect
   the degree of assurance that a resolver has that it can determine
   whether data is genuine.

   A resolver can learn the public key of a zone either by reading it
   from DNS or by having it staticly configured.  To reliably learn the
   public key by reading it from DNS, the key itself must be signed.
   Thus, to provide a reasonable degree of security, the resolver must
   be configured with at least the public key of one zone that it can
   use to authenticate signatures.  From there, it can securely read the
   public keys of other zones, if the intervening zones in the DNS tree
   are secure and their signed keys accessible.  (It is in principle
   more secure to have the resolver manually configured with the public




 
RFC 2065                DNS Security Extensions             January 1997


   keys of multiple zones, since then the compromise of a single zone
   would not permit the faking of information from other zones.  It is
   also more administratively cumbersome, however, particularly when
   public keys change.)

   Adding data origin authentication and integrity requires no change to
   the "on-the-wire" DNS protocol beyond the addition of the signature
   resource type and, as a practical matter, the key resource type
   needed for key distribution. This service can be supported by
   existing resolver and server implementations so long as they can
   support the additional resource types (see Section 8). The one
   exception is that CNAME referrals from a secure zone can not be
   authenticated if they are from non-security aware servers (see
   Section 2.3.5).