doc: Add RFC documents

1 files changed, 619 insertions, 0 deletions

diff --git a/doc/rfc/rfc5074.txt b/doc/rfc/rfc5074.txt
new file mode 100644
index 0000000..4aad851
--- /dev/null
+++ b/doc/rfc/rfc5074.txt
@@ -0,0 +1,619 @@
+
+
+
+
+
+
+Network Working Group                                          S. Weiler
+Request for Comments: 5074                                  SPARTA, Inc.
+Category: Informational                                    November 2007
+
+
+                   DNSSEC Lookaside Validation (DLV)
+
+Status of This Memo
+
+   This memo provides information for the Internet community.  It does
+   not specify an Internet standard of any kind.  Distribution of this
+   memo is unlimited.
+
+Abstract
+
+   DNSSEC Lookaside Validation (DLV) is a mechanism for publishing DNS
+   Security (DNSSEC) trust anchors outside of the DNS delegation chain.
+   It allows validating resolvers to validate DNSSEC-signed data from
+   zones whose ancestors either aren't signed or don't publish
+   Delegation Signer (DS) records for their children.
+
+Table of Contents
+
+   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 2
+   2.  Architecture  . . . . . . . . . . . . . . . . . . . . . . . . . 2
+   3.  DLV Domains . . . . . . . . . . . . . . . . . . . . . . . . . . 3
+   4.  Overview of Validator Behavior  . . . . . . . . . . . . . . . . 3
+   5.  Details of Validator Behavior . . . . . . . . . . . . . . . . . 4
+   6.  Aggressive Negative Caching . . . . . . . . . . . . . . . . . . 5
+     6.1.  Implementation Notes  . . . . . . . . . . . . . . . . . . . 5
+   7.  Overlapping DLV Domains . . . . . . . . . . . . . . . . . . . . 6
+   8.  Optimization  . . . . . . . . . . . . . . . . . . . . . . . . . 7
+   9.  Security Considerations . . . . . . . . . . . . . . . . . . . . 7
+   10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8
+   11. References  . . . . . . . . . . . . . . . . . . . . . . . . . . 8
+     11.1. Normative References  . . . . . . . . . . . . . . . . . . . 8
+     11.2. Informative References  . . . . . . . . . . . . . . . . . . 9
+   Appendix A.  Acknowledgments  . . . . . . . . . . . . . . . . . . .10
+
+
+
+
+
+
+
+
+
+
+
+
+
+Weiler                       Informational                      [Page 1]
+
+RFC 5074                          DLV                      November 2007
+
+
+1.  Introduction
+
+   DNSSEC [RFC4033] [RFC4034] [RFC4035] authenticates DNS data by
+   building public-key signature chains along the DNS delegation chain
+   from a trust anchor.
+
+   In the present world, with the DNS root and many key top level
+   domains unsigned, the only way for a validating resolver
+   ("validator") to validate the many DNSSEC-signed zones is to maintain
+   a sizable collection of preconfigured trust anchors.  Maintaining
+   multiple preconfigured trust anchors in each DNSSEC-aware validator
+   presents a significant management challenge.
+
+   This document describes a way to publish trust anchors in the DNS
+   outside of the normal delegation chain, as a way to easily configure
+   many validators within an organization or to "outsource" trust anchor
+   management.
+
+   Some design trade-offs leading to the mechanism presented here are
+   described in [INI1999-19].
+
+   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 [RFC2119].
+
+2.  Architecture
+
+   DNSSEC Lookaside Validation allows a set of domains, called "DLV
+   domains", to publish secure entry points for zones that are not their
+   own children.
+
+   With DNSSEC, validators may expect a zone to be secure when
+   validators have one of two things: a preconfigured trust anchor for
+   the zone or a validated Delegation Signer (DS) record for the zone in
+   the zone's parent (which presumes a preconfigured trust anchor for
+   the parent or another ancestor).  DLV adds a third mechanism: a
+   validated entry in a DLV domain (which presumes a preconfigured trust
+   anchor for the DLV domain).  Whenever a DLV domain contains a DLV
+   RRset for a zone, a validator may expect the named zone to be signed.
+   Absence of a DLV RRset for a zone does not necessarily mean that the
+   zone should be expected to be insecure; if the validator has another
+   reason to believe the zone should be secured, validation of that
+   zone's data should still be attempted.
+
+
+
+
+
+
+
+
+Weiler                       Informational                      [Page 2]
+
+RFC 5074                          DLV                      November 2007
+
+
+3.  DLV Domains
+
+   A DLV domain includes trust statements about descendants of a single
+   zone, called the 'target' zone.  For example, the DLV domain
+   trustbroker.example.com could target the org zone and the DLV domain
+   bar.example.com could target the root.
+
+   A DLV domain contains one or more DLV records [RFC4431] for each of
+   the target's descendant zones that have registered security
+   information with it.  For a given zone, the corresponding name in the
+   DLV domain is formed by replacing the target zone name with the DLV
+   domain name.
+
+   For example, assuming the DLV domain trustbroker.example.com targets
+   the org zone, any DLV records corresponding to the zone example.org
+   can be found at example.trustbroker.example.com.  DLV records
+   corresponding to the org zone can be found at the apex of
+   trustbroker.example.com.
+
+   As another example, assuming the DLV domain bar.example.com targets
+   the root zone, DLV records corresponding to the zone example.org can
+   be found at example.org.bar.example.com.  DLV records corresponding
+   to the org zone can be found at org.bar.example.com, and DLV records
+   corresponding to the root zone itself can be found at the apex of
+   bar.example.com.
+
+   A DLV domain need not contain data other than DLV records,
+   appropriate DNSSEC records validating that data, the apex NS and SOA
+   records, and, optionally, delegations.  In most cases, the operator
+   of a DLV domain will probably not want to include any other RR types
+   in the DLV domain.
+
+   To gain full benefit from aggressive negative caching, described in
+   Section 6, a DLV domain SHOULD NOT use minimally-covering NSEC
+   records, as described in [RFC4470], and it SHOULD NOT use NSEC3
+   records, as described in [NSEC3].
+
+4.  Overview of Validator Behavior
+
+   To minimize the load on the DLV domain's authoritative servers as
+   well as query response time, a validator SHOULD first attempt
+   validation using any applicable (non-DLV) trust anchors.  If the
+   validation succeeds (with a result of Secure), DLV processing need
+   not occur.
+
+   When configured with a trust anchor for a DLV domain, a validator
+   SHOULD attempt to validate all responses at and below the target of
+   that DLV domain.
+
+
+
+Weiler                       Informational                      [Page 3]
+
+RFC 5074                          DLV                      November 2007
+
+
+   To do validation using DLV, a validator looks for a (validated) DLV
+   RRset applicable to the query, as described in the following section,
+   and uses it as though it were a DS RRset to validate the answer using
+   the normal procedures in Section 5 of RFC 4035.
+
+   For each response, the validator attempts validation using the
+   "closest enclosing" DLV RRset in the DLV domain, which is the DLV
+   RRset with the longest name that matches the query or could be an
+   ancestor of the QNAME.  For example, assuming the DLV domain
+   trustbroker.example.com targets the org zone, and there exist DLV
+   RRsets named trustbroker.example.com (applicable to org),
+   example.trustbroker.example.com (applicable to example.org), and
+   sub.example.trustbroker.example.com (applicable to sub.example.org),
+   a validator would use the sub.example.trustbroker.example.com DLV
+   RRset for validating responses to a query for sub.example.org.
+
+   The choice of which DLV record(s) to use has a significant impact on
+   the query load seen at DLV domains' authoritative servers.  The
+   particular DLV selection rule described in this document results in a
+   higher query load than some other selection rules, but it has some
+   advantages in terms of the security policies that it can implement.
+   More detailed discussion of this DLV selection rule as well as
+   several alternatives that were considered along the way can be found
+   in [INI1999-19].
+
+5.  Details of Validator Behavior
+
+   As above, to minimize the load on the DLV domain's authoritative
+   servers as well as query response time, a validator SHOULD first
+   attempt validation using any applicable (non-DLV) trust anchors.  If
+   the validation succeeds (with a result of Secure), DLV processing
+   need not occur.
+
+   To find the closest enclosing DLV RRset for a given query, the
+   validator starts by looking for a DLV RRset corresponding to the
+   QNAME.  If it doesn't find a DLV RRset for that name (as confirmed by
+   the presence of a validated NSEC record) and that name is not the
+   apex of the DLV domain, the validator removes the leading label from
+   the name and tries again.  This process is repeated until a DLV RRset
+   is found or it is proved that there is no enclosing DLV RRset
+   applicable to the QNAME.  In all cases, a validator SHOULD check its
+   cache for the desired DLV RRset before issuing a query.  Section 8
+   discusses a slight optimization to this strategy.
+
+   Having found the closest enclosing DLV RRset or received proof that
+   no applicable DLV RRset exists, the validator MUST validate the RRset
+   or non-existence proof using the normal procedures in Section 5 of
+   RFC 4035.  In particular, any delegations within the DLV domain need
+
+
+
+Weiler                       Informational                      [Page 4]
+
+RFC 5074                          DLV                      November 2007
+
+
+   to be followed, with normal DNSSEC validation applied.  If validation
+   of the DLV RRset leads to a result of Bogus, then it MUST NOT be used
+   and the validation result for the original response SHOULD be Bogus,
+   also.  If validation of the DLV RRset leads to a result of Insecure
+   (i.e., the DLV record is in an unsecured portion of the DLV domain),
+   then it MUST NOT be used and the validation result for the original
+   response SHOULD be Insecure, also.  (It should be very odd, indeed,
+   to find part of a DLV domain marked as Insecure: this is likely to
+   happen only when there are delegations within the DLV domain and some
+   portions of that domain use different cryptographic signing
+   algorithms.)  If the validation of the DLV RRset leads to a result of
+   Secure, the validator then treats that DLV RRset as though it were a
+   DS RRset for the applicable zone and attempts validation using the
+   procedures described in Section 5 of RFC 4035.
+
+   In the interest of limiting complexity, validators SHOULD NOT attempt
+   to use DLV to validate data from another DLV domain.
+
+6.  Aggressive Negative Caching
+
+   To minimize load on authoritative servers for DLV domains,
+   particularly those with few entries, DLV validators SHOULD implement
+   aggressive negative caching, as defined in this section.
+
+   Previously, cached negative responses were indexed by QNAME, QCLASS,
+   QTYPE, and the setting of the CD bit (see RFC 4035, Section 4.7), and
+   only queries matching the index key would be answered from the cache.
+   With aggressive negative caching, the validator, in addition to
+   checking to see if the answer is in its cache before sending a query,
+   checks to see whether any cached and validated NSEC record denies the
+   existence of the sought record(s).
+
+   Using aggressive negative caching, a validator will not make queries
+   for any name covered by a cached and validated NSEC record.
+   Furthermore, a validator answering queries from clients will
+   synthesize a negative answer whenever it has an applicable validated
+   NSEC in its cache unless the CD bit was set on the incoming query.
+
+6.1.  Implementation Notes
+
+   Implementing aggressive negative caching suggests that a validator
+   will need to build an ordered data structure of NSEC records in order
+   to efficiently find covering NSEC records.  Only NSEC records from
+   DLV domains need to be included in this data structure.
+
+
+
+
+
+
+
+Weiler                       Informational                      [Page 5]
+
+RFC 5074                          DLV                      November 2007
+
+
+   Also note that some DLV validator implementations do not synthesize
+   negative answers to insert into outgoing responses -- they only use
+   aggressive negative caching when looking up DLV RRs as part of their
+   internal DLV validation.
+
+7.  Overlapping DLV Domains
+
+   It is possible to have multiple DLV domains targeting overlapping
+   portions of the DNS hierarchy.  For example, two DLV domains, perhaps
+   operated by different parties, might target the org zone, or one DLV
+   domain might target the root while another targets org.
+
+   If a validator supports multiple DLV domains, the choice of
+   precedence in case of overlap is left up to the implementation and
+   SHOULD be exposed as a configuration option to the user (as compared
+   to the choice of DLV records within each domain, a precedence for
+   which is clearly specified in this document).  As a very simple
+   default, a validator could give precedence to the most specific DLV
+   domain.
+
+   Some other reasonable options include:
+
+   1.  Searching all applicable DLV domains until an applicable DLV
+       record is found that results in a successful validation of the
+       response.  In the case where no applicable DLV record is found in
+       any DLV domain, the answer will be treated as Unsecure.
+
+   2.  Applying some sort of precedence to the DLV domains based on
+       their perceived trustworthiness.
+
+   3.  Searching all applicable DLV domains for applicable DLV records
+       and using only the most specific of those DLV records.
+
+   4.  If multiple DLV domains provide applicable DLV records, use a
+       threshold or scoring system (e.g., "best 2 out of 3") to
+       determine the validation result.
+
+   The above list is surely not complete, and it's possible for
+   validators to have different precedence rules and configuration
+   options for these cases.  [INI1999-19] discusses different policies
+   for selecting from multiple DLV records within the same DLV domain.
+   That discussion may also be applicable to the question of which DLV
+   domain to use and may be of interest to implementers of validators
+   that support multiple DLV domains.
+
+
+
+
+
+
+
+Weiler                       Informational                      [Page 6]
+
+RFC 5074                          DLV                      November 2007
+
+
+8.  Optimization
+
+   This section documents an optimization to further reduce query load
+   on DLV servers and improve validator response time.
+
+   Authoritative servers, when processing a query for a DLV RRset,
+   SHOULD include all DLV RRsets potentially applicable to a query
+   (specifically, all DLV RRsets applicable to the QNAME and any of its
+   ancestors) in the Additional section of the response as well as NSEC
+   records proving the non-existence of any other applicable DLV records
+   in the DLV domain.  Authoritative servers need only include DLV
+   RRsets they're aware of -- RRsets in sub-zones may be omitted.
+
+   Validators still seek out of the closest enclosing DLV RRset first.
+   If they receive any data about other DLV RRsets in the zone, they MAY
+   cache and use it (assuming that it validates), thus avoiding further
+   round-trips to the DLV domain's authoritative servers.
+
+9.  Security Considerations
+
+   Validators MUST NOT use a DLV record unless it has been successfully
+   authenticated.  Normally, validators will have a trust anchor for the
+   DLV domain and use DNSSEC to validate the data in it.
+
+   Aggressive negative caching increases the need for validators to do
+   some basic validation of incoming NSEC records before caching them.
+   In particular, the 'next name' field in the NSEC record MUST be
+   within the zone that generated (and signed) the NSEC.  Otherwise, a
+   malicious zone operator could generate an NSEC that reaches out of
+   its zone -- into its ancestor zones, even up into the root zone --
+   and use that NSEC to spoof away any name that sorts after the name of
+   the NSEC.  We call these overreaching NSECs.  More insidiously, an
+   attacker could use an overreaching NSEC in combination with a signed
+   wildcard record to substitute a signed positive answer in place of
+   the real data.  This checking is not a new requirement -- these
+   attacks are a risk even without aggressive negative caching.
+   However, aggressive negative caching makes the checking more
+   important.  Before aggressive negative caching, NSECs were cached
+   only as metadata associated with a particular query.  An overreaching
+   NSEC that resulted from a broken zone signing tool or some
+   misconfiguration would only be used by a cache for those queries that
+   it had specifically made before.  Only an overreaching NSEC actively
+   served by an attacker could cause misbehavior.  With aggressive
+   negative caching, an overreaching NSEC can cause broader problems
+   even in the absence of an active attacker.  This threat can be easily
+   mitigated by checking the bounds on the NSEC.
+
+
+
+
+
+Weiler                       Informational                      [Page 7]
+
+RFC 5074                          DLV                      November 2007
+
+
+   As a reminder, validators MUST NOT use the mere presence of an RRSIG
+   or apex DNSKEY RRset as a trigger for doing validation, whether
+   through the normal DNSSEC hierarchy or DLV.  Otherwise, an attacker
+   might perpetrate a downgrade attack by stripping off those RRSIGs or
+   DNSKEYs.
+
+   Section 8 of RFC 4034 describes security considerations specific to
+   the DS RR.  Those considerations are equally applicable to DLV RRs.
+   Of particular note, the key tag field is used to help select DNSKEY
+   RRs efficiently, but it does not uniquely identify a single DNSKEY
+   RR.  It is possible for two distinct DNSKEY RRs to have the same
+   owner name, the same algorithm type, and the same key tag.  An
+   implementation that uses only the key tag to select a DNSKEY RR might
+   select the wrong public key in some circumstances.
+
+   For further discussion of the security implications of DNSSEC, see
+   RFCs 4033, 4034, and 4035.
+
+10.  IANA Considerations
+
+   DLV makes use of the DLV resource record (RR type 32769) previously
+   assigned in [RFC4431].
+
+11.  References
+
+11.1.  Normative References
+
+   [RFC2119]     Bradner, S., "Key words for use in RFCs to Indicate
+                 Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [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.
+
+   [RFC4431]     Andrews, M. and S. Weiler, "The DNSSEC Lookaside
+                 Validation (DLV) DNS Resource Record", RFC 4431,
+                 February 2006.
+
+
+
+
+
+
+Weiler                       Informational                      [Page 8]
+
+RFC 5074                          DLV                      November 2007
+
+
+11.2.  Informative References
+
+   [INI1999-19]  Weiler, S., "Deploying DNSSEC Without a Signed Root",
+                 Technical Report 1999-19, Information Networking
+                 Institute, Carnegie Mellon University, April 2004.
+
+   [NSEC3]       Laurie, B., Sisson, G., Arends, R., and D. Blacka,
+                 "DNSSEC Hashed Authenticated Denial of Existence", Work
+                 in Progress, July 2007.
+
+   [RFC4470]     Weiler, S. and J. Ihren, "Minimally Covering NSEC
+                 Records and DNSSEC On-line Signing", RFC 4470,
+                 April 2006.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Weiler                       Informational                      [Page 9]
+
+RFC 5074                          DLV                      November 2007
+
+
+Appendix A.  Acknowledgments
+
+   Johan Ihren, Paul Vixie, and Suzanne Woolf contributed significantly
+   to the exploration of possible validator algorithms that led to this
+   design.  More about those explorations is documented in [INI1999-19].
+
+   Johan Ihren and the editor share the blame for aggressive negative
+   caching.
+
+   Thanks to David B. Johnson and Marvin Sirbu for their patient review
+   of [INI1999-19] which led to this specification being far more
+   complete.
+
+   Thanks to Mark Andrews, Rob Austein, David Blacka, Stephane
+   Bortzmeyer, Steve Crocker, Wes Hardaker, Alfred Hoenes, Russ Housley,
+   Peter Koch, Olaf Kolkman, Juergen Quittek, and Suzanne Woolf for
+   their valuable comments on this document.
+
+Author's Address
+
+   Samuel Weiler
+   SPARTA, Inc.
+   7110 Samuel Morse Drive
+   Columbia, Maryland  21046
+   US
+
+   EMail: weiler@tislabs.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Weiler                       Informational                     [Page 10]
+
+RFC 5074                          DLV                      November 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.
+
+
+
+
+
+
+
+
+
+
+
+
+Weiler                       Informational                     [Page 11]
+