RFC 8198

Aggressive Use of DNSSEC-Validated Cache

📅 published July 2017, from ietf

Aggressive Use of DNSSEC-Validated Cache

Internet Engineering Task Force (IETF) · K. Fujiwara (JPRS), A. Kato (Keio/WIDE), W. Kumari (Google) · Request for Comments: 8198 · July 2017 · Category: Standards Track · ISSN: 2070-1721

Okay bestie, let's get the title block sorted first 💅✨ This is RFC 8198, written by K. Fujiwara from JPRS, A. Kato from Keio/WIDE, and W. Kumari from Google, all dated July 2017. It's a Standards Track doc 🎀 and it updates RFC 4035 🔥. Nothing in here obsoletes anything, so no drama there 🙈

Abstract

The DNS relies upon caching to scale 🌸 but the cache lookup usually needs an exact match, which is kind of a bummer 😭 This doc specifies using NSEC/NSEC3 resource records so that DNSSEC-validating resolvers can generate negative answers for a whole range, and positive answers from wildcards 🧚 The payoff is better performance, lower latency, less resource use on both authoritative and recursive servers, and more privacy 💜 It may also help with certain DoS attacks in some situations 🛡️

This document updates RFC 4035 by letting validating resolvers generate negative answers from NSEC/NSEC3 records, and positive answers when wildcards are involved 🦋

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, received public review, and was approved for publication by the Internet Engineering Steering Group (IESG) 👑 More info on Internet Standards is in Section 2 of RFC 7841.

Info about the current status of this document, any errata, and how to give feedback can be found at http://www.rfc-editor.org/info/rfc8198.

Copyright (c) 2017 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 carefully, since 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 🎀

Table of Contents

1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
3.  Problem Statement . . . . . . . . . . . . . . . . . . . . . .   3
4.  Background  . . . . . . . . . . . . . . . . . . . . . . . . .   4
5.  Aggressive Use of DNSSEC-Validated Cache  . . . . . . . . . .   6
  5.1.  NSEC  . . . . . . . . . . . . . . . . . . . . . . . . . .   6
  5.2.  NSEC3 . . . . . . . . . . . . . . . . . . . . . . . . . .   6
  5.3.  Wildcards . . . . . . . . . . . . . . . . . . . . . . . .   6
  5.4.  Consideration on TTL  . . . . . . . . . . . . . . . . . .   7
6.  Benefits  . . . . . . . . . . . . . . . . . . . . . . . . . .   7
7.  Update to RFC 4035  . . . . . . . . . . . . . . . . . . . . .   8
8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   9
9.  Security Considerations . . . . . . . . . . . . . . . . . . .   9
10. References  . . . . . . . . . . . . . . . . . . . . . . . . .   9
  10.1.  Normative References . . . . . . . . . . . . . . . . . .   9
  10.2.  Informative References . . . . . . . . . . . . . . . . .  10
Appendix A.  Detailed Implementation Notes  . . . . . . . . . . .  11
Appendix B.  Procedure for Determining ENT vs. NXDOMAIN with NSEC  11
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  12
Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  13

1. Introduction ✨

Okay so the DNS has a negative cache 🙈 which remembers the fact that an RRset doesn't exist. The catch is that this style of negative caching needs an exact match 😭 That leads to extra lookups nobody asked for, more latency, extra resource use on both authoritative and recursive servers, and less privacy because queries leak 🫠

This document updates RFC 4035 so resolvers can use NSEC/NSEC3 resource records to synthesize negative answers from what's already in the cache 💅 That means a validating resolver can respond with a negative answer right away if the name falls inside a range covered by an NSEC/NSEC3 record already cached 🌈 It also lets resolvers synthesize positive answers when wildcard records are present 🦋

Aggressive negative caching was first proposed in Section 6 of DNSSEC Lookaside Validation (DLV) [RFC5074] to find covering NSEC records efficiently 🧚

[RFC8020] and [RES-IMPROVE] suggest steps for using NXDOMAIN information for more effective caching 💜 This document takes that idea even further 🔥

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 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

