Subject: [DNSOP] draft-moura-dnsop-negative-cache-loop

From: "Giovane C. M. Moura" <[email-masked]>
Date: Mon, 8 Nov 2021 08:49:03 +0100

Folks,

Loops in DNS are an old problem, but as our tsuname[0,1] disclosure last
May shows, they are still a problem.

We wrote a new draft that adds a new requirement to existing solutions:
recursive resolvers must detect and negative cache problematic (loop)
records.

It would be nice to hear what folks have to say.

Thanks,

/giovane

Giovane C.M. Moura
SIDN Labs

[0] https://tsuname.io
[1] https://www.isi.edu/~johnh/PAPERS/Moura21b.pdf

------

A new version of I-D, draft-moura-dnsop-negative-cache-loop-00.txt
has been successfully submitted by Giovane C. M. Moura and posted to the
IETF repository.

Name:		draft-moura-dnsop-negative-cache-loop
Revision:	00
Title:		Negative Caching of Looping NS records
Document date:	2021-11-08
Group:		Individual Submission
Pages:		8
URL:
https://www.ietf.org/archive/id/draft-moura-dnsop-negative-cache-loop-00.txt
Status:
https://datatracker.ietf.org/doc/draft-moura-dnsop-negative-cache-loop/
Htmlized:
https://datatracker.ietf.org/doc/html/draft-moura-dnsop-negative-cache-loop

Abstract:
   This document updates guidance about detecting DNS loops in recursive
   resolver algorithms with new requirements to require recursive
   resolvers to detect loops and to implement negative caches.

The IETF Secretariat

---

From: Petr Špaček <[email-masked]>
Date: Tue, 9 Nov 2021 17:12:46 +0100

> It would be nice to hear what folks have to say.

I generally support the direction, 22+ years after RFC 2308 was 
published it's time to have a look at it again.

If I understand this correctly, TL;DR summary essentially is
""" make https://datatracker.ietf.org/doc/html/rfc2308#section-7.1 
mandatory """
(even though your version is a bit stronger). Is that correct?

If it is the case, then the document needs to clearly update 2308 
section 7.1 and go through standards track. Right now this might not be 
clear.

Ad the draft content:

> 2.  Past solutions
This section somehow does not mention RFC 2308 section 7.1 which solves 
most of the problem if implemented. In fact BIND has an implementation 
of it and is not vulnerable to the TsuNAME attack (or at least I was not 
able to reproduce it).

> 3.  Current Problem
Nitpick: Maybe this should go to Appendix as there is no protocol 
description in here?

> 4.  New requirement
I think section 4 should not require full blown _loop_ detection, but 
any sort of limit should be good enough for compliance.

I mean, implementing a loop detection algorithm in hot path might not be 
a good idea, mainly because most of the time it just wastes resources - 
compared to a simple resource limit like, say, number of delegation 
steps per query.

To be clear:
I don't think the resolver _has to_ stop resolution at the earliest 
moment it has data to potentially detect the cycle. If the cycle has 
length 2, it should be okay to allow the resolver to do 4,6,8,... steps 
before giving up. For compliance it should be good enough to stop within 
"a" reasonable limit (not necessarily specified by a number).

An additional nitpick: I think section 4.  New requirement sound avoid 
term "negative" caching. In my eyes it is a bit misleading because 
"negative" is typically used for different kinds of answers.

I hope this early feedback helps a bit.

-- 
Petr Špaček

---

From: Ralf Weber <[email-masked]>
Date: Tue, 09 Nov 2021 20:41:41 +0100

Moin!

On 9 Nov 2021, at 17:12, Petr Špaček wrote:
>> 4.  New requirement
> I think section 4 should not require full blown _loop_ detection, but any sort of limit should be good enough for compliance.
>
> I mean, implementing a loop detection algorithm in hot path might not be a good idea, mainly because most of the time it just wastes resources - compared to a simple resource limit like, say, number of delegation steps per query.
>
> To be clear:
> I don't think the resolver _has to_ stop resolution at the earliest moment it has data to potentially detect the cycle. If the cycle has length 2, it should be okay to allow the resolver to do 4,6,8,... steps before giving up. For compliance it should be good enough to stop within "a" reasonable limit (not necessarily specified by a number).
I fully agree here. Most of the current or older implementations solve this by resource limiting and had no problem with tsuName. Only some new cloud implementations had a problems. So please don’t require those that had working mitigations to change them.

> An additional nitpick: I think section 4.  New requirement sound avoid term "negative" caching. In my eyes it is a bit misleading because "negative" is typically used for different kinds of answers.
Maybe failed resolution caching is a better term here.

So long
-Ralf
——-
Ralf Weber

---

From: "Giovane C. M. Moura" <[email-masked]>
Date: Wed, 10 Nov 2021 10:31:29 +0100

Thanks a lot, Petr.

> (even though your version is a bit stronger). Is that correct?

