rfc4035.txt

非常好的dns解析软件

4.5.  Response Caching

   A security-aware resolver SHOULD cache each response as a single
   atomic entry containing the entire answer, including the named RRset
   and any associated DNSSEC RRs.  The resolver SHOULD discard the
   entire atomic entry when any of the RRs contained in it expire.  In
   most cases the appropriate cache index for the atomic entry will be
   the triple <QNAME, QTYPE, QCLASS>, but in cases such as the response
   form described in Section 3.1.3.2 the appropriate cache index will be
   the double <QNAME,QCLASS>.

   The reason for these recommendations is that, between the initial
   query and the expiration of the data from the cache, the
   authoritative data might have been changed (for example, via dynamic
   update).






Arends, et al.              Standards Track                    [Page 21]

RFC 4035             DNSSEC Protocol Modifications            March 2005


   There are two situations for which this is relevant:

   1.  By using the RRSIG record, it is possible to deduce that an
       answer was synthesized from a wildcard.  A security-aware
       recursive name server could store this wildcard data and use it
       to generate positive responses to queries other than the name for
       which the original answer was first received.

   2.  NSEC RRs received to prove the non-existence of a name could be
       reused by a security-aware resolver to prove the non-existence of
       any name in the name range it spans.

   In theory, a resolver could use wildcards or NSEC RRs to generate
   positive and negative responses (respectively) until the TTL or
   signatures on the records in question expire.  However, it seems
   prudent for resolvers to avoid blocking new authoritative data or
   synthesizing new data on their own.  Resolvers that follow this
   recommendation will have a more consistent view of the namespace.

4.6.  Handling of the CD and AD Bits

   A security-aware resolver MAY set a query's CD bit in order to
   indicate that the resolver takes responsibility for performing
   whatever authentication its local policy requires on the RRsets in
   the response.  See Section 3.2 for the effect this bit has on the
   behavior of security-aware recursive name servers.

   A security-aware resolver MUST clear the AD bit when composing query
   messages to protect against buggy name servers that blindly copy
   header bits that they do not understand from the query message to the
   response message.

   A resolver MUST disregard the meaning of the CD and AD bits in a
   response unless the response was obtained by using a secure channel
   or the resolver was specifically configured to regard the message
   header bits without using a secure channel.

4.7.  Caching BAD Data

   While many validation errors will be transient, some are likely to be
   more persistent, such as those caused by administrative error
   (failure to re-sign a zone, clock skew, and so forth).  Since
   requerying will not help in these cases, validating resolvers might
   generate a significant amount of unnecessary DNS traffic as a result
   of repeated queries for RRsets with persistent validation failures.

   To prevent such unnecessary DNS traffic, security-aware resolvers MAY
   cache data with invalid signatures, with some restrictions.



Arends, et al.              Standards Track                    [Page 22]

RFC 4035             DNSSEC Protocol Modifications            March 2005


   Conceptually, caching such data is similar to negative caching
   ([RFC2308]), except that instead of caching a valid negative
   response, the resolver is caching the fact that a particular answer
   failed to validate.  This document refers to a cache of data with
   invalid signatures as a "BAD cache".

   Resolvers that implement a BAD cache MUST take steps to prevent the
   cache from being useful as a denial-of-service attack amplifier,
   particularly the following:

   o  Since RRsets that fail to validate do not have trustworthy TTLs,
      the implementation MUST assign a TTL.  This TTL SHOULD be small,
      in order to mitigate the effect of caching the results of an
      attack.

   o  In order to prevent caching of a transient validation failure
      (which might be the result of an attack), resolvers SHOULD track
      queries that result in validation failures and SHOULD only answer
      from the BAD cache after the number of times that responses to
      queries for that particular <QNAME, QTYPE, QCLASS> have failed to
      validate exceeds a threshold value.

   Resolvers MUST NOT return RRsets from the BAD cache unless the
   resolver is not required to validate the signatures of the RRsets in
   question under the rules given in Section 4.2 of this document.  See
   Section 3.2.2 for discussion of how the responses returned by a
   security-aware recursive name server interact with a BAD cache.

4.8.  Synthesized CNAMEs

   A validating security-aware resolver MUST treat the signature of a
   valid signed DNAME RR as also covering unsigned CNAME RRs that could
   have been synthesized from the DNAME RR, as described in [RFC2672],
   at least to the extent of not rejecting a response message solely
   because it contains such CNAME RRs.  The resolver MAY retain such
   CNAME RRs in its cache or in the answers it hands back, but is not
   required to do so.

4.9.  Stub Resolvers

   A security-aware stub resolver MUST support the DNSSEC RR types, at
   least to the extent of not mishandling responses just because they
   contain DNSSEC RRs.








Arends, et al.              Standards Track                    [Page 23]

RFC 4035             DNSSEC Protocol Modifications            March 2005


4.9.1.  Handling of the DO Bit

   A non-validating security-aware stub resolver MAY include the DNSSEC
   RRs returned by a security-aware recursive name server as part of the
   data that the stub resolver hands back to the application that
   invoked it, but is not required to do so.  A non-validating stub
   resolver that seeks to do this will need to set the DO bit in order
   to receive DNSSEC RRs from the recursive name server.

   A validating security-aware stub resolver MUST set the DO bit,
   because otherwise it will not receive the DNSSEC RRs it needs to
   perform signature validation.

