nsd users - Oct 2021 - NSD 4.3.8rc2 pre-release

On Thu, 7 Oct 2021, Wouter Wijngaards via nsd-users wrote:
> Cookies are a problem for when there are several servers.
You mean anycast?
> Those servers
> have to coordinate the cookie responses, and there are configuration
> options for that. But the default on was causing the trouble by default,
> instead of a more cautious default off, that does not cause the problem
> all of a sudden after an upgrade.
understood. But of course now we keep having the problem of needing to
answer to spoofed requests and being part of DDoS attacks :)

So I am trying balance the issues with the option. I'm more tempted to
leave it enabled to add DDoS protection, and assume server operators
of anycast clouds have their process in place for doing proper upgrades
of all their servers at the same time, and not run OS default configs.

So to me, it still seems better to enable this per default.

Paul

On 07/10/2021 14:27, Paul Wouters via nsd-users wrote:

Hi Paul,
>> Cookies are a problem for when there are several servers.
> 
> You mean anycast?
Anycast is one type of load-balancing. And this issue affects any DNS 
cluster that's load-balanced with multiple implementations. We have 
sites where we balance queries across multiple servers, and some run NSD 
while others run BIND and Knot DNS. If one server answers with cookies, 
and the others don't, a client gets confused.
> understood. But of course now we keep having the problem of needing to
> answer to spoofed requests and being part of DDoS attacks :)
> 
> So I am trying balance the issues with the option. I'm more tempted to
> leave it enabled to add DDoS protection, and assume server operators
> of anycast clouds have their process in place for doing proper upgrades
> of all their servers at the same time, and not run OS default configs.
> 
> So to me, it still seems better to enable this per default.
If an operator wants to enable cookies, they are free to do so.

But I 100% disagree with it being on by default. This issue goes deeper. 
Yesterday I wrote privately to the NSD folk about it. Here's my explanation.

NSD's release model is, IMHO, fast and loose. The NSD version number 
looks like semver, ie. X.Y.Z. X should change when there are major, 
breaking changes. Y should be reserved for new features, and Z should be 
for bug fixes.

Sadly, NSD went from 4.3.6 to 4.3.7 (looking like a bug fix update), but 
introduced new features such as cookies and XOT, and the cookies were 
turned on by default. An operator updating for bug fixes also get the 
new features, which they may not want. Okay, I could also deal with new 
features, but the fact that they're on by default is annoying. Suppose 
there's a bug in the new feature. Suddenly an update enables the 
feature, and break things.

Look, I really have no problem with new features. But first, they should 
be introduced in a way that makes things clear, with the proper version 
number scheme. Secondly, I feel very strongly that a new feature should 
default to off. Once the code has been around for a while, and tested 
properly, a future update could default it to on. That is, IMHO, the 
responsible way to introduce new features into code. You may disagree 
with me, but I'm sticking to my opinion about this.

Regards,
Anand