Version: 15.3 (repro), unchanged in 15.4 per changelog. Two-node cluster (v15.3, Debian 13), primary + secondary, catalog-provisioned member zones, DNSSEC-signed zones.
When a locally-hosted primary reverse zone covers the cluster nodes' own IPs, the cluster maintains PTR records for the nodes in that zone ("Cluster managed record. Do not update or delete."). Re-registering these PTRs — at every service start and on cluster config syncs — increments the zone's SOA serial in memory, re-signs the affected RRsets (RRSIG inception matches service start time), and sends NOTIFY, but the zone file is never saved (no "Saved zone file" log line; file mtime/serial stay frozen). Ordinary record edits via the API save correctly.
Consequence: on every primary restart the zone loads the stale (lower) serial from disk while the secondary retains the higher serial it was last notified of. The secondary then never transfers (its serial is higher), so the pair is deadlocked with a permanently diverged serial until unrelated content changes push the primary past the secondary — or an operator calls zones/resync on the secondary.
Repro:
Two-node cluster whose primary hosts the reverse zone covering both node IPs; catalog-member the zone.
Note the served SOA serial and the on-disk zone file serial/mtime on the primary.
Restart the primary's dns service a few times (or trigger cluster config syncs).
Served serial climbs (+N per event, NOTIFY sent each time); zone file never rewritten.
Restart the primary once more: it serves the stale file serial (lower than the secondary now holds) → secondary refuses transfers; dig SOA against both nodes shows secondary > primary indefinitely.
Expected: any code path that increments a zone's SOA serial (including cluster node record registration) persists the zone, or the registration skips the serial bump when content is unchanged.
Version: 15.3 (repro), unchanged in 15.4 per changelog. Two-node cluster (v15.3, Debian 13), primary + secondary, catalog-provisioned member zones, DNSSEC-signed zones.
When a locally-hosted primary reverse zone covers the cluster nodes' own IPs, the cluster maintains PTR records for the nodes in that zone ("Cluster managed record. Do not update or delete."). Re-registering these PTRs — at every service start and on cluster config syncs — increments the zone's SOA serial in memory, re-signs the affected RRsets (RRSIG inception matches service start time), and sends NOTIFY, but the zone file is never saved (no "Saved zone file" log line; file mtime/serial stay frozen). Ordinary record edits via the API save correctly.
Consequence: on every primary restart the zone loads the stale (lower) serial from disk while the secondary retains the higher serial it was last notified of. The secondary then never transfers (its serial is higher), so the pair is deadlocked with a permanently diverged serial until unrelated content changes push the primary past the secondary — or an operator calls zones/resync on the secondary.
Repro:
Two-node cluster whose primary hosts the reverse zone covering both node IPs; catalog-member the zone.
Note the served SOA serial and the on-disk zone file serial/mtime on the primary.
Restart the primary's dns service a few times (or trigger cluster config syncs).
Served serial climbs (+N per event, NOTIFY sent each time); zone file never rewritten.
Restart the primary once more: it serves the stale file serial (lower than the secondary now holds) → secondary refuses transfers; dig SOA against both nodes shows secondary > primary indefinitely.
Expected: any code path that increments a zone's SOA serial (including cluster node record registration) persists the zone, or the registration skips the serial bump when content is unchanged.