implement SOA serial increment logic in ReplaceRRSet

[fr6nco]

Summary

This change fixes SOA updates to always advance serials from the live PowerDNS value instead of relying on a generated value in the desired payload.
When updating an SOA record, the controller now fetches the current SOA RRSet, parses the existing serial, increments it by one, and applies that incremented serial in the PATCH request.
The behavior is intentionally limited to SOA updates, and all other record types continue using the existing update path with no extra read call.
It also adds info-level logs for serial fetch/increment/apply steps and adds focused unit tests for both SOA and non-SOA behavior.

Why

SOA serials must be monotonic for reliable zone transfer and propagation behavior, especially under rapid consecutive updates.
Incrementing from the authoritative current serial prevents invalid or stale serial progression during high-frequency changes.

Test Plan

• Run go test ./internal/dns/pdns
• Verify SOA updates fetch current serial and patch with serial + 1
• Verify non-SOA updates do not trigger SOA serial fetch
• Confirm existing PDNS package tests remain green

Notes

The SOA flow now emits informational logs for:

• start of serial fetch
• current serial discovered
• incremented serial selected
• incremented serial applied to outbound SOA value

[fr6nco]

@mattdjenkinson Would be great if in conjunction with this we could disable the SOA serial field on the UI. The Serial would be always "auto".

[0xmc]

Hi @fr6nco, two things.

1. Without SOA-EDIT-API=NONE anything we do to the serial number with the controller is still going to also be updated by pdns. My testing shows this usually leads to the serial number being incremented by 2 on each change.
2. As implemented there is a TOCTOU race in internal/dns/pdns/client.go, ReplaceRRSet:
   • Read at client.go:688 → nextSOASerial(...) → getPDNSRRSet(...) at client.go:739 (a HTTP GET)
   • Write at client.go:735 → applyRRSetPatch(...) → applyRRSetPatch at client.go:796 (a HTTP PATCH)

Perhaps a per-zone mutex if the critical section can be kept small enough?

[fr6nco]

true, with the next iteration the current SOA Serial is reused and increments by 1. However, incrementing it by more than 1 is not considered an issue since some implementation use timestamps

[mattdjenkinson]

@mattdjenkinson Would be great if in conjunction with this we could disable the SOA serial field on the UI. The Serial would be always "auto".

So no create, edit or delete for these records?

[0xmc]

@fr6nco @mattdjenkinson we shouldn't be hiding SOA serial number, at least not for this reason. We need to bring serial number under the control plane's control and make it deterministic.

[0xmc]

@fr6nco your latest change addresses the +2 instead of +1 increment, but we're still dependent on pdns as the source of truth for the serial number, and we still have a TOCTOU around read and writing the serial number (currently around the pdns api, but the same would apply to etcd).