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

bind 9.3结合mysql数据库

DNS Extensions                                                 R. Arends
Internet-Draft                                      Telematica Instituut
Expires: January 13, 2005                                     R. Austein
                                                                     ISC
                                                               M. Larson
                                                                VeriSign
                                                               D. Massey
                                                                 USC/ISI
                                                                 S. Rose
                                                                    NIST
                                                           July 15, 2004


               DNS Security Introduction and Requirements
                   draft-ietf-dnsext-dnssec-intro-11

Status of this Memo

   By submitting this Internet-Draft, I certify that any applicable
   patent or other IPR claims of which I am aware have been disclosed,
   and any of which I become aware will be disclosed, in accordance with
   RFC 3668.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as
   Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on January 13, 2005.

Copyright Notice

   Copyright (C) The Internet Society (2004).  All Rights Reserved.

Abstract

   The Domain Name System Security Extensions (DNSSEC) add data origin
   authentication and data integrity to the Domain Name System.  This



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


   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
   group of documents that collectively describe DNSSEC.

Table of Contents

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





















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


1.  Introduction

   This document introduces the Domain Name System Security Extensions
   (DNSSEC).  This document and its two companion documents
   ([I-D.ietf-dnsext-dnssec-records] and
   [I-D.ietf-dnsext-dnssec-protocol]) update, clarify, and refine the
   security extensions defined in RFC 2535 [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.  Section 3 and Section 4 describe
   the capabilities and limitations of the security extensions in
   greater detail.  Section 5 discusses the scope of the document set.
   Section 6, Section 7, Section 8, and Section 9 discuss the effect
   that these security extensions will have on resolvers, stub
   resolvers, zones and name servers.

   This document and its two companions update and obsolete RFCs 2535
   [RFC2535], 3008 [RFC3008], 3090 [RFC3090], 3445 [RFC3445], 3655
   [RFC3655], 3658 [RFC3658], 3755 [RFC3755], and the Work in Progress
   [I-D.ietf-dnsext-nsec-rdata].  This document set also updates, but
   does not obsolete, RFCs 1034 [RFC1034], 1035 [RFC1035], 2136
   [RFC2136], 2181 [RFC2181], 2308 [RFC2308], 3597 [RFC3597], and parts
   of 3226 [RFC3226] (dealing with DNSSEC).

   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.






















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


2.  Definitions of Important DNSSEC Terms

   This section defines a number of terms used in this document set.
   Since 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, then come back to
   this section.

   Authentication Chain: An alternating sequence of DNSKEY RRsets and 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." as well as 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 which 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.

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





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


   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
      [I-D.ietf-dnsext-dnssec-records]).  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 which will sign other zone data.  Local
      policy may require the zone signing key to 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.

   Non-Validating Security-Aware Stub Resolver: A security-aware stub
      resolver which 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 which sends DNS queries, receives DNS
      responses, and is capable of establishing an appropriately secured
      channel to a security-aware recursive name server which 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 which
      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.



Arends, et al.          Expires January 13, 2005                [Page 5]


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

   Security-Aware Resolver: An entity acting in the role of a resolver
      (defined in section 2.4 of [RFC1034]) which understands the DNS
      security extensions defined in this document set.  In particular,
      a security-aware resolver is an entity which 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]) which 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.

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

   Signed Zone: A zone whose RRsets are signed and which contains
      properly constructed DNSKEY, RRSIG, 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
      a starting point for building the authentication chain to a signed
      DNS response.  In general, a validating resolver will need 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 which 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.





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


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

   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.