On 17/08/2022 13:18, Klaus Darilion via nsd-users wrote: Hi Klaus,> NSD 4.3.5: > 07:31:13 nsd-pl[811535]: notify for kepno.pl. from X.X.X.20 serial 1660716049 > 07:31:13 nsd-pl[811535]: notify for kepno.pl. from XXXX:XXXX:9::5 serial 1660716049 > 07:31:13 nsd-pl[3084]: xfrd: zone kepno.pl committed "received update to serial 1660716049 at 2022-08-17T07:31:13 from X.X.X.20 TSIG verified with key foobar" > 07:31:13 nsd-pl[3089]: zone kepno.pl. received update to serial 1660716049 at 2022-08-17T07:31:13 from X.X.X.20 TSIG verified with key foobar of 2403 bytes in 9.8e-05 seconds > 07:31:13 nsd-pl[811535]: notify for kepno.pl. from X.X.X.4 serial 1660716049 > 07:31:13 nsd-pl[811535]: notify for kepno.pl. from XXXX:XXXX:8::5 serial 1660716049 > 07:31:14 nsd-pl[3084]: zone kepno.pl serial 1660716048 is updated to 1660716049 > 07:46:24 nsd-pl[3089]: writing zone kepno.pl to file kepno.pl.zoneHere, the zone kepno.pl has been saved with serial 1660716049.> 09:46:22 nsd-pl[1008051]: notify for kepno.pl. from XXXX:XXXX:9::5 serial 1660716050 > 09:46:22 nsd-pl[1008051]: notify for kepno.pl. from X.X.X.20 serial 1660716050 > 09:46:22 nsd-pl[3084]: xfrd: zone kepno.pl committed "received update to serial 1660716050 at 2022-08-17T09:46:22 from XXXX:XXXX:9::5 TSIG verified with key foobar" > 09:46:22 nsd-pl[1008051]: notify for kepno.pl. from XXXX:XXXX:8::5 serial 1660716050 > 09:46:22 nsd-pl[1008051]: notify for kepno.pl. from X.X.X.4 serial 1660716050 > 09:46:27 nsd-pl[3089]: zone kepno.pl. received update to serial 1660716050 at 2022-08-17T09:46:22 from XXXX:XXXX:9::5 TSIG verified with key foobar of 840 bytes in 0.000108 seconds > 09:46:28 nsd-pl[3084]: zone kepno.pl serial 1660716049 is updated to 1660716050 > -> NSD 4.3.5 serves serial 1660716050NSD has internally updated to serial 1660716050, but not yet saved it to disk. By default, NSD writes out zone files only once per hour.> Now, upgrade to 4.6 and restart NSD: > 10:32:04 nsd-pl[1072241]: zone kepno.pl read with success > 10:32:04 nsd-pl[1072241]: rehash of zone kepno.pl. with parameters 1 0 12 e831662b2ffa02c1 > 10:32:10 nsd-pl[1072240]: zone kepno.pl serial 1660716050 is updated to 1660716049 > --> Why is the serial going backwards?NSD read the zone from disk, and it still had the previous serial number, so that's what got loaded into memory. Eventually, NSD would have noticed that it's outdated and would have done an XFR to update it. Before restarting NSD, it is good practice to write zones to disk. Or configure it to save an updated zone immediately to disk, by setting "zonefiles-write" to a low value, so that zone files on disk are as up to date as possible. [snip]> Is this a bug or a feature?Feature ;-) Regards, Anand
Hi Anand!> > -> NSD 4.3.5 serves serial 1660716050 > > NSD has internally updated to serial 1660716050, but not yet saved it to > disk. By default, NSD writes out zone files only once per hour. > > > Now, upgrade to 4.6 and restart NSD: > > 10:32:04 nsd-pl[1072241]: zone kepno.pl read with success > > 10:32:04 nsd-pl[1072241]: rehash of zone kepno.pl. with parameters 1 0 12 > e831662b2ffa02c1 > > 10:32:10 nsd-pl[1072240]: zone kepno.pl serial 1660716050 is updated to > 1660716049 > > --> Why is the serial going backwards? > > NSD read the zone from disk, and it still had the previous serial > number, so that's what got loaded into memory.That makes sense.> Eventually, NSD would > have noticed that it's outdated and would have done an XFR to update it.That's the weird thing. NSD knows that the version on disk is older than the previously served one (serial is goind backwards: "1660716050 is updated to 1660716049"). Hence it could check the serial on the primary and fetch the latest version. I also tried "nsd-control transfer ....", but that also did not triggered an XFR. Only "force_transfer" triggered an XFR. From my understanding, "transfer: try to update slave zones to newer serial" should also trigger an XFR as the primary has a higher serial then the current served one.> Before restarting NSD, it is good practice to write zones to disk. Or > configure it to save an updated zone immediately to disk, by setting > "zonefiles-write" to a low value, so that zone files on disk are as up > to date as possible.Thanks for the tip Klaus
Anand Buddhdev via nsd-users <nsd-users at lists.nlnetlabs.nl> wrote:> NSD has internally updated to serial 1660716050, but not yet saved it to > disk. By default, NSD writes out zone files only once per hour.I presume that's to reduce I/O? Is there any reason why updates aren't written as soon as the file they are replacing is older than 1 hour? In other words, write as soon as possible unless we already had an update written in the last hour. Sorry if this is a dumb question! Cheers, Jamie
Hi Jamie!> -----Urspr?ngliche Nachricht----- > Von: Jamie Landeg-Jones <jamie at catflap.org> > Gesendet: Mittwoch, 17. August 2022 23:50 > An: nsd-users at lists.nlnetlabs.nl; Klaus Darilion <klaus.darilion at nic.at>; > anandb at ripe.net > Betreff: Re: [nsd-users] NSD serves old serial after restart > > Anand Buddhdev via nsd-users <nsd-users at lists.nlnetlabs.nl> wrote: > > > NSD has internally updated to serial 1660716050, but not yet saved it to > > disk. By default, NSD writes out zone files only once per hour. > > I presume that's to reduce I/O?Yes. Consider a very huge zone which gets updated with IXFR every few seconds. That would be heavy to write the zone to disk after every update.> Is there any reason why updates aren't > written as soon as the file they are replacing is older than 1 hour?AFAIK this is actually the case, when default zonefile-write=1h In my opinion, it would be useful to have a zonefile-write-onshutdown=true option to force a "write" when the daemon is shut down. I think this is what Bind9 for example does. regards Klaus