Lots of the specialized terms used here are defined in DNS Terminology [RFC7719] 📖

The key words "source of synthesis" in this document are to be interpreted as described in [RFC4592] 🌸

3. Problem Statement 🙈

The DNS negative cache stores negative (non-existent) info and needs an exact match in most cases [RFC2308] 😩

Picture the (DNSSEC-signed) "example.com" zone 🍓 It has:

albatross.example.com. IN A 192.0.2.1
elephant.example.com.  IN A 192.0.2.2
zebra.example.com.     IN A 192.0.2.3

If a validating resolver gets a query for cat.example.com, it asks its resolver (which might be itself) to query the example.com servers 📡 It gets back an NSEC record saying there are no records (alphabetically) between albatross and elephant, or an NSEC3 record saying there's nothing between two hashed names 🦋 So the resolver knows cat.example.com doesn't exist 💅 BUT it doesn't use the fact that the proof covers a whole range (albatross to elephant) to skip queries for other labels in that range 😭 So if the validating resolver then gets a query for ball.example.com (or dog.example.com), it goes right back out and queries the example.com servers for those names again 🙃

That's not just wasted bandwidth 💀 It also wastes resources on the recursive server (it has to keep state for outstanding queries), wastes resources on the authoritative server (it has to answer extra questions), adds latency (the end user waits longer than necessary for an NXDOMAIN answer), can be used by attackers to cause a DoS, and has privacy implications (e.g., typos leak out further than necessary) 🫣

Another example! Picture the (DNSSEC-signed) "example.org" zone 🌈

avocado.example.org.   IN A 192.0.2.1
*.example.org.         IN A 192.0.2.2
zucchini.example.org.  IN A 192.0.2.3

