draft-ietf-dnsext-dnssec-intro-11.txt

bind 9.3结合mysql数据库

Arends, et al.          Expires January 13, 2005                [Page 7]

Internet-Draft    DNSSEC Introduction and Requirements         July 2004


3.  Services Provided by DNS Security

   The Domain Name System (DNS) security extensions provide origin
   authentication and integrity assurance services for DNS data,
   including mechanisms for authenticated denial of existence of DNS
   data.  These mechanisms are described below.

   These mechanisms require changes to the DNS protocol.  DNSSEC adds
   four new resource record types (RRSIG, DNSKEY, DS and NSEC) and two
   new message header bits (CD and AD).  In order to support the larger
   DNS message sizes that result from adding the DNSSEC RRs, DNSSEC also
   requires EDNS0 support [RFC2671].  Finally, DNSSEC requires support
   for the DO bit [RFC3225], so that a security-aware resolver can
   indicate in its queries that it wishes to receive DNSSEC RRs in
   response messages.

   These services protect against most of the threats to the Domain Name
   System described in [I-D.ietf-dnsext-dns-threats].

3.1  Data Origin Authentication and Data Integrity

   DNSSEC provides authentication by associating cryptographically
   generated digital signatures with DNS RRsets.  These digital
   signatures are stored in a new resource record, the RRSIG record.
   Typically, there will be a single private key that signs a zone's
   data, but multiple keys are possible: for example, there may be keys
   for each of several different digital signature algorithms.  If a
   security-aware resolver reliably learns a zone's public key, it can
   authenticate that zone's signed data.  An important DNSSEC concept is
   that the key that signs a zone's data is associated with the zone
   itself and not with the zone's authoritative name servers (public
   keys for DNS transaction authentication mechanisms may also appear in
   zones, as described in [RFC2931], but DNSSEC itself is concerned with
   object security of DNS data, not channel security of DNS
   transactions.  The keys associated with transaction security may be
   stored in different RR types.  See [RFC3755] for details.).

   A security-aware resolver can learn a zone's public key either by
   having a trust anchor configured into the resolver or by normal DNS
   resolution.  To allow the latter, public keys are stored in a new
   type of resource record, the DNSKEY RR.  Note that the private keys
   used to sign zone data must be kept secure, and should be stored
   offline when practical to do so.  To discover a public key reliably
   via DNS resolution, the target key itself needs to be signed by
   either a configured authentication key or another key that has been
   authenticated previously.  Security-aware resolvers authenticate zone
   information by forming an authentication chain from a newly learned
   public key back to a previously known authentication public key,



Arends, et al.          Expires January 13, 2005                [Page 8]

Internet-Draft    DNSSEC Introduction and Requirements         July 2004


   which in turn either has been configured into the resolver or must
   have been learned and verified previously.  Therefore, the resolver
   must be configured with at least one trust anchor.  If the configured
   key is a zone signing key, then it will authenticate the associated
   zone; if the configured key is a key signing key, it will
   authenticate a zone signing key.  If the resolver has been configured
   with the hash of a key rather than the key itself, the resolver may
   need to obtain the key via a DNS query.  To help security-aware
   resolvers establish this authentication chain, security-aware name
   servers attempt to send the signature(s) needed to authenticate a
   zone's public key(s) in the DNS reply message along with the public
   key itself, provided there is space available in the message.

   The Delegation Signer (DS) RR type simplifies some of the
   administrative tasks involved in signing delegations across
   organizational boundaries.  The DS RRset resides at a delegation
   point in a parent zone and indicates the public key(s) corresponding
   to the private key(s) used to self-sign the DNSKEY RRset at the
   delegated child zone's apex.  The administrator of the child zone, in
   turn, uses the private key(s) corresponding to one or more of the
   public keys in this DNSKEY RRset to sign the child zone's data.  The
   typical authentication chain is therefore
   DNSKEY->[DS->DNSKEY]*->RRset, where "*" denotes zero or more
   DS->DNSKEY subchains.  DNSSEC permits more complex authentication
   chains, such as additional layers of DNSKEY RRs signing other DNSKEY
   RRs within a zone.

   A security-aware resolver normally constructs this authentication
   chain from the root of the DNS hierarchy down to the leaf zones based
   on configured knowledge of the public key for the root.  Local
   policy, however, may also allow a security-aware resolver to use one
   or more configured public keys (or hashes of public keys) other than
   the root public key, or may not provide configured knowledge of the
   root public key, or may prevent the resolver from using particular
   public keys for arbitrary reasons even if those public keys are
   properly signed with verifiable signatures.  DNSSEC provides
   mechanisms by which a security-aware resolver can determine whether
   an RRset's signature is "valid" within the meaning of DNSSEC.  In the
   final analysis however, authenticating both DNS keys and data is a
   matter of local policy, which may extend or even override the
   protocol extensions defined in this document set.  See Section 5 for
   further discussion.

