GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc5074

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]

/data/webs/external/dokuwiki/data/pages/rfc/rfc5074.txt · Last modified: 2007/11/08 00:57 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki