rfc3658.txt

bind 9.3结合mysql数据库

Network Working Group                                     O. Gudmundsson
Request for Comments: 3658                                 December 2003
Updates: 3090, 3008, 2535, 1035
Category: Standards Track


              Delegation Signer (DS) Resource Record (RR)

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 (2003).  All Rights Reserved.

Abstract

   The delegation signer (DS) resource record (RR) is inserted at a zone
   cut (i.e., a delegation point) to indicate that the delegated zone is
   digitally signed and that the delegated zone recognizes the indicated
   key as a valid zone key for the delegated zone.  The DS RR is a
   modification to the DNS Security Extensions definition, motivated by
   operational considerations.  The intent is to use this resource
   record as an explicit statement about the delegation, rather than
   relying on inference.

   This document defines the DS RR, gives examples of how it is used and
   describes the implications on resolvers.  This change is not
   backwards compatible with RFC 2535.  This document updates RFC 1035,
   RFC 2535, RFC 3008 and RFC 3090.
















Gudmundsson                 Standards Track                     [Page 1]

RFC 3658      Delegation Signer (DS) Resource Record (RR)  December 2003


Table of Contents

   1.  Introduction. . . . . . . . . . . . . . . . . . . . . . . . .   3
       1.2.  Reserved Words. . . . . . . . . . . . . . . . . . . . .   4
   2.  Specification of the Delegation key Signer. . . . . . . . . .   4
       2.1.  Delegation Signer Record Model. . . . . . . . . . . . .   4
       2.2.  Protocol Change . . . . . . . . . . . . . . . . . . . .   5
             2.2.1.  RFC 2535 2.3.4 and 3.4: Special Considerations
                     at Delegation Points  . . . . . . . . . . . . .   6
                     2.2.1.1. Special processing for DS queries. . .   6
                     2.2.1.2. Special processing when child and an
                              ancestor share nameserver. . . . . . .   7
                     2.2.1.3. Modification on use of KEY RR in the
                              construction of Responses. . . . . . .   8
             2.2.2.  Signer's Name (replaces RFC3008 section 2.7). .   9
             2.2.3.  Changes to RFC 3090 . . . . . . . . . . . . . .   9
                     2.2.3.1. RFC 3090: Updates to section 1:
                              Introduction . . . . . . . . . . . . .   9
                     2.2.3.2. RFC 3090 section 2.1: Globally
                              Secured. . . . . . . . . . . . . . . .  10
                     2.2.3.3. RFC 3090 section 3: Experimental
                              Status . . . . . . . . . . . . . . . .  10
             2.2.4.  NULL KEY elimination. . . . . . . . . . . . . .  10
       2.3.  Comments on Protocol Changes. . . . . . . . . . . . . .  10
       2.4.  Wire Format of the DS record. . . . . . . . . . . . . .  11
             2.4.1.  Justifications for Fields . . . . . . . . . . .  12
       2.5.  Presentation Format of the DS Record. . . . . . . . . .  12
       2.6.  Transition Issues for Installed Base. . . . . . . . . .  12
             2.6.1.  Backwards compatibility with RFC 2535 and
                     RFC 1035. . . . . . . . . . . . . . . . . . . .  12
       2.7.  KEY and corresponding DS record example . . . . . . . .  13
   3.  Resolver. . . . . . . . . . . . . . . . . . . . . . . . . . .  14
       3.1.  DS Example" . . . . . . . . . . . . . . . . . . . . . .  14
       3.2.  Resolver Cost Estimates for DS Records" . . . . . . . .  15
   4.  Security Considerations . . . . . . . . . . . . . . . . . . .  15
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  16
   6.  Intellectual Property Statement . . . . . . . . . . . . . . .  16
   7.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .  17
   8.  References. . . . . . . . . . . . . . . . . . . . . . . . . .  17
       8.1.  Normative References. . . . . . . . . . . . . . . . . .  17
       8.2.  Informational References. . . . . . . . . . . . . . . .  17
   9.  Author's Address. . . . . . . . . . . . . . . . . . . . . . .  18
   10. Full Copyright Statement. . . . . . . . . . . . . . . . . . .  19








Gudmundsson                 Standards Track                     [Page 2]

RFC 3658      Delegation Signer (DS) Resource Record (RR)  December 2003


