[nsd-users] NSD serves old serial after restart

Klaus Darilion klaus.darilion at nic.at
Wed Aug 17 12:51:41 UTC 2022


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


More information about the nsd-users mailing list