3.2  Authenticating Name and Type Non-Existence

   The security mechanism described in Section 3.1 only provides a way
   to sign existing RRsets in a zone.  The problem of providing negative
   responses with the same level of authentication and integrity



Arends, et al.          Expires January 13, 2005                [Page 9]

Internet-Draft    DNSSEC Introduction and Requirements         July 2004


   requires the use of another new resource record type, the NSEC
   record.  The NSEC record allows a security-aware resolver to
   authenticate a negative reply for either name or type non-existence
   via the same mechanisms used to authenticate other DNS replies.  Use
   of NSEC records requires a canonical representation and ordering for
   domain names in zones.  Chains of NSEC records explicitly describe
   the gaps, or "empty space", between domain names in a zone, as well
   as listing the types of RRsets present at existing names.  Each NSEC
   record is signed and authenticated using the mechanisms described in
   Section 3.1.









































Arends, et al.          Expires January 13, 2005               [Page 10]

Internet-Draft    DNSSEC Introduction and Requirements         July 2004


4.  Services Not Provided by DNS Security

   DNS was originally designed with the assumptions that the DNS will
   return the same answer to any given query regardless of who may have
   issued the query, and that all data in the DNS is thus visible.
   Accordingly, DNSSEC is not designed to provide confidentiality,
   access control lists, or other means of differentiating between
   inquirers.

   DNSSEC provides no protection against denial of service attacks.
   Security-aware resolvers and security-aware name servers are
   vulnerable to an additional class of denial of service attacks based
   on cryptographic operations.  Please see Section 12 for details.

   The DNS security extensions provide data and origin authentication
   for DNS data.  The mechanisms outlined above are not designed to
   protect operations such as zone transfers and dynamic update
   [RFC3007].  Message authentication schemes described in [RFC2845] and
   [RFC2931] address security operations that pertain to these
   transactions.































Arends, et al.          Expires January 13, 2005               [Page 11]

Internet-Draft    DNSSEC Introduction and Requirements         July 2004


5.  Scope of the DNSSEC Document Set and Last Hop Issues

   The specification in this document set defines the behavior for zone
   signers and security-aware name servers and resolvers in such a way
   that the validating entities can unambiguously determine the state of
   the data.

   A validating resolver can determine these 4 states:

   Secure: The validating resolver has a trust anchor, a chain of trust
      and is able to verify all the signatures in the response.

   Insecure: The validating resolver has a trust anchor, a chain of
      trust, and, at some delegation point, signed proof of the
      non-existence of a DS record.  That indicates that subsequent
      branches in the tree are provably insecure.  A validating resolver
      may have local policy to mark parts of the domain space as
      insecure.

   Bogus: The validating resolver has a trust anchor and there is a
      secure delegation which is indicating that subsidiary data will be
      signed, but the response fails to validate due to one or more
      reasons: missing signatures, expired signatures, signatures with
      unsupported algorithms, data missing which the relevant NSEC RR
      says should be present, and so forth.

   Indeterminate: There is no trust anchor which would indicate that a
      specific portion of the tree is secure.  This is the default
      operation mode.

   This specification only defines how security aware name servers can
   signal non-validating stub resolvers that data was found to be bogus
   (using RCODE=2, "Server Failure" -- see
   [I-D.ietf-dnsext-dnssec-protocol]).

   There is a mechanism for security aware name servers to signal
   security-aware stub resolvers that data was found to be secure (using
   the AD bit, see [I-D.ietf-dnsext-dnssec-protocol]).

   This specification does not define a format for communicating why
   responses were found to be bogus or marked as insecure.  The current
   signaling mechanism does not distinguish between indeterminate and
   insecure.

   A method for signaling advanced error codes and policy between a
   security aware stub resolver and security aware recursive nameservers
   is a topic for future work, as is the interface between a security
   aware resolver and the applications that use it.  Note, however, that



Arends, et al.          Expires January 13, 2005               [Page 12]

Internet-Draft    DNSSEC Introduction and Requirements         July 2004


   the lack of the specification of such communication does not prohibit
   deployment of signed zones or the deployment of security aware
   recursive name servers that prohibit propagation of bogus data to the
   applications.















































Arends, et al.          Expires January 13, 2005               [Page 13]

Internet-Draft    DNSSEC Introduction and Requirements         July 2004