rfc4033.txt

非常好的dns解析软件

      a starting point for building the authentication chain to a signed
      DNS response.  In general, a validating resolver will have to
      obtain the initial values of its trust anchors via some secure or
      trusted means outside the DNS protocol.  Presence of a trust
      anchor also implies that the resolver should expect the zone to
      which the trust anchor points to be signed.

   Unsigned Zone: A zone that is not signed.

   Validating Security-Aware Stub Resolver: A security-aware resolver
      that sends queries in recursive mode but that performs signature
      validation on its own rather than just blindly trusting an
      upstream security-aware recursive name server.  See also
      security-aware stub resolver, non-validating security-aware stub
      resolver.

   Validating Stub Resolver: A less tedious term for a validating
      security-aware stub resolver.

   Zone Apex: Term used to describe the name at the child's side of a
      zone cut.  See also delegation point.

   Zone Signing Key (ZSK): An authentication key that corresponds to a
      private key used to sign a zone.  Typically, a zone signing key
      will be part of the same DNSKEY RRset as the key signing key whose
      corresponding private key signs this DNSKEY RRset, but the zone
      signing key is used for a slightly different purpose and may
      differ from the key signing key in other ways, such as validity
      lifetime.  Designating an authentication key as a zone signing key
      is purely an operational issue; DNSSEC validation does not
      distinguish between zone signing keys and other DNSSEC
      authentication keys, and it is possible to use a single key as
      both a key signing key and a zone signing key.  See also key
      signing key.








Arends, et al.              Standards Track                     [Page 6]

RFC 4033       DNS Security Introduction and Requirements     March 2005


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: Resource Record Signature (RRSIG),
   DNS Public Key (DNSKEY), Delegation Signer (DS), and Next Secure
   (NSEC).  It also adds two new message header bits: Checking Disabled
   (CD) and Authenticated Data (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 DNSSEC OK (DO) EDNS header 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 [RFC3833].  Please see Section 12 for a
   discussion of the limitations of these extensions.

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 discover a public key reliably via DNS
   resolution, the target key itself has to be signed by either a
   configured authentication key or another key that has been



Arends, et al.              Standards Track                     [Page 7]

RFC 4033       DNS Security Introduction and Requirements     March 2005


   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,
   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 trust anchor 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
   configured trust anchor is the hash of a key rather than the key
   itself, the resolver may have 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 that 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, 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.




Arends, et al.              Standards Track                     [Page 8]

RFC 4033       DNS Security Introduction and Requirements     March 2005


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
   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
   with 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 and list
   the types of RRsets present at existing names.  Each NSEC record is
   signed and authenticated using the mechanisms described in Section
   3.1.

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
   ([RFC2136], [RFC3007]).  Message authentication schemes described in
   [RFC2845] and [RFC2931] address security operations that pertain to
   these transactions.

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 the following 4 states:

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



Arends, et al.              Standards Track                     [Page 9]

RFC 4033       DNS Security Introduction and Requirements     March 2005


   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.  This indicates that subsequent
      branches in the tree are provably insecure.  A validating resolver
      may have a local policy to mark parts of the domain space as
      insecure.

   Bogus: The validating resolver has a trust anchor and a secure
      delegation indicating that subsidiary data is signed, but the
      response fails to validate for some reason: missing signatures,
      expired signatures, signatures with unsupported algorithms, data
      missing that the relevant NSEC RR says should be present, and so
      forth.

   Indeterminate: There is no trust anchor that 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 [RFC4035]).

   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 [RFC4035]).

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

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

6.  Resolver Considerations

   A security-aware resolver has to be able to perform cryptographic
   functions necessary to verify digital signatures using at least the
   mandatory-to-implement algorithm(s).  Security-aware resolvers must
   also be capable of forming an authentication chain from a newly
   learned zone back to an authentication key, as described above.  This
   process might require additional queries to intermediate DNS zones to



Arends, et al.              Standards Track                    [Page 10]

RFC 4033       DNS Security Introduction and Requirements     March 2005


   obtain necessary DNSKEY, DS, and RRSIG records.  A security-aware
   resolver should be configured with at least one trust anchor as the
   starting point from which it will attempt to establish authentication
   chains.

   If a security-aware resolver is separated from the relevant
   authoritative name servers by a recursive name server or by any sort
   of intermediary device that acts as a proxy for DNS, and if the
   recursive name server or intermediary device is not security-aware,
   the security-aware resolver may not be capable of operating in a
   secure mode.  For example, if a security-aware resolver's packets are
   routed through a network address translation (NAT) device that
   includes a DNS proxy that is not security-aware, the security-aware
   resolver may find it difficult or impossible to obtain or validate
   signed DNS data.  The security-aware resolver may have a particularly
   difficult time obtaining DS RRs in such a case, as DS RRs do not
   follow the usual DNS rules for ownership of RRs at zone cuts.  Note
   that this problem is not specific to NATs: any security-oblivious DNS
   software of any kind between the security-aware resolver and the
   authoritative name servers will interfere with DNSSEC.

   If a security-aware resolver must rely on an unsigned zone or a name
   server that is not security aware, the resolver may not be able to
   validate DNS responses and will need a local policy on whether to