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