Hi,
NSD 4.3.9rc1 pre-release is available:
https://nlnetlabs.nl/downloads/nsd/nsd-4.3.9rc1.tar.gz
sha256 096e48ec7ee72c23e62f5e18a378b254865689f2f5518c2df4ceb3a445b711b8
pgp https://nlnetlabs.nl/downloads/nsd/nsd-4.3.9rc1.tar.gz.asc
This release contains a small number of bug fixes. The reconfig failure
is fixed for cpu-affinity config re-read. Version repository and
continuous integration files are removed from the sourcecode tarball.
4.3.9
Hello Wouter,
the new version compiles without trouble (using openssl3)
Not directly related to this rc1:
UNBOUND has the ability to check ZONEMD records
I'm missing a similar feature in NSD. Are there any plans?
Andreas
Hi Andreas,
Thanks for the test. 
The ZONEMD was devised to safeguard transmission of zones like the root
and in-addr zones, and for hyperlocal hosting of those zones, so
implementation in Unbound makes sense for that. For NSD, it could
perhaps verify ZONEMD records, the hashes of it, upon loading a zonefile
or loading from a zone transfer. But that would only work if that zone
has one. And NSD then could not actually check the RRSIGs on the ZONEMD,
because although Unbound is a DNSSEC validator, and Unbound can lookup
recursively records that are needed, NSD is not and wants to be a small,
tightly focused package.
So for NSD it is less relevant, not really those zones have ZONEMD. And
it lacks DNSSEC verification capabilities. Because of that, there are no
plans for ZONEMD in NSD. Even though, hash-only checks, would not be too
difficult, but the spec mandates DNSSEC checks.
Best regards, Wouter
Hello Wouter,
Thanks for that clarification. It helped a lot for my understanding.
I read it mostly as
1) I know not many relevant zones providing ZONEMD data today.
2) checking require DNSSEC-validation which is not implemented in NSD
Point 1 let met me ask: which zones offer ZONEMD today? Just checked my local copies of
- .
- arpa
- in-addr.arpa
- ip6.arpa
- root-servers.net.
for ZONEMD records: nothing ...
Point 2 is valid, BUT
especially for DNSSEC validation it is not necessary to implement it inside NSD.
postfix, the well-known MTA, is a perfect example for an other way.
The whole DANE implementation simply require DNS queries are answered from a DNSSEC validating resolver.
And there is an important operational advise: use a LOCAL resolver (UNBOUND is suggested btw.)
-> http://www.postfix.org/TLS_README.html#client_tls_dane -> CTRL+F -> "Note:"
Andreas
Hi Andreas,
1) I know not many relevant zones providing ZONEMD data today.
2) checking require DNSSEC-validation which is not implemented in NSDPoint 1 let met me ask: which zones offer ZONEMD today? Just checked my local copies of
- .
- arpa
- in-addr.arpa
- ip6.arpa
- root-servers.net.
for ZONEMD records: nothing ...
ZONEMD is expected to appear in the root zone next year. Here's a publication by ICANN about it:
The idea behind this is that validating resolvers that want a local copy of the root zone can get it from any source, and verify it using the ZONEMD record.
As Wouter explained, NSD is an authoritative-only server, and usually has no need to verify zones. Usually, NSD will be configured as a secondary, and XFR zones from primaries using TSIG.
Regards,
Anand Buddhdev
RIPE NCC
Hi Anand!
ZONEMD is expected to appear in the root zone next year.
ok, good to know.
As Wouter explained, NSD is an authoritative-only server, and usually has no need to verify zones. Usually, NSD will be configured as a secondary, and XFR zones from primaries using TSIG.
so it looks like zone transfer over TCP+TLS and TSIG and DNSSEC are enough integrity checks to /assume/
data served by a secondary aren't corrupted.
well, don't sound like a strange assumption but I thought, ZONEMD was also developed as a next layer ontop.
Andreas
We at .CL use ZONEMD as an integrity check after transfer in all
nodes. It's an ad-hoc process for now, outside the server, so we're
not concerned that nsd doesn't have plans to implement it.
Hugo