"state" should be something else than "ok" then served-serial and commit-serial are not equal

[pettai]

It's a NSD behavior follow-up on #417

nsd-control zonestatus reports zone state: ok even thought served-serial is several updates away from current commit-serial.

Example https://github.com/NLnetLabs/nsd/issues/417

Generally, perhaps it shouldn't be regarded as a fault state (since the new zone data is suppose to be installed, but currently hasn't been that yet).
So perhaps something like state: old-serial or similar would be an indication that the zone currently isn't on par with the latest zone NSD knows about.

This would make it much simpler to discover then the NSD updating process isn't working as expected (as per #417)

[wtoorop]

Good idea. I'll implement that shortly.

[pettai]

your fix worked for us 👍

[wtoorop]

Ack, served-serial: none and commit-serial: something is okay, but not the other way around. But there are some retries implemented already. I'll have to consider this...

[wtoorop]

I realize this issue might only be touching the 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.

That is peculiar. I tried this myself, but with me it did start to add the zones, even though the catalog zone itself was read from disk:

[2025-01-23 15:34:25.231] nsd[411416]: notice: nsd starting (NSD 4.11.2)
[2025-01-23 15:34:25.235] main[411417]: info: zone catalog1.invalid read with success
[2025-01-23 15:34:25.252] main[411417]: notice: nsd started (NSD 4.11.2), pid 411416
[2025-01-23 15:34:25.253] xfrd[411416]: info: zone catalog1.invalid read with success
[2025-01-23 15:34:25.253] xfrd[411416]: info: Adding '0270267e.zones.catalog1.invalid.' PTR 'zone105.invalid'

I did notice however that all the zones in the catalog are then freshly transferred from the primary, even though they did have zone files on disk, and even though their state was properly recorded in the xfrd.state file. This needs fixing, but I'd rather create a new issue for it.

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

[wtoorop]

Should I open a separate issue for this then? I can cut&paste the stuff over to it
(Note that, not all NSD nodes have problem during restarts, most of them will load all catz -zones)

Yes, I would prefer that, then I can merge PR #420

[pettai]

I've hidden/removed all catz member zone stuff now, please go ahead