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

["Giovane C. M. Moura" <[e-mail]>]

Thanks a lot, Petr.

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

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.


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

+1

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

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.



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

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