similar to: NSD 4.12.0rc1 pre-release

NSD 4.10.0rc1 is available: https://nlnetlabs.nl/downloads/nsd/nsd-4.10.0rc1.tar.gz sha256 ad476e82eee5bdabc985e071cabe6a68263dd02eac6278ce2f81798b8c08f19f pgp https://nlnetlabs.nl/downloads/nsd/nsd-4.10.0rc1.tar.gz.asc Version 4.10.0 integrates simdzone and drops the Flex+Bison zone parser. NSD used a Flex+Bison based zone parser since version 1.4.0. The parser served NSD well, but zones have

On 2025-04-16 14:22 +02, Jannik Peters via nsd-users <nsd-users at lists.nlnetlabs.nl> wrote: > Dear all, > > NSD 4.12.0rc1 pre-release is available: > https://nlnetlabs.nl/downloads/nsd/nsd-4.12.0rc1.tar.gz > sha256 b9085a3fd08b8318ac30715faf1c7698099781eb3520253774a46f74386342e9 > pgp https://nlnetlabs.nl/downloads/nsd/nsd-4.12.0rc1.tar.gz.asc > > > This release

Hi Jannik, What's the rationale behind the "--enable-prometheus-metrics" compile-time option? If this code were compiled by default, would it do any harm? The reason I'm asking this is that features that can be enabled/disabled at compile-time make package distribution complicated. It can result in a scenario where NSD packages on different operating systems or distributions

We upgraded to NSD 3.2.9 (from 3.2.8) because we encountered the problem "Fix denial of existence response for empty non-terminal that looks like a NSEC3-only domain (but has data below it)." (a nasty problem with DNSSEC). But we now have IXFR issues. On one name server, NSD 3.2.9 works fine, zones are IXFRed and work. On another name server, with much more zones (and big ones), we

Hi, NSD 4.8.0rc1 pre-release is available: https://nlnetlabs.nl/downloads/nsd/nsd-4.8.0rc1.tar.gz sha256 64f1da8f8163340f9d3b352ef8819e3c72c951fdd87cff55dc3b6a6b1ea27942 pgp https://nlnetlabs.nl/downloads/nsd/nsd-4.8.0rc1.tar.gz.asc This release introduces PROXYv2 support and faster statistics gathering, removes the database option and fixes bugs. The proxy protocol support is an implementation

Dear all, NSD 4.11.0rc1 pre-release is available: https://nlnetlabs.nl/downloads/nsd/nsd-4.11.0rc1.tar.gz sha256 7594d014199585c24f6593649bfc657078d411a3f09eb31192a35a7c031c028f pgp https://nlnetlabs.nl/downloads/nsd/nsd-4.11.0rc1.tar.gz.asc Version 4.11.0rc1 sees various small features and bugfixes. One notable feature is that configuration can be reloaded and evaluated on SIGHUP, when

Hi, I'm new to NSD and would really appreciate if someone can point me to the right direction. I have like 8 NSD servers (secondary) serving around 30,000 zones. Zone updates are transferred from the primary DNS servers by AXFR/IXFR. The 8 NSD servers do not save the zones file on disk but are only held in memory. Therefore after NSD service is restarted zone transfer requests are being

Hello NSD developers, The new release candidate of NSD, with the new prometheus metrics feature, got me thinking about NSD's feature set, and how so many of its features have to be enabled at compile time. The result of of this is that NSD packages on various operating systems behave differently. I would like to propose that you adjust the build process to compile in *all* the features of

Dear all, NSD 4.11.0 is available: https://nlnetlabs.nl/downloads/nsd/nsd-4.11.0.tar.gz sha256 93956d90d45ffa9f84f8ca2f718a42105e4236d094ce032211849f1a12cdc158 pgp https://nlnetlabs.nl/downloads/nsd/nsd-4.11.0.tar.gz.asc Version 4.11.0 sees various small features and bugfixes. One notable feature is that configuration can be reloaded and evaluated on SIGHUP, when enabled with the new

