rfc2535.txt

bind 9.3结合mysql数据库

   signatures. Commonly, there will be a single private key that
   authenticates an entire zone but there might be multiple keys for
   different algorithms, signers, etc. If a security aware resolver
   reliably learns a public key of the zone, it can authenticate, for
   signed data read from that zone, that it is properly authorized.  The
   most secure implementation is for the zone private key(s) to be kept
   off-line and used to re-sign all of the records in the zone
   periodically.  However, there are cases, for example dynamic update
   [RFCs 2136, 2137], where DNS private keys need to be on-line [RFC
   2541].

   The data origin authentication key(s) are associated with the zone
   and not with the servers that store copies of the data.  That means
   compromise of a secondary server or, if the key(s) are kept off line,
   even the primary server 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 could learn a public key of a zone either by reading it
   from the DNS or by having it staticly configured.  To reliably learn
   a public key by reading it from the DNS, the key itself must be
   signed with a key the resolver trusts. The resolver must be
   configured with at least a public key which authenticates one zone as
   a starting point. From there, it can securely read public keys of
   other zones, if the intervening zones in the DNS tree are secure and
   their signed keys accessible.

   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 the key resource type needed for key distribution.
   (Data non-existence authentication also requires the NXT RR as
   described in 2.3.2.)  This service can be supported by existing
   resolver and caching server implementations so long as they can
   support the additional resource types (see Section 9). The one
   exception is that CNAME referrals in a secure zone can not be
   authenticated if they are from non-security aware servers (see
   Section 2.3.5).





Eastlake                    Standards Track                     [Page 6]

RFC 2535                DNS Security Extensions               March 1999


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

2.3.1 The SIG Resource Record

   The syntax of a SIG resource record (signature) is described in
   Section 4.  It cryptographicly binds the RRset being signed to the
   signer and a validity interval.

   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 address RRs and delegation point NS RRs.  A security aware
   server will attempt to return, with RRs retrieved, the corresponding
   SIGs.  If a server is not security aware, the resolver must retrieve
   all the SIG records for a name and select the one or ones that sign
   the resource record set(s) that resolver is interested in.

2.3.2 Authenticating Name and Type Non-existence

   The above security mechanism only provides a way to sign existing
   RRsets 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 existing 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 (TTL) field of resource records tick down while they 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 TTL values undetected.  Instead, we include the
   "original" TTL in the signature and communicate that data along with
   the current TTL. Unscrupulous servers under this scheme can
   manipulate the TTL but a security aware resolver will bound the TTL
   value it uses at the original signed value.  Separately, signatures
   include a signature inception time and a signature expiration time. A



Eastlake                    Standards Track                     [Page 7]

RFC 2535                DNS Security Extensions               March 1999


   resolver that knows the absolute time can determine securely whether
   a signature is in effect.  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 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 with each entry
   (RRset) signed by a special private key held by the zone manager.
   But the DNS protocol 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
   might 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. [RFC 2181]

   There MUST be a zone KEY RR, signed by its superzone, for every
   subzone if the superzone is secure. This will normally appear in the
   subzone and may also be included in the superzone.  But, in the case
   of an unsecured subzone which can not or will not be modified to add
   any security RRs, a KEY declaring the subzone to be unsecured MUST
   appear with the superzone signature in the superzone, if the
   superzone is secure. For all but one other RR type the data from the
   subzone is more authoritative so only the subzone KEY RR should be
   signed in the superzone if it appears there. The NS and any glue
   address 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 only there. The NXT RR type is the
   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

   There is a 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 may
   not retrieve any associated SIG, KEY, or NXT RR. For retrieved types
   other than CNAME, it will retrieve that type at the target name of
   the CNAME (or chain of CNAMEs) and will also return the CNAME.  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.





Eastlake                    Standards Track                     [Page 8]

RFC 2535                DNS Security Extensions               March 1999


   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 [RFCs 1034/1035] 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 cases where the signer in a SIG resource record is other
   than one of the private key(s) used to authenticate a zone.

   One is for support of dynamic update [RFC 2136] (or future requests
   which require secure authentication) where an entity is permitted to
   authenticate/update its records [RFC 2137] and the zone is operating
   in a mode where the zone key is not on line. The public key of the
   entity must be present in the DNS and be signed by a zone level key
   but the other RR(s) may be signed with the entity's key.

   A second case is support of transaction and request authentication as
   described in Section 2.4.

   In additions, signatures can be included on resource records within
   the DNS for use by applications other than DNS. DNS related
   signatures authenticate that data originated with the authority of a
   zone owner or that a request or transaction originated with the
   relevant entity. Other signatures can provide other types of
   assurances.

2.4 DNS Transaction and Request Authentication

   The data origin authentication service described above protects
   retrieved resource records and the non-existence of resource records
   but provides no protection for DNS requests or for message headers.

   If header bits are falsely set by a bad 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 and that the response is from the query it sent (i.e., 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.





Eastlake                    Standards Track                     [Page 9]

RFC 2535                DNS Security Extensions               March 1999


   Requests can also be authenticated by including a special SIG RR at
   the end of the request.  Authenticating requests serves no function
   in older DNS servers and requests with a non-empty additional
   information section produce error returns or may even be ignored by
   many of them. However, this syntax for signing requests is defined as
   a way of authenticating secure dynamic update requests [RFC 2137] or
   future requests requiring authentication.

   The private keys used in transaction security belong to the entity
   composing the reply, not to the zone involved.  Request
   authentication may also involve the private key of the host or other
   entity composing the request or other private keys depending on the
   request authority it is sought to establish. The corresponding public
   key(s) are normally stored in and retrieved from the DNS for
   verification.

   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 store a public key that is
   associated with a Domain Name System (DNS) name.  This can be the
   public key of a zone, a user, or a host or other end entity. Security
   aware DNS implementations MUST be designed to handle at least two
   simultaneously valid keys of the same type associated with the same
   name.

   The type number for the KEY RR is 25.

   A KEY RR is, like any other RR, authenticated by a SIG RR.  KEY RRs
   must be signed by a zone level key.

3.1 KEY RDATA format

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











Eastlake                    Standards Track                    [Page 10]

RFC 2535                DNS Security Extensions               March 1999


                        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 KEY RR is not intended for storage of certificates and a separate
   certificate RR has been developed for that purpose, defined in [RFC
   2538].

   The meaning of the KEY RR owner name, flags, and protocol octet are
   described in Sections 3.1.1 through 3.1.5 below.  The flags and
   algorithm must be examined before any data following the algorithm
   octet as they control the existence and format of any following data.
   The algorithm and public key fields are described in Section 3.2.
   The format of the public key is algorithm dependent.

   KEY RRs do not specify their validity period but their authenticating
   SIG RR(s) do as described in Section 4 below.