I concur with Benno.

For Bind 9, there is no technical challenge to set the iteration cap at
a lower value.

We prefer the value to be as low as possible, because it adds no real
value at a real resource cost.

But we will likely not implement blindly a maximum that will cause lots
of operational problems.

Best regards,

Matthijs

On 11/5/21 5:09 PM, Benno Overeinder 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
> 
> 

_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Reply via email to