Wes,
On 05/11/2021 09:40, Vladimír Čunát wrote:
On 04/11/2021 23.44, Wes Hardaker wrote:
The most important sticking point is there are 4 implementations (thank
you for the links Matthijs) that have implemented 150. Since DNSOP
strives for implementations of specs, I think this is the number we
should publish*unless the vendors speak up and say they'll drive lower*.
I'm convinced that 150 was just a quick stop-gap compromise and that
from the start vendors expected that dnsop might set it lower later.
Therefore I don't think this *argument* for keeping 150 is really valid.
As for Knot Resolver, I see no problem in setting the hard limit lower,
especially if that gets published in this RFC. From Viktor I gather
that 100 shouldn't cause issues even at this moment, especially if it's
only a limit for downgrading to insecure (which won't be even noticed by
most DNS consumers). So personally I expected the draft to lower the
bound to <=100, though as I said... for us the *overall* performance
ratio from e.g. 150 -> 50 isn't that large.
For Unbound, we have no problem setting the iteration cap to a value
lower than the current 150. If Viktor's analysis shows a limit of 100
is feasible without (m)any problems for operators, and this value will
be adopted in the soon-to-be-released RFC, we will use the new limit value.
Cheers,
-- Benno
--
Benno J. Overeinder
NLnet Labs
https://www.nlnetlabs.nl/
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
