doc: Add RFC documents

1 files changed, 955 insertions, 0 deletions

diff --git a/doc/rfc/rfc4956.txt b/doc/rfc/rfc4956.txt
new file mode 100644
index 0000000..536c680
--- /dev/null
+++ b/doc/rfc/rfc4956.txt
@@ -0,0 +1,955 @@
+
+
+
+
+
+
+Network Working Group                                          R. Arends
+Request for Comments: 4956                                       Nominet
+Category: Experimental                                        M. Kosters
+                                                               D. Blacka
+                                                          VeriSign, Inc.
+                                                               July 2007
+
+
+                      DNS Security (DNSSEC) Opt-In
+
+Status of This Memo
+
+   This memo defines an Experimental Protocol for the Internet
+   community.  It does not specify an Internet standard of any kind.
+   Discussion and suggestions for improvement are requested.
+   Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The IETF Trust (2007).
+
+Abstract
+
+   In the DNS security (DNSSEC) extensions, delegations to unsigned
+   subzones are cryptographically secured.  Maintaining this
+   cryptography is not always practical or necessary.  This document
+   describes an experimental "Opt-In" model that allows administrators
+   to omit this cryptography and manage the cost of adopting DNSSEC with
+   large zones.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Arends, et al.                Experimental                      [Page 1]
+
+RFC 4956              DNS Security (DNSSEC) Opt-In             July 2007
+
+
+Table of Contents
+
+   1.  Overview . . . . . . . . . . . . . . . . . . . . . . . . . . .  3
+   2.  Definitions and Terminology  . . . . . . . . . . . . . . . . .  3
+   3.  Experimental Status  . . . . . . . . . . . . . . . . . . . . .  4
+   4.  Protocol Additions . . . . . . . . . . . . . . . . . . . . . .  5
+     4.1.  Server Considerations  . . . . . . . . . . . . . . . . . .  6
+       4.1.1.  Delegations Only . . . . . . . . . . . . . . . . . . .  6
+       4.1.2.  Insecure Delegation Responses  . . . . . . . . . . . .  6
+       4.1.3.  Dynamic Update . . . . . . . . . . . . . . . . . . . .  6
+     4.2.  Client Considerations  . . . . . . . . . . . . . . . . . .  7
+       4.2.1.  Delegations Only . . . . . . . . . . . . . . . . . . .  7
+       4.2.2.  Validation Process Changes . . . . . . . . . . . . . .  7
+       4.2.3.  NSEC Record Caching  . . . . . . . . . . . . . . . . .  8
+       4.2.4.  Use of the AD bit  . . . . . . . . . . . . . . . . . .  8
+   5.  Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . .  8
+   6.  Example  . . . . . . . . . . . . . . . . . . . . . . . . . . .  9
+   7.  Transition Issues  . . . . . . . . . . . . . . . . . . . . . . 11
+   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 11
+   9.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 13
+   10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
+     10.1. Normative References . . . . . . . . . . . . . . . . . . . 13
+     10.2. Informative References . . . . . . . . . . . . . . . . . . 13
+   Appendix A.  Implementing Opt-In Using "Views" . . . . . . . . . . 15
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Arends, et al.                Experimental                      [Page 2]
+
+RFC 4956              DNS Security (DNSSEC) Opt-In             July 2007
+
+
+1.  Overview
+
+   The cost to cryptographically secure delegations to unsigned zones is
+   high for large delegation-centric zones and zones where insecure
+   delegations will be updated rapidly.  For these zones, the costs of
+   maintaining the NextSECure (NSEC) record chain may be extremely high
+   relative to the gain of cryptographically authenticating existence of
+   unsecured zones.
+
+   This document describes an experimental method of eliminating the
+   superfluous cryptography present in secure delegations to unsigned
+   zones.  Using "Opt-In", a zone administrator can choose to remove
+   insecure delegations from the NSEC chain.  This is accomplished by
+   extending the semantics of the NSEC record by using a redundant bit
+   in the type map.
+
+2.  Definitions and Terminology
+
+   Throughout this document, familiarity with the DNS system (RFC 1035
+   [1]), DNS security extensions ([4], [5], and [6], referred to in this
+   document as "standard DNSSEC"), and DNSSEC terminology (RFC 3090
+   [10]) is assumed.
+
+   The following abbreviations and terms are used in this document:
+
+   RR:  is used to refer to a DNS resource record.
+
+   RRset:  refers to a Resource Record Set, as defined by [8].  In this
+      document, the RRset is also defined to include the covering RRSIG
+      records, if any exist.
+
+   signed name:  refers to a DNS name that has, at minimum, a (signed)
+      NSEC record.
+
+   unsigned name:  refers to a DNS name that does not (at least) have an
+      NSEC record.
+
+   covering NSEC record/RRset:  is the NSEC record used to prove
+      (non)existence of a particular name or RRset.  This means that for
+      a RRset or name 'N', the covering NSEC record has the name 'N', or
+      has an owner name less than 'N' and "next" name greater than 'N'.
+
+   delegation:  refers to an NS RRset with a name different from the
+      current zone apex (non-zone-apex), signifying a delegation to a
+      subzone.
+
+
+
+
+
+
+Arends, et al.                Experimental                      [Page 3]
+
+RFC 4956              DNS Security (DNSSEC) Opt-In             July 2007
+
+
+   secure delegation:  refers to a signed name containing a delegation
+      (NS RRset), and a signed DS RRset, signifying a delegation to a
+      signed subzone.
+
+   insecure delegation:  refers to a signed name containing a delegation
+      (NS RRset), but lacking a DS RRset, signifying a delegation to an
+      unsigned subzone.
+
+   Opt-In insecure delegation:  refers to an unsigned name containing
+      only a delegation NS RRset.  The covering NSEC record uses the
+      Opt-In methodology described in this document.
+
+   The key words "MUST, "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY, and "OPTIONAL" in this
+   document are to be interpreted as described in RFC 2119 [2].
+
+3.  Experimental Status
+
+   This document describes an EXPERIMENTAL extension to DNSSEC.  It
+   interoperates with non-experimental DNSSEC using the technique
+   described in [7].  This experiment is identified with the following
+   private algorithms (using algorithm 253):
+
+   "3.optin.verisignlabs.com":  is an alias for DNSSEC algorithm 3, DSA,
+      and
+
+   "5.optin.verisignlabs.com":  is an alias for DNSSEC algorithm 5,
+      RSASHA1.
+
+   Servers wishing to sign and serve zones that utilize Opt-In MUST sign
+   the zone with only one or more of these private algorithms and MUST
+   NOT use any other algorithms.
+
+   Resolvers MUST NOT apply the Opt-In validation rules described in
+   this document unless a zone is signed using one or more of these
+   private algorithms.
+
+   This experimental protocol relaxes the restriction that validators
+   MUST ignore the setting of the NSEC bit in the type map as specified
+   in RFC 4035 [6] Section 5.4.
+
+   The remainder of this document assumes that the servers and resolvers
+   involved are aware of and are involved in this experiment.
+
+
+
+
+
+
+
+
+Arends, et al.                Experimental                      [Page 4]
+
+RFC 4956              DNS Security (DNSSEC) Opt-In             July 2007
+
+
+4.  Protocol Additions
+
+   In DNSSEC, delegation NS RRsets are not signed, but are instead
+   accompanied by an NSEC RRset of the same name and (possibly) a DS
+   record.  The security status of the subzone is determined by the
+   presence or absence of the DS RRset, cryptographically proven by the
+   NSEC record.  Opt-In expands this definition by allowing insecure
+   delegations to exist within an otherwise signed zone without the
+   corresponding NSEC record at the delegation's owner name.  These
+   insecure delegations are proven insecure by using a covering NSEC
+   record.
+
+   Since this represents a change of the interpretation of NSEC records,
+   resolvers must be able to distinguish between RFC standard DNSSEC
+   NSEC records and Opt-In NSEC records.  This is accomplished by
+   "tagging" the NSEC records that cover (or potentially cover) insecure
+   delegation nodes.  This tag is indicated by the absence of the NSEC
+   bit in the type map.  Since the NSEC bit in the type map merely
+   indicates the existence of the record itself, this bit is redundant
+   and safe for use as a tag.
+
+   An Opt-In tagged NSEC record does not assert the (non)existence of
+   the delegations that it covers (except for a delegation with the same
+   name).  This allows for the addition or removal of these delegations
+   without recalculating or resigning records in the NSEC chain.
+   However, Opt-In tagged NSEC records do assert the (non)existence of
+   other RRsets.
+
+   An Opt-In NSEC record MAY have the same name as an insecure
+   delegation.  In this case, the delegation is proven insecure by the
+   lack of a DS bit in the type map, and the signed NSEC record does
+   assert the existence of the delegation.
+
+   Zones using Opt-In MAY contain a mixture of Opt-In tagged NSEC
+   records and standard DNSSEC NSEC records.  If an NSEC record is not
+   Opt-In, there MUST NOT be any insecure delegations (or any other
+   records) between it and the RRsets indicated by the 'next domain
+   name' in the NSEC RDATA.  If it is Opt-In, there MUST only be
+   insecure delegations between it and the next node indicated by the
+   'next domain name' in the NSEC RDATA.
+
+   In summary,
+
+   o  An Opt-In NSEC type is identified by a zero-valued (or not-
+      specified) NSEC bit in the type bit map of the NSEC record.
+
+
+
+
+
+
+Arends, et al.                Experimental                      [Page 5]
+
+RFC 4956              DNS Security (DNSSEC) Opt-In             July 2007
+
+
+   o  A standard DNSSEC NSEC type is identified by a one-valued NSEC bit
+      in the type bit map of the NSEC record.
+
+   and
+
+   o  An Opt-In NSEC record does not assert the non-existence of a name
+      between its owner name and "next" name, although it does assert
+      that any name in this span MUST be an insecure delegation.
+
+   o  An Opt-In NSEC record does assert the (non)existence of RRsets
+      with the same owner name.
+
+4.1.  Server Considerations
+
+   Opt-In imposes some new requirements on authoritative DNS servers.
+
+4.1.1.  Delegations Only
+
+   This specification dictates that only insecure delegations may exist
+   between the owner and "next" names of an Opt-In tagged NSEC record.
+   Signing tools MUST NOT generate signed zones that violate this
+   restriction.  Servers MUST refuse to load and/or serve zones that
+   violate this restriction.  Servers also MUST reject AXFR or IXFR
+   responses that violate this restriction.
+
+4.1.2.  Insecure Delegation Responses
+
+   When returning an Opt-In insecure delegation, the server MUST return
+   the covering NSEC RRset in the Authority section.
+
+   In standard DNSSEC, NSEC records already must be returned along with
+   the insecure delegation.  The primary difference that this proposal
+   introduces is that the Opt-In tagged NSEC record will have a
+   different owner name from the delegation RRset.  This may require
+   implementations to search for the covering NSEC RRset.
+
+4.1.3.  Dynamic Update
+
+   Opt-In changes the semantics of Secure DNS Dynamic Update [9].  In
+   particular, it introduces the need for rules that describe when to
+   add or remove a delegation name from the NSEC chain.  This document
+   does not attempt to define these rules.  Until these rules are
+   defined, servers MUST NOT process DNS Dynamic Update requests against
+   zones that use Opt-In NSEC records.  Servers SHOULD return responses
+   to update requests with RCODE=REFUSED.
+
+
+
+
+
+
+Arends, et al.                Experimental                      [Page 6]
+
+RFC 4956              DNS Security (DNSSEC) Opt-In             July 2007
+
+
+4.2.  Client Considerations
+
+   Opt-In imposes some new requirements on security-aware resolvers
+   (caching or otherwise).
+
+4.2.1.  Delegations Only
+
+   As stated in Section 4.1 above, this specification restricts the
+   namespace covered by Opt-In tagged NSEC records to insecure
+   delegations only.  Clients are not expected to take any special
+   measures to enforce this restriction; instead, it forms an underlying
+   assumption that clients may rely on.
+
+4.2.2.  Validation Process Changes
+
+   This specification does not change the resolver's resolution
+   algorithm.  However, it does change the DNSSEC validation process.
+
+4.2.2.1.  Referrals
+
+   Resolvers MUST be able to use Opt-In tagged NSEC records to
+   cryptographically prove the validity and security status (as
+   insecure) of a referral.  Resolvers determine the security status of
+   the referred-to zone as follows:
+
+   o  In standard DNSSEC, the security status is proven by the existence
+      or absence of a DS RRset at the same name as the delegation.  The
+      existence of the DS RRset indicates that the referred-to zone is
+      signed.  The absence of the DS RRset is proven using a verified
+      NSEC record of the same name that does not have the DS bit set in
+      the type map.  This NSEC record MAY also be tagged as Opt-In.
+
+   o  Using Opt-In, the security status is proven by the existence of a
+      DS record (for signed) or the presence of a verified Opt-In tagged
+      NSEC record that covers the delegation name.  That is, the NSEC
+      record does not have the NSEC bit set in the type map, and the
+      delegation name falls between the NSEC's owner and "next" name.
+
+   Using Opt-In does not substantially change the nature of following
+   referrals within DNSSEC.  At every delegation point, the resolver
+   will have cryptographic proof that the referred-to subzone is signed
+   or unsigned.
+
+4.2.2.2.  Queries for DS Resource Records
+
+   Since queries for DS records are directed to the parent side of a
+   zone cut (see [5], Section 5), negative responses to these queries
+   may be covered by an Opt-In flagged NSEC record.
+
+
+
+Arends, et al.                Experimental                      [Page 7]
+
+RFC 4956              DNS Security (DNSSEC) Opt-In             July 2007
+
+
+   Resolvers MUST be able to use Opt-In tagged NSEC records to
+   cryptographically prove the validity and security status of negative
+   responses to queries for DS records.  In particular, a NOERROR/NODATA
+   (i.e., RCODE=3, but the answer section is empty) response to a DS
+   query may be proven by an Opt-In flagged covering NSEC record, rather
+   than an NSEC record matching the query name.
+
+4.2.3.  NSEC Record Caching
+
+   Caching resolvers MUST be able to retrieve the appropriate covering
+   Opt-In NSEC record when returning referrals that need them.  This
+   requirement differs from standard DNSSEC in that the covering NSEC
+   will not have the same owner name as the delegation.  Some
+   implementations may have to use new methods for finding these NSEC
+   records.
+
+4.2.4.  Use of the AD bit
+
+   The AD bit, as defined by [3] and [6], MUST NOT be set when:
+
+   o  sending a Name Error (RCODE=3) response where the covering NSEC is
+      tagged as Opt-In.
+
+   o  sending an Opt-In insecure delegation response, unless the
+      covering (Opt-In) NSEC record's owner name equals the delegation
+      name.
+
+   o  sending a NOERROR/NODATA response when query type is DS and the
+      covering NSEC is tagged as Opt-In, unless NSEC record's owner name
+      matches the query name.
+
+   This rule is based on what the Opt-In NSEC record actually proves:
+   for names that exist between the Opt-In NSEC record's owner and
+   "next" names, the Opt-In NSEC record cannot prove the non-existence
+   or existence of the name.  As such, not all data in the response has
+   been cryptographically verified, so the AD bit cannot be set.
+
+5.  Benefits
+
+   Using Opt-In allows administrators of large and/or changing
+   delegation-centric zones to minimize the overhead involved in
+   maintaining the security of the zone.
+
+   Opt-In accomplishes this by eliminating the need for NSEC records for
+   insecure delegations.  This, in a zone with a large number of
+   delegations to unsigned subzones, can lead to substantial space
+   savings (both in memory and on disk).  Additionally, Opt-In allows
+   for the addition or removal of insecure delegations without modifying
+
+
+
+Arends, et al.                Experimental                      [Page 8]
+
+RFC 4956              DNS Security (DNSSEC) Opt-In             July 2007
+
+
+   the NSEC record chain.  Zones that are frequently updating insecure
+   delegations (e.g., Top-Level Domains (TLDs)) can avoid the
+   substantial overhead of modifying and resigning the affected NSEC
+   records.
+
+6.  Example
+
+   Consider the zone EXAMPLE shown below.  This is a zone where all of
+   the NSEC records are tagged as Opt-In.
+
+   Example A: Fully Opt-In Zone.
+
+         EXAMPLE.               SOA    ...
+         EXAMPLE.               RRSIG  SOA ...
+         EXAMPLE.               NS     FIRST-SECURE.EXAMPLE.
+         EXAMPLE.               RRSIG  NS ...
+         EXAMPLE.               DNSKEY ...
+         EXAMPLE.               RRSIG  DNSKEY ...
+         EXAMPLE.               NSEC   FIRST-SECURE.EXAMPLE. (
+                                       SOA NS RRSIG DNSKEY )
+         EXAMPLE.               RRSIG  NSEC ...
+
+         FIRST-SECURE.EXAMPLE.  A      ...
+         FIRST-SECURE.EXAMPLE.  RRSIG  A ...
+         FIRST-SECURE.EXAMPLE.  NSEC   NOT-SECURE-2.EXAMPLE. A RRSIG
+         FIRST-SECURE.EXAMPLE.  RRSIG  NSEC ...
+
+         NOT-SECURE.EXAMPLE.    NS     NS.NOT-SECURE.EXAMPLE.
+         NS.NOT-SECURE.EXAMPLE. A      ...
+
+         NOT-SECURE-2.EXAMPLE.  NS     NS.NOT-SECURE.EXAMPLE.
+         NOT-SECURE-2.EXAMPLE   NSEC   SECOND-SECURE.EXAMPLE NS RRSIG
+         NOT-SECURE-2.EXAMPLE   RRSIG  NSEC ...
+
+         SECOND-SECURE.EXAMPLE. NS     NS.ELSEWHERE.
+         SECOND-SECURE.EXAMPLE. DS     ...
+         SECOND-SECURE.EXAMPLE. RRSIG  DS ...
+         SECOND-SECURE.EXAMPLE. NSEC   EXAMPLE. NS RRSIG DNSKEY
+         SECOND-SECURE.EXAMPLE. RRSIG  NSEC ...
+
+         UNSIGNED.EXAMPLE.      NS     NS.UNSIGNED.EXAMPLE.
+         NS.UNSIGNED.EXAMPLE.   A      ...
+
+
+                                Example A.
+
+
+
+
+
+
+Arends, et al.                Experimental                      [Page 9]
+
+RFC 4956              DNS Security (DNSSEC) Opt-In             July 2007
+
+
+   In this example, a query for a signed RRset (e.g., "FIRST-
+   SECURE.EXAMPLE A") or a secure delegation ("WWW.SECOND-SECURE.EXAMPLE
+   A") will result in a standard DNSSEC response.
+
+   A query for a nonexistent RRset will result in a response that
+   differs from standard DNSSEC by the following: the NSEC record will
+   be tagged as Opt-In, there may be no NSEC record proving the non-
+   existence of a matching wildcard record, and the AD bit will not be
+   set.
+
+   A query for an insecure delegation RRset (or a referral) will return
+   both the answer (in the Authority section) and the corresponding
+   Opt-In NSEC record to prove that it is not secure.
+
+   Example A.1: Response to query for WWW.UNSIGNED.EXAMPLE.  A
+
+
+         RCODE=NOERROR, AD=0
+
+         Answer Section:
+
+         Authority Section:
+         UNSIGNED.EXAMPLE.      NS     NS.UNSIGNED.EXAMPLE
+         SECOND-SECURE.EXAMPLE. NSEC   EXAMPLE. NS RRSIG DS
+         SECOND-SECURE.EXAMPLE. RRSIG  NSEC ...
+
+         Additional Section:
+         NS.UNSIGNED.EXAMPLE.   A      ...
+
+                                Example A.1
+
+   In the Example A.1 zone, the EXAMPLE. node MAY use either style of
+   NSEC record, because there are no insecure delegations that occur
+   between it and the next node, FIRST-SECURE.EXAMPLE.  In other words,
+   Example A would still be a valid zone if the NSEC record for EXAMPLE.
+   was changed to the following RR:
+
+         EXAMPLE.               NSEC   FIRST-SECURE.EXAMPLE. (SOA NS
+                                       RRSIG DNSKEY NSEC )
+
+   However, the other NSEC records (FIRST-SECURE.EXAMPLE. and SECOND-
+   SECURE.EXAMPLE.)  MUST be tagged as Opt-In because there are insecure
+   delegations in the range they define.  (NOT-SECURE.EXAMPLE. and
+   UNSIGNED.EXAMPLE., respectively).
+
+   NOT-SECURE-2.EXAMPLE. is an example of an insecure delegation that is
+   part of the NSEC chain and also covered by an Opt-In tagged NSEC
+   record.  Because NOT-SECURE-2.EXAMPLE. is a signed name, it cannot be
+
+
+
+Arends, et al.                Experimental                     [Page 10]
+
+RFC 4956              DNS Security (DNSSEC) Opt-In             July 2007
+
+
+   removed from the zone without modifying and resigning the prior NSEC
+   record.  Delegations with names that fall between NOT-SECURE-
+   2.EXAMPLE. and SECOND-SECURE.EXAMPLE. may be added or removed without
+   resigning any NSEC records.
+
+7.  Transition Issues
+
+   Opt-In is not backwards compatible with standard DNSSEC and is
+   considered experimental.  Standard DNSSEC-compliant implementations
+   would not recognize Opt-In tagged NSEC records as different from
+   standard NSEC records.  Because of this, standard DNSSEC
+   implementations, if they were to validate Opt-In style responses,
+   would reject all Opt-In insecure delegations within a zone as
+   invalid.  However, by only signing with private algorithms, standard
+   DNSSEC implementations will treat Opt-In responses as unsigned.
+
+   It should be noted that all elements in the resolution path between
+   (and including) the validator and the authoritative name server must
+   be aware of the Opt-In experiment and implement the Opt-In semantics
+   for successful validation to be possible.  In particular, this
+   includes any caching middleboxes between the validator and
+   authoritative name server.
+
+8.  Security Considerations
+
+   Opt-In allows for unsigned names, in the form of delegations to
+   unsigned subzones, to exist within an otherwise signed zone.  All
+   unsigned names are, by definition, insecure, and their validity or
+   existence cannot be cryptographically proven.
+
+   In general:
+
+   o  Records with unsigned names (whether or not existing) suffer from
+      the same vulnerabilities as records in an unsigned zone.  These
+      vulnerabilities are described in more detail in [12] (note in
+      particular Sections 2.3, "Name Games" and 2.6, "Authenticated
+      Denial").
+
+   o  Records with signed names have the same security whether or not
+      Opt-In is used.
+
+   Note that with or without Opt-In, an insecure delegation may have its
+   contents undetectably altered by an attacker.  Because of this, the
+   primary difference in security that Opt-In introduces is the loss of
+   the ability to prove the existence or nonexistence of an insecure
+   delegation within the span of an Opt-In NSEC record.
+
+
+
+
+
+Arends, et al.                Experimental                     [Page 11]
+
+RFC 4956              DNS Security (DNSSEC) Opt-In             July 2007
+
+
+   In particular, this means that a malicious entity may be able to
+   insert or delete records with unsigned names.  These records are
+   normally NS records, but this also includes signed wildcard
+   expansions (while the wildcard record itself is signed, its expanded
+   name is an unsigned name), which can be undetectably removed or used
+   to replace an existing unsigned delegation.
+
+   For example, if a resolver received the following response from the
+   example zone above:
+
+   Example S.1: Response to query for WWW.DOES-NOT-EXIST.EXAMPLE.  A
+
+         RCODE=NOERROR
+
+         Answer Section:
+
+         Authority Section:
+         DOES-NOT-EXIST.EXAMPLE. NS     NS.FORGED.
+         EXAMPLE.                NSEC   FIRST-SECURE.EXAMPLE. SOA NS \
+                                        RRSIG DNSKEY
+         EXAMPLE.                RRSIG  NSEC ...
+
+         Additional Section:
+
+
+                        Attacker has forged a name
+
+   The resolver would have no choice but to believe that the referral to
+   NS.FORGED. is valid.  If a wildcard existed that would have been
+   expanded to cover "WWW.DOES-NOT-EXIST.EXAMPLE.", an attacker could
+   have undetectably removed it and replaced it with the forged
+   delegation.
+
+   Note that being able to add a delegation is functionally equivalent
+   to being able to add any record type: an attacker merely has to forge
+   a delegation to the nameserver under his/her control and place
+   whatever records are needed at the subzone apex.
+
+   While in particular cases, this issue may not present a significant
+   security problem, in general it should not be lightly dismissed.
+   Therefore, it is strongly RECOMMENDED that Opt-In be used sparingly.
+   In particular, zone signing tools SHOULD NOT default to Opt-In, and
+   MAY choose not to support Opt-In at all.
+
+
+
+
+
+
+
+
+Arends, et al.                Experimental                     [Page 12]
+
+RFC 4956              DNS Security (DNSSEC) Opt-In             July 2007
+
+
+9.  Acknowledgments
+
+   The contributions, suggestions, and remarks of the following persons
+   (in alphabetic order) to this document are acknowledged:
+
+      Mats Kolkman, Edward Lewis, Ted Lindgreen, Rip Loomis, Bill
+      Manning, Dan Massey, Scott Rose, Mike Schiraldi, Jakob Schlyter,
+      Brian Wellington.
+
+10.  References
+
+10.1.  Normative References
+
+   [1]   Mockapetris, P., "Domain names - implementation and
+         specification", STD 13, RFC 1035, November 1987.
+
+   [2]   Bradner, S., "Key words for use in RFCs to Indicate Requirement
+         Levels", BCP 14, RFC 2119, March 1997.
+
+   [3]   Wellington, B. and O. Gudmundsson, "Redefinition of DNS
+         Authenticated Data (AD) bit", RFC 3655, November 2003.
+
+   [4]   Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
+         "DNS Security Introduction and Requirements", RFC 4033,
+         March 2005.
+
+   [5]   Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
+         "Resource Records for the DNS Security Extensions", RFC 4034,
+         March 2005.
+
+   [6]   Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
+         "Protocol Modifications for the DNS Security Extensions",
+         RFC 4035, March 2005.
+
+   [7]   Blacka, D., "DNSSEC Experiments", RFC 4955, July 2007.
+
+10.2.  Informative References
+
+   [8]   Elz, R. and R. Bush, "Clarifications to the DNS Specification",
+         RFC 2181, July 1997.
+
+   [9]   Wellington, B., "Secure Domain Name System (DNS) Dynamic
+         Update", RFC 3007, November 2000.
+
+   [10]  Lewis, E., "DNS Security Extension Clarification on Zone
+         Status", RFC 3090, March 2001.
+
+
+
+
+
+Arends, et al.                Experimental                     [Page 13]
+
+RFC 4956              DNS Security (DNSSEC) Opt-In             July 2007
+
+
+   [11]  Conrad, D., "Indicating Resolver Support of DNSSEC", RFC 3225,
+         December 2001.
+
+   [12]  Atkins, D. and R. Austein, "Threat Analysis of the Domain Name
+         System (DNS)", RFC 3833, August 2004.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Arends, et al.                Experimental                     [Page 14]
+
+RFC 4956              DNS Security (DNSSEC) Opt-In             July 2007
+
+
+Appendix A.  Implementing Opt-In Using "Views"
+
+   In many cases, it may be convenient to implement an Opt-In zone by
+   combining two separately maintained "views" of a zone at request
+   time.  In this context, "view" refers to a particular version of a
+   zone, not to any specific DNS implementation feature.
+
+   In this scenario, one view is the secure view, the other is the
+   insecure (or legacy) view.  The secure view consists of an entirely
+   signed zone using Opt-In tagged NSEC records.  The insecure view
+   contains no DNSSEC information.  It is helpful, although not
+   necessary, for the secure view to be a subset (minus DNSSEC records)
+   of the insecure view.
+
+   In addition, the only RRsets that may solely exist in the insecure
+   view are non-zone-apex NS RRsets.  That is, all non-NS RRsets (and
+   the zone apex NS RRset) MUST be signed and in the secure view.
+
+   These two views may be combined at request time to provide a virtual,
+   single Opt-In zone.  The following algorithm is used when responding
+   to each query:
+
+      V_A is the secure view as described above.
+
+      V_B is the insecure view as described above.
+
+      R_A is a response generated from V_A, following standard DNSSEC.
+
+      R_B is a response generated from V_B, following DNS resolution as
+      per RFC 1035 [1].
+
+      R_C is the response generated by combining R_A with R_B, as
+      described below.
+
+      A query is DNSSEC-aware if it either has the DO bit [11] turned on
+      or is for a DNSSEC-specific record type.
+
+   1.  If V_A is a subset of V_B and the query is not DNSSEC-aware,
+       generate and return R_B, otherwise
+
+   2.  Generate R_A.
+
+   3.  If R_A's RCODE != NXDOMAIN, return R_A, otherwise
+
+
+
+
+
+
+
+
+Arends, et al.                Experimental                     [Page 15]
+
+RFC 4956              DNS Security (DNSSEC) Opt-In             July 2007
+
+
+   4.  Generate R_B and combine it with R_A to form R_C:
+
+          For each section (ANSWER, AUTHORITY, ADDITIONAL), copy the
+          records from R_A into R_B, EXCEPT the AUTHORITY section SOA
+          record, if R_B's RCODE = NOERROR.
+
+   5.  Return R_C.
+
+Authors' Addresses
+
+   Roy Arends
+   Nominet
+   Sandford Gate
+   Sandy Lane West
+   Oxford  OX4 6LB
+   UNITED KINGDOM
+
+   Phone: +44 1865 332211
+   EMail: roy@nominet.org.uk
+
+
+   Mark Kosters
+   VeriSign, Inc.
+   21355 Ridgetop Circle
+   Dulles, VA  20166
+   US
+
+   Phone: +1 703 948 3200
+   EMail: mkosters@verisign.com
+   URI:   http://www.verisignlabs.com
+
+
+   David Blacka
+   VeriSign, Inc.
+   21355 Ridgetop Circle
+   Dulles, VA  20166
+   US
+
+   Phone: +1 703 948 3200
+   EMail: davidb@verisign.com
+   URI:   http://www.verisignlabs.com
+
+
+
+
+
+
+
+
+
+
+Arends, et al.                Experimental                     [Page 16]
+
+RFC 4956              DNS Security (DNSSEC) Opt-In             July 2007
+
+
+Full Copyright Statement
+
+   Copyright (C) The IETF Trust (2007).
+
+   This document is subject to the rights, licenses and restrictions
+   contained in BCP 78, and except as set forth therein, the authors
+   retain all their rights.
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
+   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
+   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
+   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use of
+   such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+Arends, et al.                Experimental                     [Page 17]
+