Hello! I use NSD 4.7.0 self compiled: Configure line: --build=x86_64-linux-gnu --prefix=/usr --includedir=${prefix}/include --mandir=${prefix}/share/man --infodir=${prefix}/share/info --sysconfdir=/etc --localstatedir=/var --disable-option-checking --disable-silent-rules --libdir=${prefix}/lib/x86_64-linux-gnu --runstatedir=/run --disable-maintainer-mode --disable-dependency-tracking

Hi all, we have discovered a segfault in nsd-patch when renaming slave zone in nsd config file if some data for this zone still exists in the IXFR diff database. In my case, the zone "black" was renamed to "blackinwhite": > root at ggd115:/cage/nsd/var/nsd/zones#nsd-patch -c > /cage/nsd/etc/nsd-dns-slave.conf > reading database > reading updates to database >

hi, On 2024-12-27 22:32, Fredrik Pettai via nsd-users wrote: > Hello, > > It seems our NSD secondary has triggered some sort of intermittent bug > After several weeks/months of running nsd stops forking with the new > zone data. > > A manual nsd-control transfer or even nsd-control force_transfer won?t > work, only restart of nsd solves the problem. > The only

Hi Jean Claude, The message is printed when the bind operation failed. Why that happens is hard to say, I'd need more information for that. As the message does not say: address already in use (or similar), I'm guessing the address is not configured? Best regards, Jeroen On Fri, 2023-04-21 at 18:03 +0200, HAKIZIMANA Jean Claude via nsd-users wrote: > Dear nsd Users, > kindly can

Hi NSD developers, I have been experimenting with the "store-ixfr" feature in NSD. I have a configuration with: server: zonefiles-write: 0 pattern: store-ixfr: yes With this configuration, NSD transfers zones from a primary, and keeps them in RAM. When the zones are updated, it receives and stores the IXFR in RAM too. I can query NSD with the IXFR qtype, and it replies with

Dear authors of NSD, currently, the manpages that come with NSD are written in the traditional man(7) markup language. I am proposing to rewrite them into the semantic markup of the mdoc(7) language. I am willing to do the work. See a version of nsd-checkzone.8 below as an example. Both the man(7) and mdoc(7) languages have been around for decades, and are supported by the prevalent formatters:

Am 23.07.24 um 17:28 schrieb Jeroen Koekkoek via nsd-users: > NSD 4.10.1rc2 pre-release is available: no compile time warnings while building on debian bookworm/x86_64 > @bilias implemented mutual TLS authentication for zone transfers. > Please consult the nsd.conf manual for details on the newly introduced > configuration options tls-auth-port and tls-auth-xfr-only. this is an nice

Hello, It seems our NSD secondary has triggered some sort of intermittent bug After several weeks/months of running nsd stops forking with the new zone data. A manual nsd-control transfer or even nsd-control force_transfer won?t work, only restart of nsd solves the problem. The only ?hint? I?ve found is that the nsd xfrd messages stops appearing in the logs (while the notify messages keeps

On Sat, 28 Dec 2019 17:02:09 +0100 richard lucassen via nsd-users <nsd-users at lists.nlnetlabs.nl> wrote: > The problem is (was) that I used "include:" statements in nsd.conf > to load zone information. Apparently nsd does not reread the include > files upon a SIGHUP. I scripted everything into 1 file and a HUP > rereads the zone info now. Wrong, I made a mistake it

Dear nsd Users, kindly can you help me to trace the cause of this error in nsd " nsd[25372]: warning: xfrd: could not bind source address:port to socket: Cannot assign requested address". I use NSD version 4.0.1 Thank you, -------------- next part -------------- An HTML attachment was scrubbed... URL:

Hi Andreas, The suggestions I captured in GitHub issues. Thanks for sharing. Regarding whether notifies are still plain UDP. Yes, the config parser doesn't accept additional arguments to "notify" and judging by the xfrd code anything to do with notify is using UDP, so no TLS yet. I've added a GitHub issue for this too. Thanks for the suggestions. They make for nice