RFC 5074

DNSSEC Lookaside Validation (DLV) 💖

okay bestie, this is RFC 5074 🎀. It's titled "DNSSEC Lookaside Validation (DLV)" and it came out in November 2007. The author is S. Weiler from SPARTA, Inc., and it's published as Informational, which means it's sharing info with the internet community, not setting a standard. The header doesn't say it obsoletes or updates anything. It's from the Network Working Group 🦋

Status of This Memo ✨

This memo gives information to the Internet community. It doesn't specify an Internet standard of any kind. Distribution of this memo is unlimited 💅

Abstract 🌸

DNSSEC Lookaside Validation (DLV) is a way to publish DNS Security (DNSSEC) trust anchors outside of the DNS delegation chain 👀 It lets validating resolvers check DNSSEC-signed data from zones whose ancestors are either unsigned or don't publish Delegation Signer (DS) records for their kids.

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

1. Introduction ✨

okay so DNSSEC [RFC4033] [RFC4034] [RFC4035] checks DNS data by building public-key signature chains down the DNS delegation chain, starting from a trust anchor 🔐

Right now the DNS root and lots of major top-level domains are unsigned 😭 So the only way for a validating resolver (a "validator") to check all the many DNSSEC-signed zones is to keep a big pile of preconfigured trust anchors around. Managing a bunch of preconfigured trust anchors in every DNSSEC-aware validator is a major headache 💀

This doc describes a way to publish trust anchors in the DNS, outside the normal delegation chain 🎀 It makes it way easier to configure lots of validators inside an organization, or to "outsource" trust anchor management entirely 🫶

The design trade-offs behind this mechanism are covered in [INI1999-19] if you want the deep dive 🤓

The BCP 14 key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be read as described in RFC 2119 [RFC2119] 📖

2. Architecture 🏛️

DNSSEC Lookaside Validation lets a set of domains, called "DLV domains", publish secure entry points for zones that aren't their own children 👑

With DNSSEC, validators can expect a zone to be secure if they 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 assumes a preconfigured trust anchor for the parent or some other ancestor) ✨ DLV adds a third option: a validated entry in a DLV domain (which assumes a preconfigured trust anchor for the DLV domain) 🦋 Whenever a DLV domain has a DLV RRset for a zone, a validator may expect that named zone to be signed. Not having a DLV RRset for a zone doesn't automatically mean the zone should be treated as insecure 🙈 If the validator has some other reason to think the zone should be secured, it should still try to validate that zone's data.

3. DLV Domains 🌸

A DLV domain holds 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 their security info with it 💅 For a given zone, the matching name in the DLV domain is made by swapping the target zone name for the DLV domain name.

Here's an example: say the DLV domain trustbroker.example.com targets the org zone. Then any DLV records for example.org can be found at example.trustbroker.example.com. DLV records for the org zone can be found at the apex of trustbroker.example.com ✨

Another one: say the DLV domain bar.example.com targets the root zone. Then DLV records for example.org can be found at example.org.bar.example.com. DLV records for org can be found at org.bar.example.com, and DLV records for the root zone itself can be found at the apex of bar.example.com 🧚

A DLV domain doesn't need any data except DLV records, the DNSSEC records that validate that data, the apex NS and SOA records, and, optionally, delegations. Honestly, the operator of a DLV domain probably won't want any other RR types in there 💖

To get the full benefit of aggressive negative caching (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]. Keep it clean, bestie 🫶

4. Overview of Validator Behavior 🔥

To keep the load on the DLV domain's authoritative servers low, and query response times fast, a validator SHOULD first try validation using any applicable (non-DLV) trust anchors 💨 If validation succeeds (with a result of Secure), DLV processing doesn't need to happen at all 🙌

When a validator is configured with a trust anchor for a DLV domain, it SHOULD try to validate all responses at and below the target of that DLV domain 👀

To validate using DLV, a validator looks for a (validated) DLV RRset that applies to the query, as described in the next section 🔍 It treats that RRset as though it were a DS RRset, and uses the normal procedures in Section 5 of RFC 4035 to validate the answer ✨

For each response, the validator tries validation using the "closest enclosing" DLV RRset in the DLV domain. That's the DLV RRset with the longest name that matches the QNAME or could be an ancestor of it 💅 For example, say the DLV domain trustbroker.example.com targets the org zone, and there are 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). Then a validator would use the sub.example.trustbroker.example.com DLV RRset to validate responses to a query for sub.example.org 🎀

Which DLV record(s) get picked makes a big difference to the query load on DLV domains' authoritative servers 😭 The DLV selection rule in this document creates a higher query load than some other selection rules 💀 But it has some perks when it comes to the security policies it can implement 🦋 More detail on this selection rule, plus several alternatives considered along the way, is in [INI1999-19].

5. Details of Validator Behavior 💜

Like before, to keep the load on the DLV domain's authoritative servers low and query response time fast, a validator SHOULD first try validation using any applicable (non-DLV) trust anchors. If validation succeeds (with a result of Secure), DLV processing doesn't need to happen 🙌

