Re: [DNSOP] nsec3-parameters opinions gathered

Publishing iteration count higher than 10 is reckless as that affects the performance of recursive resolvers in particular the ones that run on small CPE equipment.

The document should strongly discourage any use of NSEC3 <full stop> 
For the <censored> that want to keep using it the limit should be real low of what resolvers accept. 
Any value between 0 and 10 is fine with me 

Olafur

> On Nov 5, 2021, at 12:09 PM, Benno Overeinder <benno@NLnetLabs.nl> wrote:
> 
> 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