[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00 01 02 03 04 RFC 5074

Network Working Group                                          S. Weiler
Internet-Draft                                              SPARTA, Inc.
Expires: August 29, 2006                               February 25, 2006


                   DNSSEC Lookaside Validation (DLV)
                     draft-weiler-dnssec-dlv-00.txt

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.
   This document may not be modified, and derivative works of it may not
   be created.

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

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

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

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

   This Internet-Draft will expire on August 29, 2006.

Copyright Notice

   Copyright (C) The Internet Society (2006).

Abstract

   DNSSEC Lookaside Validation (DLV) is a mechanism for publishing
   DNSSEC trust anchors outside of the DNS delegation chain.  It allows
   resolvers to validate DNSSEC-signed data from zones whose ancestors
   either aren't signed or refuse to publish DS records for their
   children.





Weiler                   Expires August 29, 2006                [Page 1]

Internet-Draft                     DLV                     February 2006


1.  Introduction

   DNSSEC [1] [2] [3] authenticates DNS data by building public-key
   signature chains along the DNS delegation chain from a trust anchor,
   ideally a trust anchor for the DNS root.

   This document describes a way to publish trust anchors in the DNS but
   outside of the normal delegation chain.

   Some design trade-offs leading to the mechanism presented here are
   described in [8].

   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 [4].


2.  Architecture

   DNSSEC Lookaside Validation allows a set of well-known 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 they have
   one of two things: a preconfigured trust anchor for the zone or a
   validated DS for the zone in its 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 publishes a DLV RRset for a zone, a resolver 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 resolver has another reason to believe the zone should be
   secured, validation of that zone's data should still be attempted.


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 [5] 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.




Weiler                   Expires August 29, 2006                [Page 2]

Internet-Draft                     DLV                     February 2006


   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 zone zone itself can be found at the apex of
   bar.example.com.

   A DLV domain SHOULD NOT contain data other than DLV records,
   appropriate DNSSEC records validating that data, the apex NS and SOA
   records, and, optionally, delegations.

   To gain full benefit from aggressive negative caching, described in
   section X, a DLV domain SHOULD NOT use minimally-covering NSEC
   records, as described in [6], and it SHOULD NOT use NSEC3 records, as
   described in [7]


4.  Overview of Resolver Behavior

   To minimize load on the DLV domain's authoritative servers as well as
   query response time, a resolver 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 resolver
   SHOULD attempt to validate all queries at and below the target of
   that DLV domain.

   To do validation using DLV, a resolver 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 RFC4035 Section 5.

   For each query, the resolver attempts validation using the "closest
   enclosing" DLV RRset, 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 resolver would use the
   sub.example.trustbroker.example.com DLV RRset for validating queries



Weiler                   Expires August 29, 2006                [Page 3]

Internet-Draft                     DLV                     February 2006


   for sub.example.org.

   This policy is slightly different than the one discussed in previous
   versions of this document.  More detailed discussion of this policy
   and other possible choices can be found in [8].


5.  Resolver Behavior

   As above, to minimize load on the DLV domain's authoritative servers
   as well as query response time, a resolver 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
   resolver 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 resolver 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 resolver 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 a proof that
   no applicable DLV RRset exists, the resolver MUST validate that RRset
   or non-existence proof using the normal procedures in Section 5 of
   RFC4035.  In particular, any delegations within the DLV domain need
   to be followed, with normal DNSSEC validation applied.  If validation
   of the DLV RRset leads to a result of Bogus, then it SHOULD NOT be
   used and the validation result for the original query SHOULD be
   Bogus, also.  If validation of the DLV RRset leads to a result of
   Insecure (the DLV record is in an unsecured portion of the DLV tree),
   then it SHOULD NOT be used and the validation result for the original
   query SHOULD be Insecure, also.  If the validation of the DLV RRset
   leads to a result of Secure, then resolver then treats that DLV RRset
   as though it were a DS RRset for the applicable zone and attempts
   validation using the procedures described in RFC4035 Section 5.

   To avoid confusing authors of resolvers and protocol specifications,
   a resolver SHOULD NOT attempt to validate data from a DLV domain
   using DLV.


6.  Aggressive Negative Caching




Weiler                   Expires August 29, 2006                [Page 4]

Internet-Draft                     DLV                     February 2006


   To minimize load on authoritative servers for DLV domains,
   particularly those with few entries, DLV resolvers 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 RFC4035 section 4.7) and
   only queries matching the index would be answered from the cache.
   With aggressive negative caching, the resolver, 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 resolver will not make queries
   for any name covered by a cached and validated NSEC record.
   Furthermore, a resolver 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.


7.  Overlapping DLV Domains

   It is possible to have multiple DLV domains targeting overlapping
   portion of the DNS hierarchy.  For example, two DLV domains, perhaps
   operated by different parties, might target the same zone, or one DLV
   domain might target the root while another targets .org.

   If a resolver 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 a default, it is
   suggested that the most specific DLV domain be given precedence.


