rfc4033.txt

非常好的dns解析软件

Network Working Group                                          R. Arends
Request for Comments: 4033                          Telematica Instituut
Obsoletes: 2535, 3008, 3090, 3445, 3655, 3658,                R. Austein
           3755, 3757, 3845                                          ISC
Updates: 1034, 1035, 2136, 2181, 2308, 3225,                   M. Larson
         3007, 3597, 3226                                       VeriSign
Category: Standards Track                                      D. Massey
                                               Colorado State University
                                                                 S. Rose
                                                                    NIST
                                                              March 2005


               DNS Security Introduction and Requirements

Status of This Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2005).

Abstract

   The Domain Name System Security Extensions (DNSSEC) add data origin
   authentication and data integrity to the Domain Name System.  This
   document introduces these extensions and describes their capabilities
   and limitations.  This document also discusses the services that the
   DNS security extensions do and do not provide.  Last, this document
   describes the interrelationships between the documents that
   collectively describe DNSSEC.















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


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Definitions of Important DNSSEC Terms  . . . . . . . . . . .   3
   3.  Services Provided by DNS Security  . . . . . . . . . . . . .   7
       3.1.  Data Origin Authentication and Data Integrity  . . . .   7
       3.2.  Authenticating Name and Type Non-Existence . . . . . .   9
   4.  Services Not Provided by DNS Security  . . . . . . . . . . .   9
   5.  Scope of the DNSSEC Document Set and Last Hop Issues . . . .   9
   6.  Resolver Considerations  . . . . . . . . . . . . . . . . . .  10
   7.  Stub Resolver Considerations . . . . . . . . . . . . . . . .  11
   8.  Zone Considerations  . . . . . . . . . . . . . . . . . . . .  12
       8.1.  TTL Values vs. RRSIG Validity Period . . . . . . . . .  13
       8.2.  New Temporal Dependency Issues for Zones . . . . . . .  13
   9.  Name Server Considerations . . . . . . . . . . . . . . . . .  13
   10. DNS Security Document Family . . . . . . . . . . . . . . . .  14
   11. IANA Considerations  . . . . . . . . . . . . . . . . . . . .  15
   12. Security Considerations  . . . . . . . . . . . . . . . . . .  15
   13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . .  17
   14. References . . . . . . . . . . . . . . . . . . . . . . . . .  17
       14.1. Normative References . . . . . . . . . . . . . . . . .  17
       14.2. Informative References . . . . . . . . . . . . . . . .  18
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . .  20
   Full Copyright Statement . . . . . . . . . . . . . . . . . . . .  21

1.  Introduction

   This document introduces the Domain Name System Security Extensions
   (DNSSEC).  This document and its two companion documents ([RFC4034]
   and [RFC4035]) update, clarify, and refine the security extensions
   defined in [RFC2535] and its predecessors.  These security extensions
   consist of a set of new resource record types and modifications to
   the existing DNS protocol ([RFC1035]).  The new records and protocol
   modifications are not fully described in this document, but are
   described in a family of documents outlined in Section 10.  Sections
   3 and 4 describe the capabilities and limitations of the security
   extensions in greater detail.  Section 5 discusses the scope of the
   document set.  Sections 6, 7, 8, and 9 discuss the effect that these
   security extensions will have on resolvers, stub resolvers, zones,
   and name servers.

   This document and its two companions obsolete [RFC2535], [RFC3008],
   [RFC3090], [RFC3445], [RFC3655], [RFC3658], [RFC3755], [RFC3757], and
   [RFC3845].  This document set also updates but does not obsolete
   [RFC1034], [RFC1035], [RFC2136], [RFC2181], [RFC2308], [RFC3225],
   [RFC3007], [RFC3597], and the portions of [RFC3226] that deal with
   DNSSEC.




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


   The DNS security extensions provide origin authentication and
   integrity protection for DNS data, as well as a means of public key
   distribution.  These extensions do not provide confidentiality.