1.  Introduction

   Familiarity with the DNS system [RFC1035], DNS security extensions
   [RFC2535], and DNSSEC terminology [RFC3090] is important.

   Experience shows that when the same data can reside in two
   administratively different DNS zones, the data frequently gets out of
   sync.  The presence of an NS RRset in a zone anywhere other than at
   the apex indicates a zone cut or delegation.  The RDATA of the NS
   RRset specifies the authoritative nameservers for the delegated or
   "child" zone.  Based on actual measurements, 10-30% of all
   delegations on the Internet have differing NS RRsets at parent and
   child.  There are a number of reasons for this, including a lack of
   communication between parent and child and bogus name servers being
   listed to meet registry requirements.

   DNSSEC [RFC2535, RFC3008, RFC3090] specifies that a child zone needs
   to have its KEY RRset signed by its parent to create a verifiable
   chain of KEYs.  There has been some debate on where the signed KEY
   RRset should reside, whether at the child [RFC2535] or at the parent.
   If the KEY RRset resides at the child, maintaining the signed KEY
   RRset in the child requires frequent two-way communication between
   the two parties.  First, the child transmits the KEY RRset to the
   parent and then the parent sends the signature(s) to the child.
   Storing the KEY RRset at the parent was thought to simplify the
   communication.

   DNSSEC [RFC2535] requires that the parent store a NULL KEY record for
   an unsecure child zone to indicate that the child is unsecure.  A
   NULL KEY record is a waste: an entire signed RRset is used to
   communicate effectively one bit of information - that the child is
   unsecure. Chasing down NULL KEY RRsets complicates the resolution
   process in many cases, because nameservers for both parent and child
   need to be queried for the KEY RRset if the child nameserver does not
   return it.  Storing the KEY RRset only in the parent zone simplifies
   this and would allow the elimination of the NULL KEY RRsets entirely.
   For large delegation zones, the cost of NULL keys is a significant
   barrier to deployment.

   Prior to the restrictions imposed by RFC 3445 [RFC3445], another
   implication of the DNSSEC key model is that the KEY record could be
   used to store public keys for other protocols in addition to DNSSEC
   keys.  There are a number of potential problems with this, including:

   1. The KEY RRset can become quite large if many applications and
      protocols store their keys at the zone apex.  Possible protocols
      are IPSEC, HTTP, SMTP, SSH and others that use public key
      cryptography.



Gudmundsson                 Standards Track                     [Page 3]

RFC 3658      Delegation Signer (DS) Resource Record (RR)  December 2003


   2. The KEY RRset may require frequent updates.

   3. The probability of compromised or lost keys, which trigger
      emergency key roll-over procedures, increases.

   4. The parent may refuse to sign KEY RRsets with non-DNSSEC zone
      keys.

   5. The parent may not meet the child's expectations of turnaround
      time for resigning the KEY RRset.

   Given these reasons, SIG@parent isn't any better than SIG/KEY@Child.

1.2.  Reserved Words

   The key words "MAY", "MAY NOT", "MUST", "MUST NOT", "REQUIRED",
   "RECOMMENDED", "SHOULD", and "SHOULD NOT" in this document are to be
   interpreted as described in BCP 14, RFC 2119 [RFC2119].

2.  Specification of the Delegation key Signer

   This section defines the Delegation Signer (DS) RR type (type code
   43) and the changes to DNS to accommodate it.

2.1.  Delegation Signer Record Model

   This document presents a replacement for the DNSSEC KEY record chain
   of trust [RFC2535] that uses a new RR that resides only at the
   parent.  This record identifies the key(s) that the child uses to
   self-sign its own KEY RRset.

   Even though DS identifies two roles for KEYs, Key Signing Key (KSK)
   and Zone Signing Key (ZSK), there is no requirement that zone uses
   two different keys for these roles.  It is expected that many small
   zones will only use one key, while larger zones will be more likely
   to use multiple keys.

   The chain of trust is now established by verifying the parent KEY
   RRset, the DS RRset from the parent and the KEY RRset at the child.
   This is cryptographically equivalent to using just KEY records.

   Communication between the parent and child is greatly reduced, since
   the child only needs to notify the parent about changes in keys that
   sign its apex KEY RRset.  The parent is ignorant of all other keys in
   the child's apex KEY RRset.  Furthermore, the child maintains full
   control over the apex KEY RRset and its content.  The child can
   maintain any policies regarding its KEY usage for DNSSEC with minimal
   impact on the parent.  Thus, if the child wants to have frequent key



Gudmundsson                 Standards Track                     [Page 4]

