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
