nsd users - Aug 2022 - NSD serves old serial after restart

Hi Anand!

Thanks for your help.
> > 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.
> 
> Hmm. So NSD thinks the zone is up to date, because it has a newer serial
> in the state file, but is actually serving an old serial. Could be a
> subtle bug. I'll see if I can reproduce it on our test server.
It also confuses me, that the commited serial is higher than the served serial:
root at tld-all-fam1:/home/darilion# nsd-control -c /etc/nsd/nsd-shared.conf
zonestatus cy
zone:   cy
        state: ok
        served-serial: "2022081705 since 2022-08-17T12:07:26"
        commit-serial: "2022081706 since 2022-08-17T12:31:40"
        wait: "6845 sec between attempts"

I also have in the zone settings: max-refresh-time: 300
I would expect that at least after 5 minutes NSD should perform a SOA query
against the primary, detect the higher serial, and then perform the XFR. But
maybe NSD is comparing the "commit-serial" with the primary-serial and
this doing nothing,

I checked with tcpdump: on "nsd-control transfer cy" it performs an
IXFR request with serial in the SOA=2022081706.

So something is going wrong here. If NSD has the 2022081706 zone local
available, then it should serve it. If only the 2022081705 is available on disk,
NSD should perform the serial check against the primary (IXFR request) with the
serial of the local served zone, which would be 2022081705 and not 2022081706.

regards
Klaus

> It also confuses me, that the commited serial is higher than the served
serial:
> root at tld-all-fam1:/home/darilion# nsd-control -c
/etc/nsd/nsd-shared.conf
> zonestatus cy
> zone:   cy
>         state: ok
>         served-serial: "2022081705 since 2022-08-17T12:07:26"
>         commit-serial: "2022081706 since 2022-08-17T12:31:40"
>         wait: "6845 sec between attempts"
> 
> I also have in the zone settings: max-refresh-time: 300
> I would expect that at least after 5 minutes NSD should perform a SOA query
> against the primary, detect the higher serial, and then perform the XFR.
But
> maybe NSD is comparing the "commit-serial" with the
primary-serial and this
> doing nothing,
> 
> I checked with tcpdump: on "nsd-control transfer cy" it performs
an IXFR
> request with serial in the SOA=2022081706.
> 
> So something is going wrong here. If NSD has the 2022081706 zone local
> available, then it should serve it. If only the 2022081705 is available on
disk,
> NSD should perform the serial check against the primary (IXFR request) with
> the serial of the local served zone, which would be 2022081705 and not
> 2022081706.
Now, as the primary had a new serial 2022081707, NSD now serves 2022081707, but
again there are "updated failed" log messages.

15:06:36 nsd[2657770]: notify for cy. from X.X.X.20 serial 2022081707
15:06:36 nsd[2657770]: notify for cy. from XXXX:XXXX:9::5 serial 2022081707
15:06:36 nsd[2391509]: xfrd: zone cy committed "received update to serial
2022081707 at 2022-08-17T15:06:36 from X.X.X.20 TSIG verified with key
foobar"
15:06:36 nsd[2391509]: xfrd: zone cy: soa serial 2022081707 update failed,
restarting transfer (notified zone)
15:08:40 nsd[2659700]: notify for cy. from X.X.X.4 serial 2022081707
15:08:40 nsd[2659700]: notify for cy. from XXXX:XXXX:8::5 serial 2022081707
15:08:40 nsd[2391509]: xfrd: zone cy committed "received update to serial
2022081707 at 2022-08-17T15:08:40 from X.X.X.4 TSIG verified with key
foobar"
15:08:40 nsd[2391512]: zone cy. received update to serial 2022081707 at
2022-08-17T15:08:40 from X.X.X.4 TSIG verified with key foobar of 701 bytes in
8.9e-05 seconds
15:08:40 nsd[2391509]: zone cy serial 2022081705 is updated to 2022081707

Further, it is not trustworthy at all, and I suspect that this NSD now serves a
broken zone file:
- NSD served serial 2022081705
- NSD request IXFR with serial 2022081706
- the primary has 2022081707, hence sending an IXFR with the differences from
2022081706 to 2022081707

I suspect that only the diff from 2022081706 to 2022081707 was applied on top of
2022081705. Hence, I request now full AXFR to be on the safe side.

This is very scary
Thanks
Klaus