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

[Ralf Weber <[e-mail]>]

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