Thanks  for pointing to this section. We missed it.
We need to make a new draft version incorporating this.

RFC2308's solution is not strong enough (MAY cache, we say MUST cache)
-- as you rightfully pointed.

Question about "server failure": do loops qualify as a  "server failure"
in the resolver's logic?

I assume they do, the resolver will simply try to resolver a qname, and
after say, as you pointed,  "a resource limit like, say, number of
delegation steps per query", it automatically classify the query as
failure, even though I mean,  all *parent* authoritative servers are
responsive when loops are present.

> section 7.1 and go through standards track. Right now this might not be

+1

> of it and is not vulnerable to the TsuNAME attack (or at least I was not

Yep, but 7.1 was unfortunately (for this case) optional, and a MAY.

But when we privately disclosed tsuname at OARC34, we tested only if
BIND and others would loop in the presence of a single client query.
They don't. That covers only one source of loop: resolvers looping.

But what happens when a client sends non-stop queries to the same
resolver?  Does bind answer from cache (7.1 RFC2308) OR will trigger new
queries again? (we did not test for that, if you did, could you please
share the findings)?

Because if does not cache, clients recurrent queries would force the
resolver to send many queries to the authoritative servers, and it would
seem they'd be looping.  See fig3(b) in [0], where we show that only
some of Google resolvers would be aggressive -- and those were the ones
that had these impatient clients.
That's the second root cause: clients/forwarders looping.

> compared to a simple resource limit like, say, number of delegation

That sounds much simpler indeed, and that's what RFC1035  and RFC. Will
incorporate that.

> I hope this early feedback helps a bit.

It helps a lot, thanks for bringing the developer point-of-view in the
discussion.

best,

/giovane

[0] https://www.isi.edu/~johnh/PAPERS/Moura21b.pdf

---

From: "Giovane C. M. Moura" <[email-masked]>
Date: Wed, 10 Nov 2021 10:35:45 +0100

Thanks Ralf,

> I fully agree here. Most of the current or older implementations
> solve this by resource limiting and had no problem with tsuName. Only
> some new cloud implementations had a problems. So please don’t
> require those that had working mitigations to change them.

Well, not only cloud implementations: we found 34 ASes that had issues
-- but again that is limited by our vantage points (sinkhole & ripe atlas).

>> An additional nitpick: I think section 4.  New requirement sound
>> avoid term "negative" caching. In my eyes it is a bit misleading
>> because "negative" is typically used for different kinds of
>> answers.

Sure, will work on that.

Thanks Ralf,

/giovane

---

From: Petr Špaček <[email-masked]>
Date: Wed, 10 Nov 2021 14:47:48 +0100

> queries again? (we did not test for that, if you did, could you please

This is an interesting question. In case of BIND there are two (or 
three...) things which prevent it from generating queries to 
authoritatives when queried repeatedly:

1] First stage is RFC 2308 section 7.1-style "SERVFAIL cache". It is by 
default configured with a 1 second TTL ("servfail-ttl" option in 
named.conf).
Identical queries which resulted in SERVFAIL are responded from this 
cache without doing anything else.
Please note that this is an "output" cache, i.e. it stores SERVFAILs 
generated by the resolver itself - which happens when query fails for a 
number of reasons, including resource limits.

2] If the answer is not in SERVFAIL cache, the resolver starts 
recursing, but naturally consults its RR cache for each step. While 
processing the second query, the resolver will find delegations from the 
authoritative servers in RR cache and use these instead of re-querying 
servers again. I.e. no queries will be generated until TTL in RR cache 
expires (or cache eviction kicks out delegation RRs for other reasons).

3] The third reason is a bug in older versions of BIND :-D A subtle bug 
caused mishandling of queries with cyclic dependencies in delegations, 
causing BIND to _delay_ responding with SERVFAIL by roughly 10 seconds 
(an another internal timeout).

All two/three mechanism dampen amount of outgoing queries. Of course we 
need to look at it with attacker's mindset and probe for holes in it, 
but with this infrastructure in place I think it will not be much worse 
than regular TTL=0 query/answer flood, and that's only possible if 
attacker has control over delegation TTL (which is AFAIK not the case 
for most TLDs).

> That's the second root cause: clients/forwarders looping.

Sure, that boils down to generic problem "clients evading cache in 
resolvers", which is always PITA. We should declare TTL=0 illegal :-)

-- 
Petr Špaček

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Fri, 12 Nov 2021 15:17:49 +0100

On Mon, Nov 08, 2021 at 08:49:03AM +0100,
 Giovane C. M. Moura <giovane.moura=[email-masked]> wrote 

> recursive resolvers must detect and negative cache problematic (loop)

I basically agree with Petr Špaček and Ralf Weber. Resource limiting is:

* more general (it also addresses infinite recursion - CVE-2014-8500,
CVE-2014-8602, CVE-2014-8601, not just loops),

* already implemented.

So, I'm not sure we need a new RFC.