similar to: allow-notify SUBNET and request-xfr inconsistency

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 >

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

Hi, NSD 4.10.1rc2 pre-release is available: https://nlnetlabs.nl/downloads/nsd/nsd-4.10.1rc2.tar.gz sha256 ce2e82bc673aeff3a71aeb422fa38fb8db0a591edb76c13b0e4dde83ec8253e9 pgp https://nlnetlabs.nl/downloads/nsd/nsd-4.10.1rc2.tar.gz.asc Version 4.10.1 consists primarily of bug fixes. @bilias implemented mutual TLS authentication for zone transfers. Please consult the nsd.conf manual for details

Hi, I have a query regarding running a manual update of nsd via: # nsdc update My NSD server is accepting notifications from two servers. From my nsd.conf: # master 1 allow-notify: X.X.X.X NOKEY request-xfr: AXFR X.X.X.X NOKEY # master 2 allow-notify: Y.Y.Y.Y NOKEY request-xfr: AXFR Y.Y.Y.Y NOKEY Are both servers sequentially queried each time

Hi, I'm doing some quick tests with nsd-4.0.0b5 and (rc2). And found something strange when changing (nsd-control reconfig) one zone from: zone: name: 10.in-addr.arpa zonefile: /zones/empty.zone to zone: name: 10.in-addr.arpa request-xfr: 192.168.122.12 NOKEY allow-notify: 192.168.122.12 NOKEY zonefile: /zones/slave/10.rev and doing nsd-control reconfig. After

Hi Peter, NSD processes updates in batches. xfrd receives the [AI]XFR and schedules a reload for the main process, which in turn forks new serve children. The served-serial is updated after main reports success, the commit-serial (update written to disk) is updated before the reload (to explain the serials). The difference in timestamp can be explained by the fact that NSD looks up if the serial

Hi, The man page for nsd.conf claims the following syntax is valid: provide-xfr: 0/0 NOKEY However, this gives the error: /var/dnsx/nsd.zones:9: error: Bad ip4 address '0' The following does work: provide-xfr: 0.0.0.0/0 NOKEY So either the code is wrong, or the man page :) Paul

Hi Jeroen, I just realised that the version I use is very old -- 4.1. So first what I should do -- updating it and only then come here , asking for clarification. ??, 27 ????. 2024??. ? 14:19, Jeroen Koekkoek <jeroen at nlnetlabs.nl>: > Hi Peter, > > NSD processes updates in batches. xfrd receives the [AI]XFR and > schedules a reload for the main process, which in turn forks

Dear All, Please help me understand why timestamps in logs are different from those in nsd-control zonestatus output: served-serial: "2024022603 since 2024-02-27T08:07:51" commit-serial: "2024022603 since 2024-02-27T08:07:51" Feb 26 18:47:34 slave-server nsd[780]: zone testzone.test. received update to serial 2024022603 at 2024-02-26T18:47:33 from

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

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

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 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, 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 all, I want to do live migration of domains using DRBD block devices for synchronisation between the two Xen hosts with Xen 2.0.7. I''ve written a script ( block-drbd ) which binds / unbinds DRBD devices for specific domains (with DRBD, only one host can write on a drbd device at the same time). This script sets the current host as master (bind) or secondary (unbind) in a DRBD

Hello, NSD 4.8.0 running on FreeBSD 13.2-RELEASE-p9 and serving both plain and DNSSEC signed zones. I noticed Permission denied errors in the logs for all domains listed in nsd.conf: [2024-01-12 12:20:05.710] nsd[8655]: info: writing zone domain-plain.org to file domain-plain.org [2024-01-12 12:20:05.710] nsd[8655]: error: cannot write zone domain-plain.org file domain-plain.org~: Permission

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

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

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:

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