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