4.9.2.  Handling of the CD Bit

   A non-validating security-aware stub resolver SHOULD NOT set the CD
   bit when sending queries unless it is requested by the application
   layer, as by definition, a non-validating stub resolver depends on
   the security-aware recursive name server to perform validation on its
   behalf.

   A validating security-aware stub resolver SHOULD set the CD bit,
   because otherwise the security-aware recursive name server will
   answer the query using the name server's local policy, which may
   prevent the stub resolver from receiving data that would be
   acceptable to the stub resolver's local policy.

4.9.3.  Handling of the AD Bit

   A non-validating security-aware stub resolver MAY chose to examine
   the setting of the AD bit in response messages that it receives in
   order to determine whether the security-aware recursive name server
   that sent the response claims to have cryptographically verified the
   data in the Answer and Authority sections of the response message.
   Note, however, that the responses received by a security-aware stub
   resolver are heavily dependent on the local policy of the
   security-aware recursive name server.  Therefore, there may be little
   practical value in checking the status of the AD bit, except perhaps
   as a debugging aid.  In any case, a security-aware stub resolver MUST
   NOT place any reliance on signature validation allegedly performed on
   its behalf, except when the security-aware stub resolver obtained the
   data in question from a trusted security-aware recursive name server
   via a secure channel.

   A validating security-aware stub resolver SHOULD NOT examine the
   setting of the AD bit in response messages, as, by definition, the
   stub resolver performs its own signature validation regardless of the
   setting of the AD bit.



Arends, et al.              Standards Track                    [Page 24]

RFC 4035             DNSSEC Protocol Modifications            March 2005


5.  Authenticating DNS Responses

   To use DNSSEC RRs for authentication, a security-aware resolver
   requires configured knowledge of at least one authenticated DNSKEY or
   DS RR.  The process for obtaining and authenticating this initial
   trust anchor is achieved via some external mechanism.  For example, a
   resolver could use some off-line authenticated exchange to obtain a
   zone's DNSKEY RR or to obtain a DS RR that identifies and
   authenticates a zone's DNSKEY RR.  The remainder of this section
   assumes that the resolver has somehow obtained an initial set of
   trust anchors.

   An initial DNSKEY RR can be used to authenticate a zone's apex DNSKEY
   RRset.  To authenticate an apex DNSKEY RRset by using an initial key,
   the resolver MUST:

   1.  verify that the initial DNSKEY RR appears in the apex DNSKEY
       RRset, and that the DNSKEY RR has the Zone Key Flag (DNSKEY RDATA
       bit 7) set; and

   2.  verify that there is some RRSIG RR that covers the apex DNSKEY
       RRset, and that the combination of the RRSIG RR and the initial
       DNSKEY RR authenticates the DNSKEY RRset.  The process for using
       an RRSIG RR to authenticate an RRset is described in Section 5.3.

   Once the resolver has authenticated the apex DNSKEY RRset by using an
   initial DNSKEY RR, delegations from that zone can be authenticated by
   using DS RRs.  This allows a resolver to start from an initial key
   and use DS RRsets to proceed recursively down the DNS tree, obtaining
   other apex DNSKEY RRsets.  If the resolver were configured with a
   root DNSKEY RR, and if every delegation had a DS RR associated with
   it, then the resolver could obtain and validate any apex DNSKEY
   RRset.  The process of using DS RRs to authenticate referrals is
   described in Section 5.2.

   Section 5.3 shows how the resolver can use DNSKEY RRs in the apex
   DNSKEY RRset and RRSIG RRs from the zone to authenticate any other
   RRsets in the zone once the resolver has authenticated a zone's apex
   DNSKEY RRset.  Section 5.4 shows how the resolver can use
   authenticated NSEC RRsets from the zone to prove that an RRset is not
   present in the zone.

   When a resolver indicates support for DNSSEC (by setting the DO bit),
   a security-aware name server should attempt to provide the necessary
   DNSKEY, RRSIG, NSEC, and DS RRsets in a response (see Section 3).
   However, a security-aware resolver may still receive a response that
   lacks the appropriate DNSSEC RRs, whether due to configuration issues
   such as an upstream security-oblivious recursive name server that



Arends, et al.              Standards Track                    [Page 25]

RFC 4035             DNSSEC Protocol Modifications            March 2005


   accidentally interferes with DNSSEC RRs or due to a deliberate attack
   in which an adversary forges a response, strips DNSSEC RRs from a
   response, or modifies a query so that DNSSEC RRs appear not to be
   requested.  The absence of DNSSEC data in a response MUST NOT by
   itself be taken as an indication that no authentication information
   exists.

   A resolver SHOULD expect authentication information from signed
   zones.  A resolver SHOULD believe that a zone is signed if the
   resolver has been configured with public key information for the
   zone, or if the zone's parent is signed and the delegation from the
   parent contains a DS RRset.

5.1.  Special Considerations for Islands of Security

   Islands of security (see [RFC4033]) are signed zones for which it is
   not possible to construct an authentication chain to the zone from
   its parent.  Validating signatures within an island of security
   requires that the validator have some other means of obtaining an
   initial authenticated zone key for the island.  If a validator cannot
   obtain such a key, it SHOULD switch to operating as if the zones in
   the island of security are unsigned.

   All the normal processes for validating responses apply to islands of
   security.  The only difference between normal validation and
   validation within an island of security is in how the validator
   obtains a trust anchor for the authentication chain.

5.2.  Authenticating Referrals

   Once the apex DNSKEY RRset for a signed parent zone has been
   authenticated, DS RRsets can be used to authenticate the delegation
   to a signed child zone.  A DS RR identifies a DNSKEY RR in the child
   zone's apex DNSKEY RRset and contains a cryptographic digest of the
   child zone's DNSKEY RR.  Use of a strong cryptographic digest
   algorithm ensures that it is computationally infeasibl