2.  Definitions of Important DNSSEC Terms

   This section defines a number of terms used in this document set.
   Because this is intended to be useful as a reference while reading
   the rest of the document set, first-time readers may wish to skim
   this section quickly, read the rest of this document, and then come
   back to this section.

   Authentication Chain: An alternating sequence of DNS public key
      (DNSKEY) RRsets and Delegation Signer (DS) RRsets forms a chain of
      signed data, with each link in the chain vouching for the next.  A
      DNSKEY RR is used to verify the signature covering a DS RR and
      allows the DS RR to be authenticated.  The DS RR contains a hash
      of another DNSKEY RR and this new DNSKEY RR is authenticated by
      matching the hash in the DS RR.  This new DNSKEY RR in turn
      authenticates another DNSKEY RRset and, in turn, some DNSKEY RR in
      this set may be used to authenticate another DS RR, and so forth
      until the chain finally ends with a DNSKEY RR whose corresponding
      private key signs the desired DNS data.  For example, the root
      DNSKEY RRset can be used to authenticate the DS RRset for
      "example."  The "example." DS RRset contains a hash that matches
      some "example." DNSKEY, and this DNSKEY's corresponding private
      key signs the "example." DNSKEY RRset.  Private key counterparts
      of the "example." DNSKEY RRset sign data records such as
      "www.example." and DS RRs for delegations such as
      "subzone.example."

   Authentication Key: A public key that a security-aware resolver has
      verified and can therefore use to authenticate data.  A
      security-aware resolver can obtain authentication keys in three
      ways.  First, the resolver is generally configured to know about
      at least one public key; this configured data is usually either
      the public key itself or a hash of the public key as found in the
      DS RR (see "trust anchor").  Second, the resolver may use an
      authenticated public key to verify a DS RR and the DNSKEY RR to
      which the DS RR refers.  Third, the resolver may be able to
      determine that a new public key has been signed by the private key
      corresponding to another public key that the resolver has
      verified.  Note that the resolver must always be guided by local
      policy when deciding whether to authenticate a new public key,
      even if the local policy is simply to authenticate any new public
      key for which the resolver is able verify the signature.





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


   Authoritative RRset: Within the context of a particular zone, an
      RRset is "authoritative" if and only if the owner name of the
      RRset lies within the subset of the name space that is at or below
      the zone apex and at or above the cuts that separate the zone from
      its children, if any.  All RRsets at the zone apex are
      authoritative, except for certain RRsets at this domain name that,
      if present, belong to this zone's parent.  These RRset could
      include a DS RRset, the NSEC RRset referencing this DS RRset (the
      "parental NSEC"), and RRSIG RRs associated with these RRsets, all
      of which are authoritative in the parent zone.  Similarly, if this
      zone contains any delegation points, only the parental NSEC RRset,
      DS RRsets, and any RRSIG RRs associated with these RRsets are
      authoritative for this zone.

   Delegation Point: Term used to describe the name at the parental side
      of a zone cut.  That is, the delegation point for "foo.example"
      would be the foo.example node in the "example" zone (as opposed to
      the zone apex of the "foo.example" zone).  See also zone apex.

   Island of Security: Term used to describe a signed, delegated zone
      that does not have an authentication chain from its delegating
      parent.  That is, there is no DS RR containing a hash of a DNSKEY
      RR for the island in its delegating parent zone (see [RFC4034]).
      An island of security is served by security-aware name servers and
      may provide authentication chains to any delegated child zones.
      Responses from an island of security or its descendents can only
      be authenticated if its authentication keys can be authenticated
      by some trusted means out of band from the DNS protocol.

   Key Signing Key (KSK): An authentication key that corresponds to a
      private key used to sign one or more other authentication keys for
      a given zone.  Typically, the private key corresponding to a key
      signing key will sign a zone signing key, which in turn has a
      corresponding private key that will sign other zone data.  Local
      policy may require that the zone signing key be changed
      frequently, while the key signing key may have a longer validity
      period in order to provide a more stable secure entry point into
      the zone.  Designating an authentication key as a key signing key
      is purely an operational issue: DNSSEC validation does not
      distinguish between key 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.  Key signing keys
      are discussed in more detail in [RFC3757].  Also see zone signing
      key.







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


   Non-Validating Security-Aware Stub Resolver: A security-aware stub
      resolver that trusts one or more security-aware recursive name
      servers to perform most of the tasks discussed in this document
      set on its behalf.  In particular, a non-validating security-aware
      stub resolver is an entity that sends DNS queries, receives DNS
      responses, and is capable of establishing an appropriately secured
      channel to a security-aware recursive name server that will
      provide these services on behalf of the security-aware stub
      resolver.  See also security-aware stub resolver, validating
      security-aware stub resolver.

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

   Security-Aware Name Server: An entity acting in the role of a name
      server (defined in section 2.4 of [RFC1034]) that understands the
      DNS security extensions defined in this document set.  In
      particular, a security-aware name server is an entity that
      receives DNS queries, sends DNS responses, supports the EDNS0
      ([RFC2671]) message size extension and the DO bit ([RFC3225]), and
      supports the RR types and message header bits defined in this
      document set.

   Security-Aware Recursive Name Server: An entity that acts in both the
      security-aware name server and security-aware resolver roles.  A
      more cumbersome but equivalent phrase would be "a security-aware
      name server that offers recursive service".

   Security-Aware Resolver: An entity acting in the role of a resolver
      (defined in section 2.4 of [RFC1034]) that understands the DNS
      security extensions defined in this document set.  In particular,
      a security-aware resolver is an entity that sends DNS queries,
      receives DNS responses, supports the EDNS0 ([RFC2671]) message
      size extension and the DO bit ([RFC3225]), and is capable of using
      the RR types and message header bits defined in this document set
      to provide DNSSEC services.

   Security-Aware Stub Resolver: An entity acting in the role of a stub
      resolver (defined in section 5.3.1 of [RFC1034]) that has enough
      of an understanding the DNS security extensions defined in this
      document set to provide additional services not available from a
      security-oblivious stub resolver.  Security-aware stub resolvers
      may be either "validating" or "non-validating", depending on
      whether the stub resolver attempts to verify DNSSEC signatures on
      its own or trusts a friendly security-aware name server to do so.
      See also validating stub resolver, non-validating stub resolver.





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


   Security-Oblivious <anything>: An <anything> that is not
      "security-aware".

   Signed Zone: A zone whose RRsets are signed and that contains
      properly constructed DNSKEY, Resource Record Signature (RRSIG),
      Next Secure (NSEC), and (optionally) DS records.

   Trust Anchor: A configured DNSKEY RR or DS RR hash of a DNSKEY RR.  A
      validating security-aware resolver uses this public key or hash as