rfc2065.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 1,439 行 · 第 1/5 页

   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).

   If signatures are always separately retrieved and verified when
   retrieving the information they authenticate, there will be more
   trips to the server and performance will suffer.  To avoid this,
   security aware servers mitigate that degradation by always attempting
   to send the signature(s) needed.

2.3.1 The SIG Resource Record

   The syntax of a SIG resource record (signature) is described in
   Section 4.  It includes the type of the RR(s) being signed, the name
   of the signer, the time at which the signature was created, the time
   it expires (when it is no longer to be believed), its original time
   to live (which may be longer than its current time to live but cannot
   be shorter), the cryptographic algorithm in use, and the actual
   signature.

   Every name in a secured zone will have associated with it at least
   one SIG resource record for each resource type under that name except
   for glue RRs and delgation point NS RRs.  A security aware server
   supporting the performance enhanced version of the DNS protocol
   security extensions will attempt to return, with RRs retrieved, the
   corresponding SIGs.  If a server does not support the protocol, the
   resolver must retrieve all the SIG records for a name and select the
   one or ones that sign the resource record(s) that resolver is
   interested in.











Eastlake & Kaufman          Standards Track                     [Page 6]

RFC 2065                DNS Security Extensions             January 1997


2.3.2 Authenticating Name and Type Non-existence

   The above security mechanism provides only a way to sign existing RRs
   in a zone.  "Data origin" authentication is not obviously provided
   for the non-existence of a domain name in a zone or the non-existence
   of a type for an existing name.  This gap is filled by the NXT RR
   which authenticatably asserts a range of non-existent names in a zone
   and the non-existence of types for the name just before that range.

   Section 5 below covers the NXT RR.

2.3.3 Special Considerations With Time-to-Live

   A digital signature will fail to verify if any change has occurred to
   the data between the time it was originally signed and the time the
   signature is verified.  This conflicts with our desire to have the
   time-to-live field tick down when resource records are cached.

   This could be avoided by leaving the time-to-live out of the digital
   signature, but that would allow unscrupulous servers to set
   arbitrarily long time to live values undetected.  Instead, we include
   the "original" time-to-live in the signature and communicate that
   data in addition to the current time-to-live. Unscrupulous servers
   under this scheme can manipulate the time to live but a security
   aware resolver will bound the TTL value it uses at the original
   signed value.  Separately, signatures include a time signed and an
   expiration time.  A resolver that knows the absolute time can
   determine securely whether a signature has expired.  It is not
   possible to rely solely on the signature expiration as a substitute
   for the TTL, however, since the TTL is primarily a database
   consistency mechanism and, in any case, non-security aware servers
   that depend on TTL must still be supported.

2.3.4 Special Considerations at Delegation Points

   DNS security would like to view each zone as a unit of data
   completely under the control of the zone owner and signed by the
   zone's key.  But the operational DNS views the leaf nodes in a zone,
   which are also the apex nodes of a subzone (i.e., delegation points),
   as "really" belonging to the subzone.  These nodes occur in two
   master files and may have RRs signed by both the upper and lower
   zone's keys.  A retrieval could get a mixture of these RRs and SIGs,
   especially since one server could be serving both the zone above and
   below a delegation point.

   In general, there must be a zone KEY RR for the subzone in the
   superzone and the copy signed in the superzone is controlling.  For
   all but one other RR type that should appearing in both the superzone



Eastlake & Kaufman          Standards Track                     [Page 7]

RFC 2065                DNS Security Extensions             January 1997


   and subzone, the data from the subzone is more authoritative.  To
   avoid conflicts, only the KEY RR in the superzone should be signed
   and the NS and any A (glue) RRs should only be signed in the subzone.
   The SOA and any other RRs that have the zone name as owner should
   appear only in the subzone and thus are signed there. The NXT RR type
   is an exceptional case that will always appear differently and
   authoritatively in both the superzone and subzone, if both are
   secure, as described in Section 5.

2.3.5 Special Considerations with CNAME RRs

   There is a significant problem when security related RRs with the
   same owner name as a CNAME RR are retrieved from a non-security-aware
   server.  In particular, an initial retrieval for the CNAME or any
   other type will not retrieve any associated signature, key, or NXT
   RR. For types other than CNAME, it will retrieve that type at the
   target name of the CNAME (or chain of CNAMEs) and will return the
   CNAME as additional information.  In particular, a specific retrieval
   for type SIG will not get the SIG, if any, at the original CNAME
   domain name but rather a SIG at the target name.

   In general, security aware servers MUST be used to securely CNAME in
   DNS.  Security aware servers must (1) allow KEY, SIG, and NXT RRs
   along with CNAME RRs, (2) suppress CNAME processing on retrieval of
   these types as well as on retrieval of the type CNAME, and (3)
   automatically return SIG RRs authenticating the CNAME or CNAMEs
   encountered in resolving a query.  This is a change from the previous
   DNS standard which prohibited any other RR type at a node where a
   CNAME RR was present.

2.3.6 Signers Other Than The Zone

   There are two cases where a SIG resource record is signed by other
   than the zone private key.  One is for support of dynamic update
   where an entity is permitted to authenticate/update its own records.
   The public key of the entity must be present in the DNS and be
   appropriately signed but the other RR(s) may be signed with the
   entity's key.  The other is for support of transaction and request
   authentication as described in Section 2.4 immediately below.

2.4 DNS Transaction and Request Authentication

   The data origin authentication service described above protects
   retrieved resource records but provides no protection for DNS
   requests or for message headers.






Eastlake & Kaufman          Standards Track                     [Page 8]

RFC 2065                DNS Security Extensions             January 1997


   If header bits are falsely set by a server, there is little that can
   be done.  However, it is possible to add transaction authentication.
   Such authentication means that a resolver can be sure it is at least
   getting messages from the server it thinks it queried, that the
   response is from the query it sent, and that these messages have not
   been diddled in transit.  This is accomplished by optionally adding a
   special SIG resource record at the end of the reply which digitally
   signs the concatenation of the server's response and the resolver's
   query.

   Requests can also be authenticated by including a special SIG RR at
   the end of the request.  Authenticating requests serves no function
   in the current DNS and requests with a non-empty additional
   information section are ignored by almost all current DNS servers.
   However, this syntax for signing requests is defined in connection
   with authenticating future secure dynamic update requests or the
   like.

   The private keys used in transaction and request security belongs to
   the host composing the request or reply message, not to the zone
   involved.  The corresponding public key is normally stored in and
   retrieved from the DNS.

   Because requests and replies are highly variable, message
   authentication SIGs can not be pre-calculated.  Thus it will be
   necessary to keep the private key on-line, for example in software or
   in a directly connected piece of hardware.

3. The KEY Resource Record

   The KEY resource record (RR) is used to document a key that is
   associated with a Domain Name System (DNS) name.  It will be a public
   key as only public keys are stored in the DNS.  This can be the
   public key of a zone, a host or other end entity, or a user.  A KEY
   RR is, like any other RR, authenticated by a SIG RR. Security aware
   DNS implementations MUST be designed to handle at least two
   simultaneously valid keys of the same type associated with a name.

   The type number for the KEY RR is 25.












Eastlake & Kaufman          Standards Track                     [Page 9]

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 [e-mail].  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.





Eastlake & Kaufman          Standards Track                    [Page 10]

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