Subject: [dnsext] draft-ietf-dnsext-dnssec-bis-updates-10 Caching BAD Data

From: "Roy Arends" <[email-masked]>
Date: Tue, 23 Mar 2010 15:21:54 -0800

Sam Weiler asked today, during his presentation on the dnssec-bis updates 
[1] document in the dnsext WG session, if the draft should reflect new 
insights due to 'rollover and die?' [2].

I highlighted, during my presentation in the WG today, on that specific 
issue.

Currently, a validating resolver is not required to cache validation 
failures, due to the MAY in the following section [3]

   4.7.  Caching BAD Data

   While many validation errors will be transient, some are likely to be
   more persistent, such as those caused by administrative error
   (failure to re-sign a zone, clock skew, and so forth).  Since
   requerying will not help in these cases, validating resolvers might
   generate a significant amount of unnecessary DNS traffic as a result
   of repeated queries for RRsets with persistent validation failures.

   To prevent such unnecessary DNS traffic, security-aware resolvers MAY
   cache data with invalid signatures, with some restrictions.

I have seen validation errors in the field, with two popular independent 
implementations, that did not cache certain validation failures, and 
subsequently became aggressive in their effort to complete a valid 
authentication chain. Though those implementations have now been updated, 
it has now been shown [2] that not caching validation failures can lead to 
severe query storms. 

My proposal is that we change the "MAY" to a "SHOULD".

Comments are appreciated.

Kind regards,

Roy Arends
Nominet

[1] http://tools.ietf.org/html/draft-ietf-dnsext-dnssec-bis-updates-10
[2] http://www.potaroo.net/ispcol/2010-02/rollover.html
[3] http://tools.ietf.org/html/rfc4035#section-4.7

---

From: Frederico A C Neves <[email-masked]>
Date: Tue, 23 Mar 2010 21:32:08 -0300

On Tue, Mar 23, 2010 at 03:21:54PM -0800, Roy Arends wrote:
...
> My proposal is that we change the "MAY" to a "SHOULD".

As someone with a TA currently in place its not possible to not
support this proposal, I second it.

Fred

---

From: Paul Vixie <[email-masked]>
Date: Wed, 24 Mar 2010 01:27:23 +0000

> From: "Roy Arends" <[email-masked]>
> Date: Tue, 23 Mar 2010 15:21:54 -0800
> 

+1.

---

From: Samuel Weiler <[email-masked]>
Date: Tue, 23 Mar 2010 23:25:20 -0400 (EDT)

> My proposal is that we change the "MAY" to a "SHOULD".

+1.  Specifically, "SHOULD", not "MUST".

I'd like to have some text in the draft telling people why.  As one of 
the doc editors, I welcome contributions of text.

Note that 4035 section 4.7 tells resolvers to try more than once 
before populating the BAD cache:

    Resolvers that implement a BAD cache MUST take steps to prevent the
    cache from being useful as a denial-of-service attack amplifier,
    particularly the following:
...
    o  In order to prevent caching of a transient validation failure
       (which might be the result of an attack), resolvers SHOULD track
       queries that result in validation failures and SHOULD only answer
       from the BAD cache after the number of times that responses to
       queries for that particular <QNAME, QTYPE, QCLASS> have failed to
       validate exceeds a threshold value.

The text I'm hoping someone else witll contribute might clarify this 
somewhat.

-- Sam

---

From: "W.C.A. Wijngaards" <[email-masked]>
Date: Wed, 24 Mar 2010 09:34:35 +0100

Hi Sam,

> the doc editors, I welcome contributions of text.

The SHOULD is to add a BAD part to the cache, not to force validators to
have a cache.  I support the notion that (stub-)validators may do DNSSEC
without having a DNS cache.  Of course, these devices will then storm
their upstream resolvers if something goes bogus...

Best regards,
   Wouter

---

From: Paul Vixie <[email-masked]>
Date: Wed, 24 Mar 2010 14:24:52 +0000

> Date: Wed, 24 Mar 2010 09:34:35 +0100
> From: "W.C.A. Wijngaards" <[email-masked]>
> 

i can live with this, though i worry about storm-through if the authority
is SERVFAIL'ing.  i guess that's already fixed in this draft, though.

---

From: Mark Andrews <[email-masked]>
Date: Thu, 25 Mar 2010 02:05:49 +1100

> their upstream resolvers if something goes bogus...

Please stop with the knee jerk reactions.  There are a number of
ways to solve this issue.  Not all of them require a bad cache as
described in  RFC 4035.  It is something implementers need to be
aware of but we shouldn't be describing implementation details.

With named we did a number of things.

1. we workout whether a dnssec validation failure was a direct or
indirect failure.  For direct failure (e.g. DNSSEC from TA /DNSKEY
from DS) we retry a number of times before caching that there is a
break in the DNSSEC validation chain here.  For indirect failure
(e.g. SOA can't get a trusted DNSKEY RRset) we don't retry a number
of times but just fail the query.

2. we cache direct validation failures by name and type (DNSKEY/DS).

3. we cache indirect negative validation failures by name and type 
(DNSKEY/DS) of elements in the chain of trust this original validation
depends on.

We do NOT cache the RRsets from a direct validation failure.  This is
NOT a "bad cache" as described in RFC 4035.

We do cache RRsets (as pending validation) indirect validation failures.

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Jakob Schlyter <[email-masked]>
Date: Wed, 24 Mar 2010 22:54:06 -0700

> My proposal is that we change the "MAY" to a "SHOULD". 

I agree.

	jakob

--
Jakob Schlyter
Kirei AB - http://www.kirei.se/

---

From: Paul Vixie <[email-masked]>
Date: Thu, 25 Mar 2010 16:37:50 +0000

> From: Jakob Schlyter <[email-masked]>
> Date: Wed, 24 Mar 2010 22:54:06 -0700
> 

on subsequent reflection, i think marka's longer description of what to
do here is better than s/may/should/.  this isn't a change to the "bad"
cache after all.

---

From: "W.C.A. Wijngaards" <[email-masked]>
Date: Fri, 26 Mar 2010 09:59:34 +0100

I agree.

Best regards,
   Wouter

---

From: "Roy Arends" <[email-masked]>
Date: Fri, 26 Mar 2010 07:10:12 -0800

> > do here is better than s/may/should/.  this isn't a change to the 
"bad"

Could you guys help Sam out and write that longer description about these 
kind of strategies?

(i.e. send text)

Thanks

Roy

---

From: Samuel Weiler <[email-masked]>
Date: Sat, 27 Mar 2010 19:04:22 -0400 (EDT)

> Could you guys help Sam out and write that longer description about these

During the WG meeting in Anaheim, Rickard Bellgrim observed that this 
doc didn't mention the SHA512 variants.  I corrected that as well as a 
non-longer-ideal section heading.  And I added a placeholder section 
re: this scaling stuff.

The new document has been submitted and should appear soon.

I'm hopeful that better text about controlling query floods will be 
added soon.

-- Sam