[nsd-users] NSD 4.3.8rc2 pre-release
anandb at ripe.net
Thu Oct 7 13:30:35 UTC 2021
On 07/10/2021 14:27, Paul Wouters via nsd-users wrote:
>> 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.
More information about the nsd-users