Catalog member zones are always transfered on startup

[wtoorop]

Even when they have zone files on disk and are listed in the xfrd.state file.

[pettai]

And if transfer isn't happening in rare cases (because of unknown reasons ATM) member zones will not be served.

root@sunic:~# nsd-control zonestatus catz.catalog.
zone:	catz.catalog.
	catalog: consumer
	state: ok
	served-serial: "1734425182 since 2025-01-13T08:45:02"
	commit-serial: none
	wait: "80155 sec between attempts"

This happened after a restart of nsd due to the previous bug.
And none of the catz-zones where served at this state either.

After a manual nsd-control transfer catz.catalog. the catz-zones started to be served.

[pettai]

May I ask what the refresh, retry and expire timer values of the catz.catalog. SOA record are?

It seems to be what knot creates/generates by default:

; zone catz.catalog. written by NSD 4.11.1 on Mon Jan 20 18:47:01 2025
; received update to serial 1734425182 at 2025-01-20T18:45:01 from xx.yyy.zzz.aaa TSIG verified with key XXX
$ORIGIN catalog.
catz	0	IN	SOA	invalid. invalid. (
		1734425182 3600 600 2147483646 0 )
	0	IN	NS	invalid.
$ORIGIN catz.catalog.
version	0	IN	TXT	"2"
$ORIGIN zones.catz.catalog.
[...]

[pettai]

If the always transfer "bug" gets resolved, I'm certain the "no-serve of member zones" will be resolved automatically too,
because we have all of them on disk, and they are not outdated / expired

[pettai]

The last (past) comment:

I'm guessing that catz.catalog. was loaded from disk upon the restart of NSD, but none of the zones from the catalog zone where loaded. (Note the comment after catalog: consumer that wasn't present after the NSD restart)

zone:	catz.catalog.
	catalog: consumer (serial: 1734425182, # members: 414)
	state: ok
	served-serial: "1734425182 since 2025-01-13T19:45:01"
	commit-serial: "1734425182 since 2025-01-13T19:45:01"
	wait: "80100 sec between attempts"

No logs mentioned anything about the catz.catalog zone where present either.
Usually we see:

Jan 13 09:04:19 sunic nsd[3443194]: zone swupki.se read with success

But nothing happened with the catz.catalog. zone until I manually started a transfer of it...

Jan 13 09:14:22 sunic nsd[3443189]: control cmd:  transfer catz.catalog.
Jan 13 09:14:22 sunic nsd[3443189]: xfrd: zone catz.catalog. committed "received update to serial 1734425182 at 2025-01-13T09:14:22 from 192.71.XX.YYY"
Jan 13 09:14:22 sunic nsd[3443194]: zone catz.catalog. received update to serial 1734425182 at 2025-01-13T09:14:22 from 192.71.XX.YYY of 21975 bytes in 0.000623 seconds
Jan 13 09:14:26 sunic nsd[3443189]: zone catz.catalog. received update to serial 1734425182 at 2025-01-13T09:14:22 from 192.71.XX.YYY of 21975 bytes in 0.000623 seconds
Jan 13 09:14:26 sunic nsd[3443189]: Adding '00265b000a898dab.zones.catz.catalog.' PTR 'example.se'
[...]

I realize this issue might only be touching the previous state: ok issue.
But I wanted to bring it up now that we saw it, and it's nsd-control zonestatus reported this as ok, yet NSD didn't work as expected (as member zones where never loaded).