RFC 3658      Delegation Signer (DS) Resource Record (RR)  December 2003


   roll-over for its DNS zone keys, the parent does not need to be aware
   of it.  The child can use one key to sign only its apex KEY RRset and
   a different key to sign the other RRsets in the zone.

   This model fits well with a slow roll out of DNSSEC and the islands
   of security model.  In this model, someone who trusts "good.example."
   can preconfigure a key from "good.example." as a trusted key, and
   from then on trusts any data signed by that key or that has a chain
   of trust to that key.  If "example." starts advertising DS records,
   "good.example." does not have to change operations by suspending
   self-signing.  DS records can be used in configuration files to
   identify trusted keys instead of KEY records.  Another significant
   advantage is that the amount of information stored in large
   delegation zones is reduced: rather than the NULL KEY record at every
   unsecure delegation demanded by RFC 2535, only secure delegations
   require additional information in the form of a signed DS RRset.

   The main disadvantage of this approach is that verifying a zone's KEY
   RRset requires two signature verification operations instead of the
   one in RFC 2535 chain of trust.  There is no impact on the number of
   signatures verified for other types of RRsets.

2.2.  Protocol Change

   All DNS servers and resolvers that support DS MUST support the OK bit
   [RFC3225] and a larger message size [RFC3226].  In order for a
   delegation to be considered secure the delegation MUST contain a DS
   RRset.  If a query contains the OK bit, a nameserver returning a
   referral for the delegation MUST include the following RRsets in the
   authority section in this order:

   If DS RRset is present:
      parent's copy of child's NS RRset
      DS and SIG(DS)

   If no DS RRset is present:
      parent's copy of child's NS RRset
      parent's zone NXT and SIG(NXT)

   This increases the size of referral messages, possibly causing some
   or all glue to be omitted.  If the DS or NXT RRsets with signatures
   do not fit in the DNS message, the TC bit MUST be set.  Additional
   section processing is not changed.

   A DS RRset accompanying a NS RRset indicates that the child zone is
   secure.  If a NS RRset exists without a DS RRset, the child zone is
   unsecure (from the parents point of view).  DS RRsets MUST NOT appear
   at non-delegation points or at a zone's apex.



Gudmundsson                 Standards Track                     [Page 5]

RFC 3658      Delegation Signer (DS) Resource Record (RR)  December 2003


   Section 2.2.1 defines special considerations related to authoritative
   nameservers responding to DS queries and replaces RFC 2535 sections
   2.3.4 and 3.4.  Section 2.2.2 replaces RFC 3008 section 2.7, and
   section 2.2.3 updates RFC 3090.

2.2.1.  RFC 2535 2.3.4 and 3.4: Special Considerations at Delegation
        Points

   DNS security views each zone as a unit of data completely under the
   control of the zone owner with each entry (RRset) signed by a special
   private key held by the zone manager.  But the DNS protocol views the
   leaf nodes in a zone that are also the apex nodes of a child zone
   (i.e., delegation points) as "really" belonging to the child zone.
   The corresponding domain names appear in two master files and might
   have RRsets signed by both the parent and child zones' keys.  A
   retrieval could get a mixture of these RRsets and SIGs, especially
   since one nameserver could be serving both the zone above and below a
   delegation point [RFC2181].

   Each DS RRset stored in the parent zone MUST be signed by at least
   one of the parent zone's private keys.  The parent zone MUST NOT
   contain a KEY RRset at any delegation point.  Delegations in the
   parent MAY contain only the following RR types: NS, DS, NXT and SIG.
   The NS RRset MUST NOT be signed.  The NXT RRset is the exceptional
   case: it will always appear differently and authoritatively in both
   the parent and child zones, if both are secure.

   A secure zone MUST contain a self-signed KEY RRset at its apex.  Upon
   verifying the DS RRset from the parent, a resolver MAY trust any KEY
   identified in the DS RRset as a valid signer of the child's apex KEY
   RRset.  Resolvers configured to trust one of the keys signing the KEY
   RRset MAY now treat any data signed by the zone keys in the KEY RRset
   as secure.  In all other cases, resolvers MUST consider the zone
   unsecure.

   An authoritative nameserver queried for type DS MUST return the DS
   RRset in the answer section.

2.2.1.1.  Special processing for DS queries

   When a nameserver is authoritative for the parent zone at a
   delegation point and receives a query for the DS record at that name,
   it MUST answer based on data in the parent zone, return DS or
   negative answer.  This is true whether or not it is also
   authoritative for the child zone.






Gudmundsson                 Standards Track                     [Page 6]

RFC 3658      Delegation Signer (DS) Resource Record (RR)  December 2003


   When the nameserver is authoritative for the child zone at a
   delegation point but not the parent zone, there is no natural
   response, since the child zone is not authoritative for the DS record
   at the zone's apex.  As these queries are only expected to originate
   from recursive nameservers which are not DS-aware, the authoritative
   nameserver MUST answer with:

      RCODE:             NOERROR
      AA bit:            set
      Answer Section:    Empty
      Authority Section: SOA [+ SIG(SOA) + NXT + SIG(NXT)]

   That is, it answers as if it is authoritative and the DS record does
   not exist.  DS-aware recursive nameservers will query the parent zone