8.  Optimization

   This section proposes an immature and untested proposed optimization
   to further reduce query load on DLV servers and improve resolver
   response time.  This is not intended to be an optional extension --
   if included in the final DLV specification, it must be supported by
   all DLV-aware name servers and resolvers.

   Authoritative servers, when processing a query for a DLV RRset,
   should include all DLV RRsets potentially applicable to a query 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.

   Resolvers still seek out of the closest enclosing DLV RRset first.
   Should they receive any data about other DLV RRsets in the zone, they



Weiler                   Expires August 29, 2006                [Page 5]

Internet-Draft                     DLV                     February 2006


   may cache and use it (assuming that it validates), thus avoiding
   further round-trips to the DLV domain's authoritative servers.

   This optimization may preclude the use the delegations within a DLV
   domain.


9.  Security Considerations

   Resolvers MUST NOT use a DLV record unless it has been successfully
   authenticated.  Normally, resolvers 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 resolvers 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 more broader
   problems even in the absence of an active attacker.  This threat can
   be easily mitigated by checking the bounds on the NSEC.

   As a reminder, resolvers 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.

   RFC4034 Section 8 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



Weiler                   Expires August 29, 2006                [Page 6]

Internet-Draft                     DLV                     February 2006


   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
   RFC4033, RFC4034, and RFC4035.


10.  IANA Considerations

   IANA is asked to create a DLV registry, published at dlv.iana.org or
   another suitable domain name chosen at its own discretion, targeting
   the root and include in that zone entries for any TLDs that wish to
   have DLV records published.  IANA is instructed to use its own best
   practices for authenticating TLD operators' requests to insert,
   modify, and delete DLV entries.  This DLV registry should itself be
   signed with DNSSEC.

   DLV makes use of the DLV resource record previously assigned by IANA.


11.  References

11.1.  Normative References

   [1]  Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
        "DNS Security Introduction and Requirements", RFC 4033,
        March 2005.

   [2]  Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
        "Resource Records for the DNS Security Extensions", RFC 4034,
        March 2005.

   [3]  Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
        "Protocol Modifications for the DNS Security Extensions",
        RFC 4035, March 2005.

   [4]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
        Levels", BCP 14, RFC 2119, March 1997.

   [5]  Andrews, M. and S. Weiler, "The DNSSEC Lookaside Validation
        (DLV) DNS Resource Record", RFC 4431, February 2006.

11.2.  Informative References

   [6]  Weiler, S. and J. Ihren, "Minimally Covering NSEC Records and
        DNSSEC On-line Signing",
        draft-ietf-dnsext-dnssec-online-signing-02 (work in progress),
        January 2006.



Weiler                   Expires August 29, 2006                [Page 7]

Internet-Draft                     DLV                     February 2006


   [7]  Laurie, B., "DNSSEC Hash Authenticated Denial of Existence",
        draft-ietf-dnsext-nsec3-03 (work in progress), October 2005.

   [8]  Weiler, S., "Deploying DNSSEC Without a Signed Root", Technical
        Report 1999-19, Information Networking Institute, Carnegie
        Mellon University, April 2004.


Appendix A.  Acknowledgments

   Paul Vixie, Suzanne Woolf, and Johan Ihren contributed significantly
   to the exploration of possible resolver algorithms that led to this
   design.  More about those explorations is documented in [8].

   Johan Ihren and the editor share the blame for aggressive negative
   caching.

   Thanks to David B. Johnson of Rice University and Marvin Sirbu of
   Carnegie Mellon University for their patient review of [8] which led
   to this specification being far more complete.


Appendix B.  Changes from pre00 to 00

   The primary difference between earlier versions of this draft
   (circulated privately) and the present one is the resolver policy for
   choosing DLV entries from one DLV domain, which could have a
   tremendous impact on load at the DLV domain's authoritative servers.
   This document describes a policy of "Closest Encloser Trumps", as
   described in Section 3.2.2 of [8].  The previous version described a
   policy of "Accept Any Success".




















Weiler                   Expires August 29, 2006                [Page 8]

Internet-Draft                     DLV                     February 2006


Author's Address

   Samuel Weiler
   SPARTA, Inc.
   7075 Samuel Morse Drive
   Columbia, Maryland  21046
   US

   Email: weiler@tislabs.com










































Weiler                   Expires August 29, 2006                [Page 9]

Internet-Draft                     DLV                     February 2006


Intellectual Property Statement

   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.


Disclaimer of Validity

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


Copyright Statement

   Copyright (C) The Internet Society (2006).  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.


Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.




Weiler                   Expires August 29, 2006               [Page 10]


Html markup produced by rfcmarkup 1.108, available from http://tools.ietf.org/tools/rfcmarkup/