doc: Add RFC documents

1 files changed, 1179 insertions, 0 deletions

diff --git a/doc/rfc/rfc6840.txt b/doc/rfc/rfc6840.txt
new file mode 100644
index 0000000..7ed5436
--- /dev/null
+++ b/doc/rfc/rfc6840.txt
@@ -0,0 +1,1179 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                    S. Weiler, Ed.
+Request for Comments: 6840                                  SPARTA, Inc.
+Updates: 4033, 4034, 4035, 5155                           D. Blacka, Ed.
+Category: Standards Track                                 Verisign, Inc.
+ISSN: 2070-1721                                            February 2013
+
+
+   Clarifications and Implementation Notes for DNS Security (DNSSEC)
+
+Abstract
+
+   This document is a collection of technical clarifications to the DNS
+   Security (DNSSEC) document set.  It is meant to serve as a resource
+   to implementors as well as a collection of DNSSEC errata that existed
+   at the time of writing.
+
+   This document updates the core DNSSEC documents (RFC 4033, RFC 4034,
+   and RFC 4035) as well as the NSEC3 specification (RFC 5155).  It also
+   defines NSEC3 and SHA-2 (RFC 4509 and RFC 5702) as core parts of the
+   DNSSEC specification.
+
+Status of This Memo
+
+   This is an Internet Standards Track document.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Further information on
+   Internet Standards is available in Section 2 of RFC 5741.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   http://www.rfc-editor.org/info/rfc6840.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Weiler & Blacka              Standards Track                    [Page 1]
+
+RFC 6840               DNSSEC Implementation Notes         February 2013
+
+
+Copyright Notice
+
+   Copyright (c) 2013 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents
+   (http://trustee.ietf.org/license-info) in effect on the date of
+   publication of this document.  Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+   to this document.  Code Components extracted from this document must
+   include Simplified BSD License text as described in Section 4.e of
+   the Trust Legal Provisions and are provided without warranty as
+   described in the Simplified BSD License.
+
+   This document may contain material from IETF Documents or IETF
+   Contributions published or made publicly available before November
+   10, 2008.  The person(s) controlling the copyright in some of this
+   material may not have granted the IETF Trust the right to allow
+   modifications of such material outside the IETF Standards Process.
+   Without obtaining an adequate license from the person(s) controlling
+   the copyright in such materials, this document may not be modified
+   outside the IETF Standards Process, and derivative works of it may
+   not be created outside the IETF Standards Process, except to format
+   it for publication as an RFC or to translate it into languages other
+   than English.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Weiler & Blacka              Standards Track                    [Page 2]
+
+RFC 6840               DNSSEC Implementation Notes         February 2013
+
+
+Table of Contents
+
+   1. Introduction and Terminology ....................................4
+      1.1. Structure of This Document .................................4
+      1.2. Terminology ................................................4
+   2. Important Additions to DNSSEC ...................................4
+      2.1. NSEC3 Support ..............................................4
+      2.2. SHA-2 Support ..............................................5
+   3. Scaling Concerns ................................................5
+      3.1. Implement a BAD Cache ......................................5
+   4. Security Concerns ...............................................5
+      4.1. Clarifications on Nonexistence Proofs ......................5
+      4.2. Validating Responses to an ANY Query .......................6
+      4.3. Check for CNAME ............................................6
+      4.4. Insecure Delegation Proofs .................................7
+   5. Interoperability Concerns .......................................7
+      5.1. Errors in Canonical Form Type Code List ....................7
+      5.2. Unknown DS Message Digest Algorithms .......................7
+      5.3. Private Algorithms .........................................8
+      5.4. Caution about Local Policy and Multiple RRSIGs .............9
+      5.5. Key Tag Calculation ........................................9
+      5.6. Setting the DO Bit on Replies ..............................9
+      5.7. Setting the AD Bit on Queries .............................10
+      5.8. Setting the AD Bit on Replies .............................10
+      5.9. Always Set the CD Bit on Queries ..........................10
+      5.10. Nested Trust Anchors .....................................11
+      5.11. Mandatory Algorithm Rules ................................11
+      5.12. Ignore Extra Signatures from Unknown Keys ................12
+   6. Minor Corrections and Clarifications ...........................12
+      6.1. Finding Zone Cuts .........................................12
+      6.2. Clarifications on DNSKEY Usage ............................12
+      6.3. Errors in Examples ........................................13
+      6.4. Errors in RFC 5155 ........................................13
+   7. Security Considerations ........................................13
+   8. References .....................................................14
+      8.1. Normative References ......................................14
+      8.2. Informative References ....................................15
+   Appendix A. Acknowledgments .......................................16
+   Appendix B. Discussion of Setting the CD Bit ......................16
+   Appendix C. Discussion of Trust Anchor Preference Options .........19
+      C.1. Closest Encloser ..........................................19
+      C.2. Accept Any Success ........................................20
+      C.3. Preference Based on Source ................................20
+
+
+
+
+
+
+
+
+Weiler & Blacka              Standards Track                    [Page 3]
+
+RFC 6840               DNSSEC Implementation Notes         February 2013
+
+
+1.  Introduction and Terminology
+
+   This document lists some additions, clarifications, and corrections
+   to the core DNSSEC specification, as originally described in
+   [RFC4033], [RFC4034], and [RFC4035], and later amended by [RFC5155].
+   (See Section 2 for more recent additions to that core document set.)
+
+   It is intended to serve as a resource for implementors and as a
+   repository of items existing at the time of writing that need to be
+   addressed when advancing the DNSSEC documents along the Standards
+   Track.
+
+1.1.  Structure of This Document
+
+   The clarifications and changes to DNSSEC are sorted according to
+   their importance, starting with ones which could, if ignored, lead to
+   security problems and progressing down to clarifications that are
+   expected to have little operational impact.
+
+1.2.  Terminology
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
+   "OPTIONAL" in this document are to be interpreted as described in
+   [RFC2119].
+
+2.  Important Additions to DNSSEC
+
+   This section lists some documents that are now considered core DNSSEC
+   protocol documents in addition to those originally specified in
+   Section 10 of [RFC4033].
+
+2.1.  NSEC3 Support
+
+   [RFC5155] describes the use and behavior of the NSEC3 and NSEC3PARAM
+   records for hashed denial of existence.  Validator implementations
+   are strongly encouraged to include support for NSEC3 because a number
+   of highly visible zones use it.  Validators that do not support
+   validation of responses using NSEC3 will be hampered in validating
+   large portions of the DNS space.
+
+   [RFC5155] is now considered part of the DNS Security Document Family
+   as described by Section 10 of [RFC4033].
+
+
+
+
+
+
+
+
+Weiler & Blacka              Standards Track                    [Page 4]
+
+RFC 6840               DNSSEC Implementation Notes         February 2013
+
+
+   Note that the algorithm identifiers defined in [RFC5155] (DSA-NSEC3-
+   SHA1 and RSASHA1-NSEC3-SHA1) and [RFC5702] (RSASHA256 and RSASHA512)
+   signal that a zone might be using NSEC3, rather than NSEC.  The zone
+   may be using either, and validators supporting these algorithms MUST
+   support both NSEC3 and NSEC responses.
+
+2.2.  SHA-2 Support
+
+   [RFC4509] describes the use of SHA-256 as a digest algorithm in
+   Delegation Signer (DS) RRs.  [RFC5702] describes the use of the
+   RSASHA256 and RSASHA512 algorithms in DNSKEY and RRSIG RRs.
+   Validator implementations are strongly encouraged to include support
+   for these algorithms for DS, DNSKEY, and RRSIG records.
+
+   Both [RFC4509] and [RFC5702] are now considered part of the DNS
+   Security Document Family as described by Section 10 of [RFC4033].
+
+3.  Scaling Concerns
+
+3.1.  Implement a BAD Cache
+
+   Section 4.7 of [RFC4035] permits security-aware resolvers to
+   implement a BAD cache.  That guidance has changed: security-aware
+   resolvers SHOULD implement a BAD cache as described in [RFC4035].
+
+   This change in guidance is based on operational experience with
+   DNSSEC administrative errors leading to significant increases in DNS
+   traffic, with an accompanying realization that such events are more
+   likely and more damaging than originally supposed.  An example of one
+   such event is documented in "Rolling Over DNSSEC Keys" [Huston].
+
+4.  Security Concerns
+
+   This section provides clarifications that, if overlooked, could lead
+   to security issues.
+
+4.1.  Clarifications on Nonexistence Proofs
+
+   Section 5.4 of [RFC4035] under-specifies the algorithm for checking
+   nonexistence proofs.  In particular, the algorithm as presented would
+   allow a validator to interpret an NSEC or NSEC3 RR from an ancestor
+   zone as proving the nonexistence of an RR in a child zone.
+
+   An "ancestor delegation" NSEC RR (or NSEC3 RR) is one with:
+
+   o  the NS bit set,
+
+   o  the Start of Authority (SOA) bit clear, and
+
+
+
+Weiler & Blacka              Standards Track                    [Page 5]
+
+RFC 6840               DNSSEC Implementation Notes         February 2013
+
+
+   o  a signer field that is shorter than the owner name of the NSEC RR,
+      or the original owner name for the NSEC3 RR.
+
+   Ancestor delegation NSEC or NSEC3 RRs MUST NOT be used to assume
+   nonexistence of any RRs below that zone cut, which include all RRs at
+   that (original) owner name other than DS RRs, and all RRs below that
+   owner name regardless of type.
+
+   Similarly, the algorithm would also allow an NSEC RR at the same
+   owner name as a DNAME RR, or an NSEC3 RR at the same original owner
+   name as a DNAME, to prove the nonexistence of names beneath that
+   DNAME.  An NSEC or NSEC3 RR with the DNAME bit set MUST NOT be used
+   to assume the nonexistence of any subdomain of that NSEC/NSEC3 RR's
+   (original) owner name.
+
+4.2.  Validating Responses to an ANY Query
+
+   [RFC4035] does not address how to validate responses when QTYPE=*.
+   As described in Section 6.2.2 of [RFC1034], a proper response to
+   QTYPE=* may include a subset of the RRsets at a given name.  That is,
+   it is not necessary to include all RRsets at the QNAME in the
+   response.
+
+   When validating a response to QTYPE=*, all received RRsets that match
+   QNAME and QCLASS MUST be validated.  If any of those RRsets fail
+   validation, the answer is considered Bogus.  If there are no RRsets
+   matching QNAME and QCLASS, that fact MUST be validated according to
+   the rules in Section 5.4 of [RFC4035] (as clarified in this
+   document).  To be clear, a validator must not expect to receive all
+   records at the QNAME in response to QTYPE=*.
+
+4.3.  Check for CNAME
+
+   Section 5 of [RFC4035] says nothing explicit about validating
+   responses based on (or that should be based on) CNAMEs.  When
+   validating a NOERROR/NODATA response, validators MUST check the CNAME
+   bit in the matching NSEC or NSEC3 RR's type bitmap in addition to the
+   bit for the query type.
+
+   Without this check, an attacker could successfully transform a
+   positive CNAME response into a NOERROR/NODATA response by (for
+   example) simply stripping the CNAME RRset from the response.  A naive
+   validator would then note that the QTYPE was not present in the
+   matching NSEC/NSEC3 RR, but fail to notice that the CNAME bit was
+   set; thus, the response should have been a positive CNAME response.
+
+
+
+
+
+
+Weiler & Blacka              Standards Track                    [Page 6]
+
+RFC 6840               DNSSEC Implementation Notes         February 2013
+
+
+4.4.  Insecure Delegation Proofs
+
+   Section 5.2 of [RFC4035] specifies that a validator, when proving a
+   delegation is not secure, needs to check for the absence of the DS
+   and SOA bits in the NSEC (or NSEC3) type bitmap.  The validator also
+   MUST check for the presence of the NS bit in the matching NSEC (or
+   NSEC3) RR (proving that there is, indeed, a delegation), or
+   alternately make sure that the delegation is covered by an NSEC3 RR
+   with the Opt-Out flag set.
+
+   Without this check, an attacker could reuse an NSEC or NSEC3 RR
+   matching a non-delegation name to spoof an unsigned delegation at
+   that name.  This would claim that an existing signed RRset (or set of
+   signed RRsets) is below an unsigned delegation, thus not signed and
+   vulnerable to further attack.
+
+5.  Interoperability Concerns
+
+5.1.  Errors in Canonical Form Type Code List
+
+   When canonicalizing DNS names (for both ordering and signing), DNS
+   names in the RDATA section of NSEC resource records are not converted
+   to lowercase.  DNS names in the RDATA section of RRSIG resource
+   records are converted to lowercase.
+
+   The guidance in the above paragraph differs from what has been
+   published before but is consistent with current common practice.
+   Item 3 of Section 6.2 of [RFC4034] says that names in both of these
+   RR types should be converted to lowercase.  The earlier [RFC3755]
+   says that they should not.  Current practice follows neither document
+   fully.
+
+   Section 6.2 of [RFC4034] also erroneously lists HINFO as a record
+   that needs conversion to lowercase, and twice at that.  Since HINFO
+   records contain no domain names, they are not subject to case
+   conversion.
+
+5.2.  Unknown DS Message Digest Algorithms
+
+   Section 5.2 of [RFC4035] includes rules for how to handle delegations
+   to zones that are signed with entirely unsupported public key
+   algorithms, as indicated by the key algorithms shown in those zones'
+   DS RRsets.  It does not explicitly address how to handle DS records
+   that use unsupported message digest algorithms.  In brief, DS records
+   using unknown or unsupported message digest algorithms MUST be
+   treated the same way as DS records referring to DNSKEY RRs of unknown
+   or unsupported public key algorithms.
+
+
+
+
+Weiler & Blacka              Standards Track                    [Page 7]
+
+RFC 6840               DNSSEC Implementation Notes         February 2013
+
+
+   The existing text says:
+
+      If the validator does not support any of the algorithms listed in
+      an authenticated DS RRset, then the resolver has no supported
+      authentication path leading from the parent to the child.  The
+      resolver should treat this case as it would the case of an
+      authenticated NSEC RRset proving that no DS RRset exists, as
+      described above.
+
+   In other words, when determining the security status of a zone, a
+   validator disregards any authenticated DS records that specify
+   unknown or unsupported DNSKEY algorithms.  If none are left, the zone
+   is treated as if it were unsigned.
+
+   This document modifies the above text to additionally disregard
+   authenticated DS records using unknown or unsupported message digest
+   algorithms.
+
+5.3.  Private Algorithms
+
+   As discussed above, Section 5.2 of [RFC4035] requires that validators
+   make decisions about the security status of zones based on the public
+   key algorithms shown in the DS records for those zones.  In the case
+   of private algorithms, as described in Appendix A.1.1 of [RFC4034],
+   the eight-bit algorithm field in the DS RR is not conclusive about
+   what algorithm(s) is actually in use.
+
+   If no private algorithms appear in the DS RRset, or if any supported
+   algorithm appears in the DS RRset, no special processing is needed.
+   Furthermore, if the validator implementation does not support any
+   private algorithms, or only supports private algorithms using an
+   algorithm number not present in the DS RRset, no special processing
+   is needed.
+
+   In the remaining cases, the security status of the zone depends on
+   whether or not the resolver supports any of the private algorithms in
+   use (provided that these DS records use supported message digest
+   algorithms, as discussed in Section 5.2 of this document).  In these
+   cases, the resolver MUST retrieve the corresponding DNSKEY for each
+   private algorithm DS record and examine the public key field to
+   determine the algorithm in use.  The security-aware resolver MUST
+   ensure that the hash of the DNSKEY RR's owner name and RDATA matches
+   the digest in the DS RR as described in Section 5.2 of [RFC4035],
+   authenticating the DNSKEY.  If all of the retrieved and authenticated
+   DNSKEY RRs use unknown or unsupported private algorithms, then the
+   zone is treated as if it were unsigned.
+
+
+
+
+
+Weiler & Blacka              Standards Track                    [Page 8]
+
+RFC 6840               DNSSEC Implementation Notes         February 2013
+
+
+   Note that if none of the private algorithm DS RRs can be securely
+   matched to DNSKEY RRs and no other DS establishes that the zone is
+   secure, the referral should be considered Bogus data as discussed in
+   [RFC4035].
+
+   This clarification facilitates the broader use of private algorithms,
+   as suggested by [RFC4955].
+
+5.4.  Caution about Local Policy and Multiple RRSIGs
+
+   When multiple RRSIGs cover a given RRset, Section 5.3.3 of [RFC4035]
+   suggests that "the local resolver security policy determines whether
+   the resolver also has to test these RRSIG RRs and how to resolve
+   conflicts if these RRSIG RRs lead to differing results".
+
+   This document specifies that a resolver SHOULD accept any valid RRSIG
+   as sufficient, and only determine that an RRset is Bogus if all
+   RRSIGs fail validation.
+
+   If a resolver adopts a more restrictive policy, there's a danger that
+   properly signed data might unnecessarily fail validation due to cache
+   timing issues.  Furthermore, certain zone management techniques, like
+   the Double Signature Zone Signing Key Rollover method described in
+   Section 4.2.1.2 of [RFC6781], will not work reliably.  Such a
+   resolver is also vulnerable to malicious insertion of gibberish
+   signatures.
+
+5.5.  Key Tag Calculation
+
+   Appendix B.1 of [RFC4034] incorrectly defines the Key Tag field
+   calculation for algorithm 1.  It correctly says that the Key Tag is
+   the most significant 16 of the least significant 24 bits of the
+   public key modulus.  However, [RFC4034] then goes on to incorrectly
+   say that this is fourth-to-last and third-to-last octets of the
+   public key modulus.  It is, in fact, the third-to-last and second-to-
+   last octets.
+
+5.6.  Setting the DO Bit on Replies
+
+   As stated in Section 3 of [RFC3225], the DNSSEC OK (DO) bit of the
+   query MUST be copied in the response.  However, in order to
+   interoperate with implementations that ignore this rule on sending,
+   resolvers MUST ignore the DO bit in responses.
+
+
+
+
+
+
+
+
+Weiler & Blacka              Standards Track                    [Page 9]
+
+RFC 6840               DNSSEC Implementation Notes         February 2013
+
+
+5.7.  Setting the AD Bit on Queries
+
+   The semantics of the Authentic Data (AD) bit in the query were
+   previously undefined.  Section 4.6 of [RFC4035] instructed resolvers
+   to always clear the AD bit when composing queries.
+
+   This document defines setting the AD bit in a query as a signal
+   indicating that the requester understands and is interested in the
+   value of the AD bit in the response.  This allows a requester to
+   indicate that it understands the AD bit without also requesting
+   DNSSEC data via the DO bit.
+
+5.8.  Setting the AD Bit on Replies
+
+   Section 3.2.3 of [RFC4035] describes under which conditions a
+   validating resolver should set or clear the AD bit in a response.  In
+   order to interoperate with legacy stub resolvers and middleboxes that
+   neither understand nor ignore the AD bit, validating resolvers SHOULD
+   only set the AD bit when a response both meets the conditions listed
+   in Section 3.2.3 of [RFC4035], and the request contained either a set
+   DO bit or a set AD bit.
+
+5.9.  Always Set the CD Bit on Queries
+
+   When processing a request with the Checking Disabled (CD) bit set, a
+   resolver SHOULD attempt to return all response data, even data that
+   has failed DNSSEC validation.  Section 3.2.2 of [RFC4035] requires a
+   resolver processing a request with the CD bit set to set the CD bit
+   on its upstream queries.
+
+   This document further specifies that validating resolvers SHOULD set
+   the CD bit on every upstream query.  This is regardless of whether
+   the CD bit was set on the incoming query or whether it has a trust
+   anchor at or above the QNAME.
+
+   [RFC4035] is ambiguous about what to do when a cached response was
+   obtained with the CD bit unset, a case that only arises when the
+   resolver chooses not to set the CD bit on all upstream queries, as
+   specified above.  In the typical case, no new query is required, nor
+   does the cache need to track the state of the CD bit used to make a
+   given query.  The problem arises when the cached response is a server
+   failure (RCODE 2), which may indicate that the requested data failed
+   DNSSEC validation at an upstream validating resolver.  ([RFC2308]
+   permits caching of server failures for up to five minutes.)  In these
+   cases, a new query with the CD bit set is required.
+
+   Appendix B discusses more of the logic behind the recommendation
+   presented in this section.
+
+
+
+Weiler & Blacka              Standards Track                   [Page 10]
+
+RFC 6840               DNSSEC Implementation Notes         February 2013
+
+
+5.10.  Nested Trust Anchors
+
+   A DNSSEC validator may be configured such that, for a given response,
+   more than one trust anchor could be used to validate the chain of
+   trust to the response zone.  For example, imagine a validator
+   configured with trust anchors for "example." and "zone.example."
+   When the validator is asked to validate a response to
+   "www.sub.zone.example.", either trust anchor could apply.
+
+   When presented with this situation, DNSSEC validators have a choice
+   of which trust anchor(s) to use.  Which to use is a matter of
+   implementation choice.  Appendix C discusses several possible
+   algorithms.
+
+   It is possible and advisable to expose the choice of policy as a
+   configuration option.  As a default, it is suggested that validators
+   implement the "Accept Any Success" policy described in Appendix C.2
+   while exposing other policies as configuration options.
+
+   The "Accept Any Success" policy is to try all applicable trust
+   anchors until one gives a validation result of Secure, in which case
+   the final validation result is Secure.  If and only if all applicable
+   trust anchors give a result of Insecure, the final validation result
+   is Insecure.  If one or more trust anchors lead to a Bogus result and
+   there is no Secure result, then the final validation result is Bogus.
+
+5.11.  Mandatory Algorithm Rules
+
+   The last paragraph of Section 2.2 of [RFC4035] includes rules
+   describing which algorithms must be used to sign a zone.  Since these
+   rules have been confusing, they are restated using different language
+   here:
+
+      The DS RRset and DNSKEY RRset are used to signal which algorithms
+      are used to sign a zone.  The presence of an algorithm in either a
+      zone's DS or DNSKEY RRset signals that that algorithm is used to
+      sign the entire zone.
+
+      A signed zone MUST include a DNSKEY for each algorithm present in
+      the zone's DS RRset and expected trust anchors for the zone.  The
+      zone MUST also be signed with each algorithm (though not each key)
+      present in the DNSKEY RRset.  It is possible to add algorithms at
+      the DNSKEY that aren't in the DS record, but not vice versa.  If
+      more than one key of the same algorithm is in the DNSKEY RRset, it
+      is sufficient to sign each RRset with any subset of these DNSKEYs.
+      It is acceptable to sign some RRsets with one subset of keys (or
+      key) and other RRsets with a different subset, so long as at least
+
+
+
+
+Weiler & Blacka              Standards Track                   [Page 11]
+
+RFC 6840               DNSSEC Implementation Notes         February 2013
+
+
+      one DNSKEY of each algorithm is used to sign each RRset.
+      Likewise, if there are DS records for multiple keys of the same
+      algorithm, any subset of those may appear in the DNSKEY RRset.
+
+   This requirement applies to servers, not validators.  Validators
+   SHOULD accept any single valid path.  They SHOULD NOT insist that all
+   algorithms signaled in the DS RRset work, and they MUST NOT insist
+   that all algorithms signaled in the DNSKEY RRset work.  A validator
+   MAY have a configuration option to perform a signature completeness
+   test to support troubleshooting.
+
+5.12.  Ignore Extra Signatures from Unknown Keys
+
+   Validating resolvers MUST disregard RRSIGs in a zone that do not
+   (currently) have a corresponding DNSKEY in the zone.  Similarly, a
+   validating resolver MUST disregard RRSIGs with algorithm types that
+   don't exist in the DNSKEY RRset.
+
+   Good key rollover and algorithm rollover practices, as discussed in
+   RFC 6781 and its successor documents and as suggested by the rules in
+   the previous section, may require that such RRSIGs be present in a
+   zone.
+
+6.  Minor Corrections and Clarifications
+
+6.1.  Finding Zone Cuts
+
+   Appendix C.8 of [RFC4035] discusses sending DS queries to the servers
+   for a parent zone but does not state how to find those servers.
+   Specific instructions can be found in Section 4.2 of [RFC4035].
+
+6.2.  Clarifications on DNSKEY Usage
+
+   It is possible to use different DNSKEYs to sign different subsets of
+   a zone, constrained only by the rules in Section 5.11.  It is even
+   possible to use a different DNSKEY for each RRset in a zone, subject
+   only to practical limits on the size of the DNSKEY RRset and the
+   above rules.  However, be aware that there is no way to tell
+   resolvers what a particular DNSKEY is supposed to be used for -- any
+   DNSKEY in the zone's signed DNSKEY RRset may be used to authenticate
+   any RRset in the zone.  For example, if a weaker or less trusted
+   DNSKEY is being used to authenticate NSEC RRsets or all dynamically
+   updated records, that same DNSKEY can also be used to sign any other
+   RRsets from the zone.
+
+   Furthermore, note that the SEP bit setting has no effect on how a
+   DNSKEY may be used -- the validation process is specifically
+   prohibited from using that bit by Section 2.1.2 of [RFC4034].  It is
+
+
+
+Weiler & Blacka              Standards Track                   [Page 12]
+
+RFC 6840               DNSSEC Implementation Notes         February 2013
+
+
+   possible to use a DNSKEY without the SEP bit set as the sole secure
+   entry point to the zone, yet use a DNSKEY with the SEP bit set to
+   sign all RRsets in the zone (other than the DNSKEY RRset).  It is
+   also possible to use a single DNSKEY, with or without the SEP bit
+   set, to sign the entire zone, including the DNSKEY RRset itself.
+
+6.3.  Errors in Examples
+
+   The text in Appendix C.1 of [RFC4035] refers to the examples in
+   Appendix B.1 as "x.w.example.com" while B.1 uses "x.w.example".  This
+   is painfully obvious in the second paragraph where it states that the
+   RRSIG labels field value of 3 indicates that the answer was not the
+   result of wildcard expansion.  This is true for "x.w.example" but not
+   for "x.w.example.com", which of course has a label count of 4
+   (antithetically, a label count of 3 would imply the answer was the
+   result of a wildcard expansion).
+
+   The first paragraph of Appendix C.6 of [RFC4035] also has a minor
+   error: the reference to "a.z.w.w.example" should instead be
+   "a.z.w.example", as in the previous line.
+
+6.4.  Errors in RFC 5155
+
+   An NSEC3 record that matches an Empty Non-Terminal effectively has no
+   type associated with it.  This NSEC3 record has an empty type bit
+   map.  Section 3.2.1 of [RFC5155] contains the statement:
+
+      Blocks with no types present MUST NOT be included.
+
+   However, the same section contains a regular expression:
+
+      Type Bit Maps Field = ( Window Block # | Bitmap Length | Bitmap )+
+
+   The plus sign in the regular expression indicates that there is one
+   or more of the preceding element.  This means that there must be at
+   least one window block.  If this window block has no types, it
+   contradicts with the first statement.  Therefore, the correct text in
+   Section 3.2.1 of [RFC5155] should be:
+
+      Type Bit Maps Field = ( Window Block # | Bitmap Length | Bitmap )*
+
+7.  Security Considerations
+
+   This document adds SHA-2 and NSEC3 support to the core DNSSEC
+   protocol.  Security considerations for those features are discussed
+   in the documents defining them.  Additionally, this document
+   addresses some ambiguities and omissions in the core DNSSEC documents
+   that, if not recognized and addressed in implementations, could lead
+
+
+
+Weiler & Blacka              Standards Track                   [Page 13]
+
+RFC 6840               DNSSEC Implementation Notes         February 2013
+
+
+   to security failures.  In particular, the validation algorithm
+   clarifications in Section 4 are critical for preserving the security
+   properties DNSSEC offers.  Furthermore, failure to address some of
+   the interoperability concerns in Section 5 could limit the ability to
+   later change or expand DNSSEC, including adding new algorithms.
+
+   The recommendation in Section 5.9 to always set the CD bit has
+   security implications.  By setting the CD bit, a resolver will not
+   benefit from more stringent validation rules or a more complete set
+   of trust anchors at an upstream validator.
+
+8.  References
+
+8.1.  Normative References
+
+   [RFC1034]  Mockapetris, P., "Domain names - concepts and facilities",
+              STD 13, RFC 1034, November 1987.
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC3225]  Conrad, D., "Indicating Resolver Support of DNSSEC",
+              RFC 3225, December 2001.
+
+   [RFC4033]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
+              Rose, "DNS Security Introduction and Requirements",
+              RFC 4033, March 2005.
+
+   [RFC4034]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
+              Rose, "Resource Records for the DNS Security Extensions",
+              RFC 4034, March 2005.
+
+   [RFC4035]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
+              Rose, "Protocol Modifications for the DNS Security
+              Extensions", RFC 4035, March 2005.
+
+   [RFC4509]  Hardaker, W., "Use of SHA-256 in DNSSEC Delegation Signer
+              (DS) Resource Records (RRs)", RFC 4509, May 2006.
+
+   [RFC5155]  Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS
+              Security (DNSSEC) Hashed Authenticated Denial of
+              Existence", RFC 5155, March 2008.
+
+   [RFC5702]  Jansen, J., "Use of SHA-2 Algorithms with RSA in DNSKEY
+              and RRSIG Resource Records for DNSSEC", RFC 5702,
+              October 2009.
+
+
+
+
+
+Weiler & Blacka              Standards Track                   [Page 14]
+
+RFC 6840               DNSSEC Implementation Notes         February 2013
+
+
+8.2.  Informative References
+
+   [Huston]   Michaelson, G., Wallstrom, P., Arends, R., and G. Huston,
+              "Rolling Over DNSSEC Keys", Internet Protocol
+              Journal, Vol. 13, No.1, pp. 2-16, March 2010.
+
+   [RFC2308]  Andrews, M., "Negative Caching of DNS Queries (DNS
+              NCACHE)", RFC 2308, March 1998.
+
+   [RFC3755]  Weiler, S., "Legacy Resolver Compatibility for Delegation
+              Signer (DS)", RFC 3755, May 2004.
+
+   [RFC4955]  Blacka, D., "DNS Security (DNSSEC) Experiments", RFC 4955,
+              July 2007.
+
+   [RFC5011]  StJohns, M., "Automated Updates of DNS Security (DNSSEC)
+              Trust Anchors", STD 74, RFC 5011, September 2007.
+
+   [RFC5074]  Weiler, S., "DNSSEC Lookaside Validation (DLV)", RFC 5074,
+              November 2007.
+
+   [RFC6781]  Kolkman, O., Mekking, W., and R. Gieben, "DNSSEC
+              Operational Practices, Version 2", RFC 6781,
+              December 2012.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Weiler & Blacka              Standards Track                   [Page 15]
+
+RFC 6840               DNSSEC Implementation Notes         February 2013
+
+
+Appendix A.  Acknowledgments
+
+   The editors would like the thank Rob Austein for his previous work as
+   an editor of this document.
+
+   The editors are extremely grateful to those who, in addition to
+   finding errors and omissions in the DNSSEC document set, have
+   provided text suitable for inclusion in this document.
+
+   The lack of specificity about handling private algorithms, as
+   described in Section 5.3, and the lack of specificity in handling ANY
+   queries, as described in Section 4.2, were discovered by David
+   Blacka.
+
+   The error in algorithm 1 key tag calculation, as described in
+   Section 5.5, was found by Abhijit Hayatnagarkar.  Donald Eastlake
+   contributed text for Section 5.5.
+
+   The bug relating to delegation NSEC RR's in Section 4.1 was found by
+   Roy Badami.  Roy Arends found the related problem with DNAME.
+
+   The errors in the [RFC4035] examples were found by Roy Arends, who
+   also contributed text for Section 6.3 of this document.
+
+   Text on the mandatory algorithm rules was derived from suggestions by
+   Matthijs Mekking and Ed Lewis.
+
+   The CD bit logic was analyzed in depth by David Blacka, Olafur
+   Gudmundsson, Mike St. Johns, and Andrew Sullivan.
+
+   The editors would like to thank Alfred Hoenes, Ed Lewis, Danny Mayer,
+   Olafur Gudmundsson, Suzanne Woolf, Rickard Bellgrim, Mike St. Johns,
+   Mark Andrews, Wouter Wijngaards, Matthijs Mekking, Andrew Sullivan,
+   Jeremy Reed, Paul Hoffman, Mohan Parthasarathy, Florian Weimer,
+   Warren Kumari and Scott Rose for their contributions to this
+   document.
+
+Appendix B.  Discussion of Setting the CD Bit
+
+   [RFC4035] may be read as relying on the implicit assumption that
+   there is at most one validating system between the stub resolver and
+   the authoritative server for a given zone.  It is entirely possible,
+   however, for more than one validator to exist between a stub resolver
+   and an authoritative server.  If these different validators have
+   disjoint trust anchors configured, then it is possible that each
+   would be able to validate some portion of the DNS tree, but neither
+
+
+
+
+
+Weiler & Blacka              Standards Track                   [Page 16]
+
+RFC 6840               DNSSEC Implementation Notes         February 2013
+
+
+   is able to validate all of it.  Accordingly, it might be argued that
+   it is desirable not to set the CD bit on upstream queries, because
+   that allows for maximal validation.
+
+   In Section 5.9 of this document, it is recommended to set the CD bit
+   on an upstream query even when the incoming query arrives with CD=0.
+   This is for two reasons: it encourages a more predictable validation
+   experience as only one validator is always doing the validation, and
+   it ensures that all DNSSEC data that exists may be available from the
+   local cache should a query with CD=1 arrive.
+
+   As a matter of policy, it is possible to set the CD bit differently
+   than suggested in Section 5.9.  A different choice will, of course,
+   not always yield the benefits listed above.  It is beyond the scope
+   of this document to outline all of the considerations and counter
+   considerations for all possible policies.  Nevertheless, it is
+   possible to describe three approaches and their underlying philosophy
+   of operation.  These are laid out in the tables below.
+
+   The table that describes each model has five columns.  The first
+   column indicates the value of the CD bit that the resolver receives
+   (for instance, on the name server side in an iterative resolver, or
+   as local policy or from the API in the case of a stub).  The second
+   column indicates whether the query needs to be forwarded for
+   resolution (F) or can be satisfied from a local cache (C).  The third
+   column is a line number, so that it can be referred to later in the
+   table.  The fourth column indicates any relevant conditions at the
+   resolver, for example, whether the resolver has a covering trust
+   anchor, and so on.  If there are no parameters here, the column is
+   empty.  The fifth and final column indicates what action the resolver
+   takes.
+
+   The tables differentiate between "cached data" and "cached RCODE=2".
+   This is a shorthand; the point is that one has to treat RCODE=2
+   (server failure) as special, because it might indicate a validation
+   failure somewhere upstream.  The distinction is really between
+   "cached RCODE=2" and "cached everything else".
+
+   The tables are probably easiest to think of in terms of describing
+   what happens when a stub resolver sends a query to an intermediate
+   resolver, but they are perfectly general and can be applied to any
+   validating resolver.
+
+   Model 1: "always set"
+
+   This model is so named because the validating resolver sets the CD
+   bit on queries it makes regardless of whether it has a covering trust
+   anchor for the query.  The general philosophy represented by this
+
+
+
+Weiler & Blacka              Standards Track                   [Page 17]
+
+RFC 6840               DNSSEC Implementation Notes         February 2013
+
+
+   table is that only one resolver should be responsible for validation
+   irrespective of the possibility that an upstream resolver may be
+   present with trust anchors that cover different or additional QNAMEs.
+   It is the model recommended in Section 5.9 of this document.
+
+    CD F/C    line      conditions            action
+    ====================================================================
+    1   F      A1                             Set CD=1 on upstream query
+    0   F      A2                             Set CD=1 on upstream query
+    1   C      A3                             Return the cache contents
+                                               (data or RCODE=2)
+    0   C      A4       no covering TA        Return cache contents
+                                               (data or RCODE=2)
+    0   C      A5       covering TA           Validate cached result and
+                                               return it
+
+   Model 2: "never set when receiving CD=0"
+
+   This model is so named because it sets CD=0 on upstream queries for
+   all received CD=0 queries, even if it has a covering trust anchor.
+   The general philosophy represented by this table is that more than
+   one resolver may take responsibility for validating a QNAME and that
+   a validation failure for a QNAME by any resolver in the chain is a
+   validation failure for the query.  Using this model is NOT
+   RECOMMENDED.
+
+    CD F/C    line       conditions           action
+    ====================================================================
+    1  F      N1                              Set CD=1 on upstream query
+    0  F      N2                              Set CD=0 on upstream query
+    1  C      N3         cached data          Return cached data
+    1  C      N4         cached RCODE=2       Treat as line N1
+    0  C      N5         no covering TA       Return cache contents
+                                               (data or RCODE=2)
+    0  C      N6         covering TA &        Treat as line N2
+                          cached data was
+                          generated with CD=1
+    0  C      N7         covering TA &        Validate and return
+                          cached data was
+                          generated with CD=0
+
+
+   Model 3: "sometimes set"
+
+   This model is so named because it sets the CD bit on upstream queries
+   triggered by received CD=0 queries, based on whether the validator
+   has a trust anchor configured that covers the query.  If there is no
+   covering trust anchor, the resolver clears the CD bit in the upstream
+
+
+
+Weiler & Blacka              Standards Track                   [Page 18]
+
+RFC 6840               DNSSEC Implementation Notes         February 2013
+
+
+   query.  If there is a covering trust anchor, the resolver sets CD=1
+   and performs validation itself.  The general philosophy represented
+   by this table is that a resolver should try and validate QNAMEs for
+   which it has trust anchors and should not preclude validation by
+   other resolvers for QNAMEs for which it does not have covering trust
+   anchors.  Using this model is NOT RECOMMENDED.
+
+    CD F/C    line       conditions         action
+    ====================================================================
+    1  F      S1                            Set CD=1 on upstream query
+    0  F      S2         covering TA        Set CD=1 on upstream query
+    0  F      S3         no covering TA     Set CD=0 on upstream query
+    1  C      S4         cached data        Return cached data
+    1  C      S5         cached RCODE=2     Treat as line S1
+    0  C      S6         cached data was    Return cache contents
+                          generated with
+                          CD=0
+    0  C      S7         cached data was    Validate & return cache
+                          generated with     contents
+                          CD=1 &
+                          covering TA
+    0  C      S8         cached RCODE=2     Return cache contents
+    0  C      S9         cached data        Treat as line S3
+                          was generated
+                          with CD=1 &
+                          no covering
+                          TA
+
+
+Appendix C.  Discussion of Trust Anchor Preference Options
+
+   This section presents several different policies for validating
+   resolvers to use when they have a choice of trust anchors available
+   for validating a given answer.
+
+C.1.  Closest Encloser
+
+   One policy is to choose the trust anchor closest to the QNAME of the
+   response.  For example, consider a validator configured with trust
+   anchors for "example." and "zone.example."  When asked to validate a
+   response for "www.sub.zone.example.", a validator using the "Closest
+   Encloser" policy would choose the "zone.example." trust anchor.
+
+   This policy has the advantage of allowing the operator to trivially
+   override a parent zone's trust anchor with one that the operator can
+   validate in a stronger way, perhaps because the resolver operator is
+
+
+
+
+
+Weiler & Blacka              Standards Track                   [Page 19]
+
+RFC 6840               DNSSEC Implementation Notes         February 2013
+
+
+   affiliated with the zone in question.  This policy also minimizes the
+   number of public key operations needed, which is of benefit in
+   resource-constrained environments.
+
+   This policy has the disadvantage of giving the user some unexpected
+   and unnecessary validation failures when sub-zone trust anchors are
+   neglected.  As a concrete example, consider a validator that
+   configured a trust anchor for "zone.example." in 2009 and one for
+   "example." in 2011.  In 2012, "zone.example." rolls its Key Signing
+   Key (KSK) and updates its DS records, but the validator operator
+   doesn't update its trust anchor.  With the "Closest Encloser" policy,
+   the validator gets validation failures.
+
+C.2.  Accept Any Success
+
+   Another policy is to try all applicable trust anchors until one gives
+   a validation result of Secure, in which case the final validation
+   result is Secure.  If and only if all applicable trust anchors give a
+   result of Insecure, the final validation result is Insecure.  If one
+   or more trust anchors lead to a Bogus result and there is no Secure
+   result, then the final validation result is Bogus.
+
+   This has the advantage of causing the fewest validation failures,
+   which may deliver a better user experience.  If one trust anchor is
+   out of date (as in our above example), the user may still be able to
+   get a Secure validation result (and see DNS responses).
+
+   This policy has the disadvantage of making the validator subject to
+   the compromise of the weakest of these trust anchors, while making it
+   relatively painless to keep old trust anchors configured in
+   perpetuity.
+
+C.3.  Preference Based on Source
+
+   When the trust anchors have come from different sources (e.g.,
+   automated updates ([RFC5011]), one or more DNSSEC Lookaside
+   Validation (DLV) registries ([RFC5074]), and manual configuration), a
+   validator may wish to choose between them based on the perceived
+   reliability of those sources.  The order of precedence might be
+   exposed as a configuration option.
+
+   For example, a validator might choose to prefer trust anchors found
+   in a DLV registry over those manually configured on the theory that
+   the manually configured ones will not be as aggressively maintained.
+
+
+
+
+
+
+
+Weiler & Blacka              Standards Track                   [Page 20]
+
+RFC 6840               DNSSEC Implementation Notes         February 2013
+
+
+   Conversely, a validator might choose to prefer manually configured
+   trust anchors over those obtained from a DLV registry on the theory
+   that the manually configured ones have been more carefully
+   authenticated.
+
+   Or the validator might do something more complex: prefer a sub-set of
+   manually configured trust anchors (based on a configuration option),
+   then trust anchors that have been updated using the mechanism in
+   [RFC5011], then trust anchors from one DLV registry, then trust
+   anchors from a different DLV registry, then the rest of the manually
+   configured trust anchors.
+
+Authors' Addresses
+
+   Samuel Weiler (editor)
+   SPARTA, Inc.
+   7110 Samuel Morse Drive
+   Columbia, MD  21046
+   US
+
+   EMail: weiler@tislabs.com
+
+
+   David Blacka (editor)
+   Verisign, Inc.
+   12061 Bluemont Way
+   Reston, VA  20190
+   US
+
+   EMail: davidb@verisign.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Weiler & Blacka              Standards Track                   [Page 21]
+