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

[Petr Špaček <[e-mail]>]

On 10. 11. 21 10:31, Giovane C. M. Moura wrote:
>> 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).
>>
> 
> 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)?

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).

> 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.

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