To find the closest enclosing DLV RRset for a given query, the validator starts by looking for a DLV RRset that matches the QNAME 🔍 If it doesn't find one for that name (confirmed by a validated NSEC record being present) and that name isn't the apex of the DLV domain, the validator strips the leftmost label off the name and tries again. It keeps going until it finds a DLV RRset, or proves that there's no enclosing DLV RRset that applies to the QNAME 🧚 In every case, a validator SHOULD check its cache for the DLV RRset it wants before sending a query. Section 8 talks about a small optimization to this strategy ✨

Once the validator has either found the closest enclosing DLV RRset or received proof that no applicable DLV RRset exists, it MUST validate that RRset or non-existence proof using the normal procedures in Section 5 of RFC 4035. Specifically, any delegations inside the DLV domain need to be followed, with normal DNSSEC validation applied 💅 If validating the DLV RRset gives a result of Bogus, then it MUST NOT be used, and the validation result for the original response SHOULD be Bogus too 💀 If validating the DLV RRset gives a result of Insecure (meaning the DLV record sits in an unsecured part of the DLV domain), then it MUST NOT be used, and the validation result for the original response SHOULD be Insecure as well 🙈 (It would be super weird to find part of a DLV domain marked Insecure. That'd probably only happen when there are delegations inside the DLV domain and some parts of it use different cryptographic signing algorithms.) If validating the DLV RRset gives a result of Secure, the validator then treats that DLV RRset as though it were a DS RRset for the applicable zone, and tries validation using the procedures in Section 5 of RFC 4035 👑

To keep things from getting too complicated, validators SHOULD NOT try to use DLV to validate data from another DLV domain 🫶

6. Aggressive Negative Caching 🌈

To cut down the load on authoritative servers for DLV domains, especially ones with only a few entries, DLV validators SHOULD implement aggressive negative caching, as defined in this section 💖

Before this, cached negative responses were indexed by QNAME, QCLASS, QTYPE, and the setting of the CD bit (see RFC 4035, Section 4.7). Only queries that matched the index key would get answered from the cache 🙈 With aggressive negative caching, the validator does two things: it still checks whether the answer is in its cache before sending a query, and it also checks whether any cached and validated NSEC record denies the existence of the record(s) being sought ✨

With aggressive negative caching, a validator won't send queries for any name covered by a cached and validated NSEC record 🦋 Also, when a validator answers queries from clients, it synthesizes 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 means a validator will probably need to build an ordered data structure of NSEC records so it can efficiently find covering NSEC records 🔥 Only NSEC records from DLV domains need to go into this data structure.

Also, some DLV validator implementations don't synthesize negative answers to put 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 ✨

okay so bestie, it's totally possible to have multiple DLV domains that cover overlapping parts of the DNS tree 🌳 like two DLV domains, maybe run by different people, could both be looking after the org zone 👀 or one could cover the root while another covers org. chaotic but valid 💅

If a validator supports more than one DLV domain, the choice of precedence when they overlap is left up to the implementation, and it SHOULD be exposed as a configuration option for the user 🎀 (this is different from picking DLV records within one domain, because the document clearly specifies that precedence already 🫶). As a super 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. If 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 how trustworthy they're perceived to be. 🌸
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, using a threshold or scoring system (e.g., "best 2 out of 3") to determine the validation result. 👑

The list above is surely not complete, and validators are free to have different precedence rules and configuration options for these cases ✨ [INI1999-19] talks about different policies for picking from multiple DLV records inside the same DLV domain. That discussion may also apply to choosing which DLV domain to use, so implementers of validators that support multiple DLV domains might find it super useful 🤓💖

8. Optimization ⚡

This section documents an optimization that cuts down query load on DLV servers and makes validators respond faster 🏎️💨

When an authoritative server processes a query for a DLV RRset, it SHOULD include all DLV RRsets that could potentially apply to the query (specifically, all DLV RRsets that apply to the QNAME and any of its ancestors) in the Additional section of the response 🎀 It SHOULD also include NSEC records proving that no other applicable DLV records exist in the DLV domain 🙈 Authoritative servers only need to include DLV RRsets they know about, so RRsets in sub-zones can be left out 🌸

Validators still look for the closest enclosing DLV RRset first 🧐 If they receive data about other DLV RRsets in the zone, they MAY cache and use it (assuming it validates), which means they can skip extra round-trips to the DLV domain's authoritative servers 🚀

9. Security Considerations 🔐

okay this section is serious, so listen up bestie 🫶

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 makes it more important 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 it to spoof away any name that sorts after the name of the NSEC 💀 We call these overreaching NSECs. It gets even sneakier: an attacker could combine an overreaching NSEC with a signed wildcard record to swap in a signed positive answer in place of the real data 😭 This checking is not a new requirement, because these attacks are a risk even without aggressive negative caching. However, aggressive negative caching makes the checking way more important 🚨 Before aggressive negative caching, NSECs were only cached as metadata tied to a particular query. An overreaching NSEC from a broken zone signing tool or some misconfiguration would only get used by a cache for queries 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 when there's no active attacker 😱 This threat can be easily mitigated by checking the bounds on the NSEC 🛡️

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 pull off 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 apply equally 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's 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.

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.

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

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.