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
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