If a query comes in for leek.example.org, the system asks its resolver (which might be itself) to query the example.org servers 🥑 It gets back an NSEC record saying there are no records (alphabetically) between avocado and zucchini (or an NSEC3 record saying there's nothing between two hashed names), plus an answer for leek.example.org, with the label count of the signature set to two (see [RFC7129], Section 5.3 for more details) ✨

If the validating resolver then gets a query for banana.example.org, it goes off and queries the example.org servers for banana.example.org (even though it already has proof there's a wildcard record) 😤 Just like before, this has privacy implications, wastes resources, can contribute to a DoS, and so on 💔

4. Background 📚

DNSSEC [RFC4035] and [RFC5155] both provide "authenticated denial of existence" 🔐 This is a cryptographic proof that the queried-for name doesn't exist, or that the type doesn't exist. Proving a name doesn't exist works by providing a (DNSSEC-secured) record with the names that sit alphabetically before and after the queried-for name 🧚 In the first example, if the (DNSSEC-validating) recursive server queried for dog.example.com, it would get a (signed) NSEC record saying there are no labels between "albatross" and "elephant" (or, for NSEC3, a similar pair of hashed names) 💜 That's a signed, cryptographic proof that these names are the ones before and after the queried-for label 🙌 Since dog.example.com falls in that range, the recursive server knows dog.example.com really doesn't exist 🫶 Proving a type doesn't exist works by providing a (DNSSEC-secured) record containing the queried-for name, plus a type bitmap that doesn't include the requested type 🎀

This document says the NSEC/NSEC3 record should be used to generate negative answers for any queries the validating server receives that fall within the range covered by the record (for the TTL for the record) 🌸 It also says a positive answer should be generated for any queries the validating server receives that are proven to be covered by a wildcard record 🦋

Section 4.5 of [RFC4035] says:

In theory, a resolver could use wildcards or NSEC RRs to generate positive and negative responses (respectively) until the TTL or signatures on the records in question expire. However, it seems prudent for resolvers to avoid blocking new authoritative data or synthesizing new data on their own. Resolvers that follow this recommendation will have a more consistent view of the namespace.

And, earlier, Section 4.5 of [RFC4035] says:

The reason for these recommendations is that, between the initial query and the expiration of the data from the cache, the authoritative data might have been changed (for example, via dynamic update).

In other words, if a resolver generates negative answers from an NSEC record, it won't send any queries for names in that NSEC range (for the TTL) 🙅‍♀️ If a new name gets added to the zone during this interval, the resolver won't know 😬 Similarly, if the resolver is generating responses from a wildcard record, it'll keep doing that (for the TTL) 🔁

We think this recommendation can be relaxed 💅 Without this technique, a lookup for the exact name could have come in during this interval, so a negative answer could already be cached (see [RFC2308] for more background) 🧠 That means zone operators shouldn't expect a newly added name to work immediately 🫠 With DNSSEC and aggressive use of DNSSEC-validated cache, the TTL of the NSEC/NSEC3 record and the SOA.MINIMUM field are the authoritative statement of how fast a name can start working within a zone ⏰

Part 1 of 3 is done, bestie 🎀 Part 2 is coming next with Section 5 and the NSEC/NSEC3/wildcard details, so stay tuned 💖🦋

5. Aggressive Use of DNSSEC-Validated Cache ✨

okay so this document is about to relax a rule from [RFC4035]. the restriction is in Section 4.5 of [RFC4035], and you'll get the full tea in Section 7 🫶

if the validating resolver's negative cache already has enough info to validate a query, it SHOULD use NSEC, NSEC3, and wildcard records to synthesize answers the way this document describes 💅 if it doesn't have enough, it MUST fall back and send the query to the authoritative DNS servers. no skipping that step 🙅‍♀️

5.1. NSEC

the validating resolver needs to check that an NSEC RR matching/covering the source of synthesis exists, and that an NSEC RR covers the query name ✨

if the denial of existence can be determined using the NSEC records in the cache, following the rules in Section 5.4 of [RFC4035], then the resolver can immediately return an NXDOMAIN or NODATA response (whichever fits) 🦋

5.2. NSEC3

NSEC3 aggressive negative caching is harder than NSEC aggressive caching, ngl 😭 if the zone is signed with NSEC3, the validating resolver has to check that the non-terminals and wildcards deriving from the query names exist 🧚

if the denial of existence can be determined using the NSEC3 records in the cache, following the rules in [RFC5155], Sections 8.4, 8.5, 8.6, and 8.7, then the resolver can immediately return an NXDOMAIN or NODATA response (as appropriate) 🌸

⚠️ if a covering NSEC3 RR has an Opt-Out flag, that covering NSEC3 RR does NOT prove the non-existence of the domain name. so aggressive negative caching is not possible for that domain name. bestie, don't go there 💀

5.3. Wildcards

the last paragraph of [RFC4035], Section 4.5 also talks about using wildcards and NSEC RRs to generate positive responses, and it recommends that this not be relied upon. same energy as the NSEC/NSEC3 negative answers, so we're revising that recommendation too 🎀

as long as the validating resolver can tell that a name would not exist without the wildcard match (following Section 5.3.4 of [RFC4035] for NSEC, or Section 8.8 of [RFC5155] for NSEC3), it SHOULD synthesize an answer (or NODATA response) for that name using the wildcard it deduced from the cache 🔥 if the matching wildcard record isn't in the cache, it MUST fall back and send the query to the authoritative DNS servers.

5.4. Consideration on TTL

the TTL of negative info is a BIG deal, because newly added domain names can't be used while the negative info is still effective 😤

Section 5 of [RFC2308] suggests a maximum default negative cache TTL value of 3 hours (10800). it is RECOMMENDED that validating resolvers limit the maximum effective TTL of negative responses (NSEC/NSEC3 RRs) to this same value 🌈

Section 5 of [RFC2308] also says a negative cache entry TTL comes from the minimum of the SOA.MINIMUM field and the SOA's TTL. this can be less than the TTL of an NSEC or NSEC3 record, since their TTL is equal to the SOA.MINIMUM field (see [RFC4035], Section 2.3 and [RFC5155], Section 3) 🧠

a resolver that supports aggressive use of NSEC and NSEC3 SHOULD reduce the TTL of NSEC and NSEC3 records to match the SOA.MINIMUM field in the authority section of a negative response, if SOA.MINIMUM is smaller 💖

6. Benefits

the techniques in this document come with a bunch of perks, listed in no specific order 👑

  • Reduced latency: by answering straight from cache, validating resolvers can immediately tell clients that the name they want doesn't exist, which makes the user experience way smoother ✨
  • Decreased recursive server load: by answering queries from cache through synthesis, validating servers skip sending a query and waiting for a response. on top of cutting bandwidth, the server also doesn't need to allocate and maintain state, so memory and CPU load go down 🧚
  • Decreased authoritative server load: since recursive servers can answer without asking the authoritative server, the authoritative servers get fewer queries. that means less authoritative bandwidth, fewer queries per second, and lower CPU utilization 🦋

how big the benefit is depends on several factors, including the query distribution. for example, at the time of writing, around 65% of queries to root name servers result in NXDOMAIN responses (see statistics from [ROOT-SERVERS]). this technique will eliminate a sizable chunk of those 🍓

this technique may also help with so-called "random QNAME attacks", where attackers send tons of queries for random subdomains to resolvers 😬 since the resolver won't have those answers cached, it has to ask external servers for every random query, which can cause a DoS on the authoritative servers (and often the resolvers too). the technique may help by letting the resolver answer random queries straight from cache when they fall within ranges that were already requested. it won't always work as an effective defense, not least because not many zones are DNSSEC signed at all, but it still adds an extra layer of defense 🛡️

these benefits only come to those using DNSSEC, so hopefully these techniques will lead to more DNSSEC deployment 🌸

7. Update to RFC 4035

Section 4.5 of [RFC4035] says: "In theory, a resolver could use wildcards or NSEC RRs to generate positive and negative responses (respectively) until the TTL or signatures on the records in question expire. However, it seems prudent for resolvers to avoid blocking new authoritative data or synthesizing new data on their own. Resolvers that follow this recommendation will have a more consistent view of the namespace".

the paragraph gets updated like this 💅

+-----------------------------------------------------------------+
|  Once the records are validated, DNSSEC-enabled validating      |
|  resolvers SHOULD use wildcards and NSEC/NSEC3 resource records |
|  to generate positive and negative responses until the          |
|  effective TTLs or signatures for those records expire.         |
+-----------------------------------------------------------------+

8. IANA Considerations ✨

this document doesn't require any IANA actions. no paperwork, bestie 📝

9. Security Considerations 💀

okay this section is serious, so listen up 🫶

use of NSEC/NSEC3 resource records without DNSSEC validation may create serious security issues, so this technique REQUIRES DNSSEC validation. (keeping the wording exact here: this technique requires DNSSEC validation.) no validation, no aggressive caching 🚫

newly registered resource records may not be usable immediately. however, choosing a suitable TTL value and a negative cache TTL value (the SOA.MINIMUM field) will reduce the delay concern, and it is not a security problem 🌈

it is also suggested to limit the maximum TTL of NSEC/NSEC3 resource records in the negative cache to, for example, 10800 seconds (3 hours), to mitigate this issue 🍓

although the TTL of NSEC/NSEC3 records is usually pretty short (minutes or hours), their RRSIG expiration time can be WAY further out (weeks). an attacker who can successfully spoof responses might poison a cache with old NSEC/NSEC3 records 😱 if the resolver is NOT making aggressive use of NSEC/NSEC3, the attacker has to repeat the attack for every query. but if the resolver IS making aggressive use of NSEC/NSEC3, one successful attack could suppress many queries for new names, up until the negative TTL. the lesson: validate, and keep those TTLs in check 🔥

10. References 📚

10.1. Normative References

10.2. Informative References

Appendix A. Detailed Implementation Notes 🧁

  • 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 got answered from cache. with aggressive negative caching, the validator also checks whether any cached and validated NSEC record denies the existence of the sought record(s), on top of checking its cache before sending a query. with aggressive negative caching, a validator will not make queries for any name covered by a cached and validated NSEC record. also, a validator answering queries from clients will synthesize a negative answer (or NODATA response) whenever it has an applicable validated NSEC in its cache, unless the CD bit was set on the incoming query. (Imported from Section 6 of [RFC5074].) 🌟
  • implementing aggressive negative caching suggests that a validator will need to build an ordered data structure of NSEC and NSEC3 records for each signer domain name of NSEC/NSEC3 records, so it can efficiently find covering NSEC/NSEC3 records. call the table "NSEC_TABLE". (Imported from Section 6.1 of [RFC5074] and expanded.) 🗂️
  • aggressive negative caching may be inserted at the cache lookup part of the recursive resolvers 💅
  • if errors happen in an aggressive negative caching algorithm, resolvers MUST fall back to resolve the query as usual. "Resolve the query as usual" means that the resolver must process the query as though it does not implement aggressive negative caching. no drama, just fallback 🫶

Appendix B. Procedure for Determining ENT vs. NXDOMAIN with NSEC ✨

okay so this procedure is how you figure out whether a name is a total ghost (NXDOMAIN) or an ENT (empty non-terminal, see [RFC5155], Section 1.3) using an NSEC record 🔍 it's giving detective energy, and the clues go in order!!

Clue one: if the NSEC record hasn't been verified as secure, toss it. No cap, unverified receipts don't count 🙅‍♀️

Clue two: if the given name sorts before the NSEC owner name, or is an exact match for it, throw that NSEC out. It doesn't prove the NXDOMAIN or ENT, so it's not the vibe 💀

Clue three: if the given name is a subdomain of the NSEC owner name, the NS bit is present, and the SOA bit is absent, discard the NSEC because it came from a parent zone. not your zone, bestie 🙈

Clue four: if the next domain name sorts after the NSEC owner name, and the given name sorts after or matches the next domain name, discard that NSEC record. It doesn't prove the NXDOMAIN or ENT either 😭

Clue five: if the next domain name sorts before or matches the NSEC owner name, and the given name is not a subdomain of the next domain name, discard the NSEC. Same story, different outfit 👗

If you made it past all of that, congrats, you now have an NSEC record that proves the NXDOMAIN or ENT 🎉🎀

Last step, and it's the payoff: if the next domain name is a subdomain of the given name, you've got an ENT 🌸 Otherwise, you've got an NXDOMAIN 👻

Acknowledgments 🫶

The authors gratefully acknowledge DNSSEC Lookaside Validation (DLV) [RFC5074] author Samuel Weiler and the Unbound developers 💜

Thanks to Mark Andrews for providing the helpful notes for implementors provided in Appendix B 🍓

The authors would like to specifically thank Stephane Bortzmeyer (for standing next to and helping edit), Ralph Dolmans, Tony Finch, Tatuya JINMEI for extensive review and comments, and also Mark Andrews, Casey Deccio, Alexander Dupuy, Olafur Gudmundsson, Bob Harold, Shumon Huque, John Levine, Pieter Lexis, Matthijs Mekking (who even sent pull requests!), and Ondrej Sury 🌈✨ literally the whole squad, I'm obsessed 😭🫶

Authors' Addresses 💌

Kazunori Fujiwara Japan Registry Services Co., Ltd. Chiyoda First Bldg. East 13F, 3-8-1 Nishi-Kanda Chiyoda-ku, Tokyo 101-0065 Japan

Phone: +81 3 5215 8451 Email: fujiwara@jprs.co.jp

Akira Kato Keio University/WIDE Project Graduate School of Media Design, 4-1-1 Hiyoshi Kohoku, Yokohama 223-8526 Japan

Phone: +81 45 564 2490 Email: kato@wide.ad.jp

Warren Kumari Google 1600 Amphitheatre Parkway Mountain View, CA 94043 United States of America

Email: warren@kumari.net 🦋

📦 where this page comes from