On Mon, Nov 08, 2021 at 08:49:03AM +0100,
Giovane C. M. Moura wrote
a message of 58 lines which said:
> We wrote a new draft that adds a new requirement to existing solutions:
> recursive resolvers must detect and negative cache problematic (loop)
> records.
I basically agree with Petr
On 10. 11. 21 10:31, Giovane C. M. Moura wrote:
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
Thanks Ralf,
> 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.
Well, not only
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
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,
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
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
