rfc4035.txt

非常好的dns解析软件

   RRSIG RRs appear in both the parent and child zones at a zone cut and
   are authoritative in whichever zone contains the authoritative RRset
   for which the RRSIG RR provides the signature.  That is, the RRSIG RR
   for a DS RRset or a parental NSEC RR at a zone cut will be
   authoritative in the parent zone, and the RRSIG for any RRset in the
   child zone's apex will be authoritative in the child zone.  Parental
   and child RRSIG RRs at a zone cut will never be identical to each
   other, as the Signer's Name field of an RRSIG RR in the child zone's
   apex will indicate a DNSKEY RR in the child zone's apex whereas the
   same field of a parental RRSIG RR at the zone cut will indicate a
   DNSKEY RR in the parent zone's apex.  As with any other authoritative
   RRs, RRSIG RRs MUST be included in zone transfers of the zone in
   which they are authoritative data.

3.1.6.  The AD and CD Bits in an Authoritative Response

   The CD and AD bits are designed for use in communication between
   security-aware resolvers and security-aware recursive name servers.
   These bits are for the most part not relevant to query processing by
   security-aware authoritative name servers.

   A security-aware name server does not perform signature validation
   for authoritative data during query processing, even when the CD bit
   is clear.  A security-aware name server SHOULD clear the CD bit when
   composing an authoritative response.





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


   A security-aware name server MUST NOT set the AD bit in a response
   unless the name server considers all RRsets in the Answer and
   Authority sections of the response to be authentic.  A security-aware
   name server's local policy MAY consider data from an authoritative
   zone to be authentic without further validation.  However, the name
   server MUST NOT do so unless the name server obtained the
   authoritative zone via secure means (such as a secure zone transfer
   mechanism) and MUST NOT do so unless this behavior has been
   configured explicitly.

   A security-aware name server that supports recursion MUST follow the
   rules for the CD and AD bits given in Section 3.2 when generating a
   response that involves data obtained via recursion.

3.2.  Recursive Name Servers

   As explained in [RFC4033], a security-aware recursive name server is
   an entity that acts in both the security-aware name server and
   security-aware resolver roles.  This section uses the terms "name
   server side" and "resolver side" to refer to the code within a
   security-aware recursive name server that implements the
   security-aware name server role and the code that implements the
   security-aware resolver role, respectively.

   The resolver side follows the usual rules for caching and negative
   caching that would apply to any security-aware resolver.

3.2.1.  The DO Bit

   The resolver side of a security-aware recursive name server MUST set
   the DO bit when sending requests, regardless of the state of the DO
   bit in the initiating request received by the name server side.  If
   the DO bit in an initiating query is not set, the name server side
   MUST strip any authenticating DNSSEC RRs from the response but MUST
   NOT strip any DNSSEC RR types that the initiating query explicitly
   requested.

3.2.2.  The CD Bit

   The CD bit exists in order to allow a security-aware resolver to
   disable signature validation in a security-aware name server's
   processing of a particular query.

   The name server side MUST copy the setting of the CD bit from a query
   to the corresponding response.

   The name server side of a security-aware recursive name server MUST
   pass the state of the CD bit to the resolver side along with the rest



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


   of an initiating query, so that the resolver side will know whether
   it is required to verify the response data it returns to the name
   server side.  If the CD bit is set, it indicates that the originating
   resolver is willing to perform whatever authentication its local
   policy requires.  Thus, the resolver side of the recursive name
   server need not perform authentication on the RRsets in the response.
   When the CD bit is set, the recursive name server SHOULD, if
   possible, return the requested data to the originating resolver, even
   if the recursive name server's local authentication policy would
   reject the records in question.  That is, by setting the CD bit, the
   originating resolver has indicated that it takes responsibility for
   performing its own authentication, and the recursive name server
   should not interfere.

   If the resolver side implements a BAD cache (see Section 4.7) and the
   name server side receives a query that matches an entry in the
   resolver side's BAD cache, the name server side's response depends on
   the state of the CD bit in the original query.  If the CD bit is set,
   the name server side SHOULD return the data from the BAD cache; if
   the CD bit is not set, the name server side MUST return RCODE 2
   (server failure).

   The intent of the above rule is to provide the raw data to clients
   that are capable of performing their own signature verification
   checks while protecting clients that depend on the resolver side of a
   security-aware recursive name server to perform such checks.  Several
   of the possible reasons why signature validation might fail involve
   conditions that may not apply equally to the recursive name server
   and the client that invoked it.  For example, the recursive name
   server's clock may be set incorrectly, or the client may have
   knowledge of a relevant island of security that the recursive name
   server does not share.  In such cases, "protecting" a client that is
   capable of performing its own signature validation from ever seeing
   the "bad" data does not help the client.

3.2.3.  The AD Bit

   The name server side of a security-aware recursive name server MUST
   NOT set the AD bit in a response unless the name server considers all
   RRsets in the Answer and Authority sections of the response to be
   authentic.  The name server side SHOULD set the AD bit if and only if
   the resolver side considers all RRsets in the Answer section and any
   relevant negative response RRs in the Authority section to be
   authentic.  The resolver side MUST follow the procedure described in
   Section 5 to determine whether the RRs in question are authentic.
   However, for backward compatibility, a recursive name server MAY set
   the AD bit when a response includes unsigned CNAME RRs if those CNAME




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


   RRs demonstrably could have been synthesized from an authentic DNAME
   RR that is also included in the response according to the synthesis
   rules described in [RFC2672].

