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

[Petr Špaček <[e-mail]>]

On 08. 11. 21 8:49, Giovane C. M. Moura wrote:
> Folks,
> 
> Loops in DNS are an old problem, but as our tsuname[0,1] disclosure last
> May shows, they are still a problem.
> 
> We wrote a new draft that adds a new requirement to existing solutions:
> recursive resolvers must detect and negative cache problematic (loop)
> records.
> 
> It would be nice to hear what folks have to say.

I generally support the direction, 22+ years after RFC 2308 was 
published it's time to have a look at it again.


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?

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.


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

> 3.  Current Problem
Nitpick: Maybe this should go to Appendix as there is no protocol 
description in here?


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


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.


I hope this early feedback helps a bit.

-- 
Petr Špaček