NSD 4.3.8rc1 pre-release

NSD
1

Hi,

The 4.3.8rc1 pre-release is available:
https://nlnetlabs.nl/downloads/nsd/nsd-4.3.8rc1.tar.gz
sha256 16ab0237c15e121f0522e3d30869334dd1743b857f9bc57d0245fa10868c9d46
pgp https://nlnetlabs.nl/downloads/nsd/nsd-4.3.8rc1.tar.gz.asc

This release fixes a crash bug in delegation answers, and fixes
in NSEC3 answers. Also compile fixes for OpenSSL. The OpenSSL 3.0
API is supported.

The Mutual TLS feature allows for client authentication for XFR-over-TLS
connections, use the client-cert, client-key and client-key-pw options
to set up the certificate that NSD then uses to connect to the upstream
server to download the zone with.

4.3.8

2

Testing and seems to compile and run fine. But I did not test
XFR-over-TLS yet.

Paul

3

Hello,

nsd-4.3.8rc1 compiled without noise,
but the Mutual TLS feature unfortunately does not work well at first try.

Certificate and private key files are present in a directory accessible by root only.
That is sufficient for NSD to operate as DoT server.

The same files now can't be used by NSD in it's role as XFR-over-TLS client.
I assume, the relevant process no longer run as root.
(chroot is not configured/used here)

Also, NSD warn about unreadable certificate files but continue:

[2021-10-06 23:38:59.686] nsd[33]: info: control cmd: force_transfer example
[2021-10-06 23:38:59.687] nsd[33]: info: remote control operation completed
[2021-10-06 23:38:59.688] nsd[33]: error: xfrd tls: Unable to load client certificate from file /acme/nsd.example/cert+intermediate.pem
[2021-10-06 23:38:59.689] nsd[33]: error: xfrd tls: Unable to load private key from file /acme/nsd.example/key.pem
[2021-10-06 23:38:59.989] nsd[33]: info: xfrd: zone example. written received XFR packet from 2001:db8::53 with serial 2110062049 to disk
[2021-10-06 23:38:59.992] nsd[33]: info: xfrd: zone example. written received XFR packet from 2001:db8::53 with serial 2110062049 to disk
[2021-10-06 23:38:59.993] nsd[33]: info: xfrd: zone example. committed "received update to serial 2110062049 at 2021-10-06T23:38:59 from 2001:db8::53 TSIG verified with key Knsd-example"

Andreas

4

Hi,

The 4.3.8rc2 pre-release is available:
https://nlnetlabs.nl/downloads/nsd/nsd-4.3.8rc2.tar.gz
sha256 39f82885a948303b48bf61758306dd448750a72b0d1904b739e99b027d84031d
pgp https://nlnetlabs.nl/downloads/nsd/nsd-4.3.8rc2.tar.gz.asc

The RC2 is here to update the default for DNS Cookies. It is now off to
stop wrong behaviour in mixed server deployments.

Best regards, Wouter

5

Hi Wouter,

The RC2 is here to update the default for DNS Cookies. It is now off to
stop wrong behaviour in mixed server deployments.

Thanks for this. I don't mind that NSD has cookie support, but it should not default to "on" immediately. It would take many operators by surprise, and even cause operational problems.

Regards,
Anand

6

Wrong? What was wrong? Isn't it RFC compliant? Does this only affect
anycast setups?

Paul

7

Hi Paul,

Cookies are a problem for when there are several servers. 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.

Best regards, Wouter

8

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 :slight_smile:

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

9

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 :slight_smile:

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

10

operators update their config based on stock upstream software? That
would be pretty bad.

Paul

11

This reasoning doesn't quite make sense - so this was changed in one
minor version (which at least one OS is shipping in a stable release)
and now you're requesting an equally major change in a second minor
version update?

12

Hi,

NSD 4.3.8 is available:
https://nlnetlabs.nl/downloads/nsd/nsd-4.3.8.tar.gz
sha256 11897e25f72f5a98f9202bd5378c936886d54376051a614d3688e451e9cb99e1
pgp https://nlnetlabs.nl/downloads/nsd/nsd-4.3.8.tar.gz.asc

This release fixes a crash bug in delegation answers, and fixes
in NSEC3 answers. Also compile fixes for OpenSSL. The OpenSSL 3.0
API is supported.

The Mutual TLS feature allows for client authentication for XFR-over-TLS
connections, use the client-cert, client-key and client-key-pw options
to set up the certificate that NSD then uses to connect to the upstream
server to download the zone with.

The default for DNS Cookies is updated. It is now off to
stop wrong behaviour in mixed server deployments.

4.3.8