3.3.  Example DNSSEC Responses

   See Appendix B for example response packets.

4.  Resolving

   This section describes the behavior of entities that include
   security-aware resolver functions.  In many cases such functions will
   be part of a security-aware recursive name server, but a stand-alone
   security-aware resolver has many of the same requirements.  Functions
   specific to security-aware recursive name servers are described in
   Section 3.2.

4.1.  EDNS Support

   A security-aware resolver MUST include an EDNS ([RFC2671]) OPT
   pseudo-RR with the DO ([RFC3225]) bit set when sending queries.

   A security-aware resolver MUST support a message size of at least
   1220 octets, SHOULD support a message size of 4000 octets, and MUST
   use the "sender's UDP payload size" field in the EDNS OPT pseudo-RR
   to advertise the message size that it is willing to accept.  A
   security-aware resolver's IP layer MUST handle fragmented UDP packets
   correctly regardless of whether any such fragmented packets were
   received via IPv4 or IPv6.  Please see [RFC1122], [RFC2460], and
   [RFC3226] for discussion of these requirements.

4.2.  Signature Verification Support

   A security-aware resolver MUST support the signature verification
   mechanisms described in Section 5 and SHOULD apply them to every
   received response, except when:

   o  the security-aware resolver is part of a security-aware recursive
      name server, and the response is the result of recursion on behalf
      of a query received with the CD bit set;

   o  the response is the result of a query generated directly via some
      form of application interface that instructed the security-aware
      resolver not to perform validation for this query; or

   o  validation for this query has been disabled by local policy.





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


   A security-aware resolver's support for signature verification MUST
   include support for verification of wildcard owner names.

   Security-aware resolvers MAY query for missing security RRs in an
   attempt to perform validation; implementations that choose to do so
   must be aware that the answers received may not be sufficient to
   validate the original response.  For example, a zone update may have
   changed (or deleted) the desired information between the original and
   follow-up queries.

   When attempting to retrieve missing NSEC RRs that reside on the
   parental side at a zone cut, a security-aware iterative-mode resolver
   MUST query the name servers for the parent zone, not the child zone.

   When attempting to retrieve a missing DS, a security-aware
   iterative-mode resolver MUST query the name servers for the parent
   zone, not the child zone.  As explained in Section 3.1.4.1,
   security-aware name servers need to apply special processing rules to
   handle the DS RR, and in some situations the resolver may also need
   to apply special rules to locate the name servers for the parent zone
   if the resolver does not already have the parent's NS RRset.  To
   locate the parent NS RRset, the resolver can start with the
   delegation name, strip off the leftmost label, and query for an NS
   RRset by that name.  If no NS RRset is present at that name, the
   resolver then strips off the leftmost remaining label and retries the
   query for that name, repeating this process of walking up the tree
   until it either finds the NS RRset or runs out of labels.

4.3.  Determining Security Status of Data

   A security-aware resolver MUST be able to determine whether it should
   expect a particular RRset to be signed.  More precisely, a
   security-aware resolver must be able to distinguish between four
   cases:

   Secure: An RRset for which the resolver is able to build a chain of
      signed DNSKEY and DS RRs from a trusted security anchor to the
      RRset.  In this case, the RRset should be signed and is subject to
      signature validation, as described above.

   Insecure: An RRset for which the resolver knows that it has no chain
      of signed DNSKEY and DS RRs from any trusted starting point to the
      RRset.  This can occur when the target RRset lies in an unsigned
      zone or in a descendent of an unsigned zone.  In this case, the
      RRset may or may not be signed, but the resolver will not be able
      to verify the signature.





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


   Bogus: An RRset for which the resolver believes that it ought to be
      able to establish a chain of trust but for which it is unable to
      do so, either due to signatures that for some reason fail to
      validate or due to missing data that the relevant DNSSEC RRs
      indicate should be present.  This case may indicate an attack but
      may also indicate a configuration error or some form of data
      corruption.

   Indeterminate: An RRset for which the resolver is not able to
      determine whether the RRset should be signed, as the resolver is
      not able to obtain the necessary DNSSEC RRs.  This can occur when
      the security-aware resolver is not able to contact security-aware
      name servers for the relevant zones.

4.4.  Configured Trust Anchors

   A security-aware resolver MUST be capable of being configured with at
   least one trusted public key or DS RR and SHOULD be capable of being
   configured with multiple trusted public keys or DS RRs.  Since a
   security-aware resolver will not be able to validate signatures
   without such a configured trust anchor, the resolver SHOULD have some
   reasonably robust mechanism for obtaining such keys when it boots;
   examples of such a mechanism would be some form of non-volatile
   storage (such as a disk drive) or some form of trusted local network
   configuration mechanism.

   Note that trust anchors also cover key material that is updated in a
   secure manner.  This secure manner could be through physical media, a
   key exchange protocol, or some other out-of-band means.