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