v0.2.5 (PR #14) added an options-scope allow-notify enumerating the primary
pod IP on secondaries. Options-scope config feeds the config-hash annotation
that rolls the StatefulSet, so any config change rolled the pods, the primary
came back on a new pod IP, the operator re-rendered with the new IP, the hash
changed, the pods rolled again — an infinite roll loop across every
BindCluster. The prod deployment was reverted to v0.2.4.
Replace the pod-IP allow-notify with TSIG-authenticated NOTIFY:
- Secondaries render `allow-notify { key "<name>"; };` — a static key element
with NO IPs. It depends only on the key name, so pod-IP churn can never
change the render, the config-hash, or trigger a restart.
- The primary signs its outgoing NOTIFYs: the zone-scope also-notify entries
(already enumerating replica pod IPs, applied via rndc addzone/modzone with
NO restart) now carry `key "<name>"`.
- Key choice: reuse the cluster's catalog transfer TSIG key (TransferKeyRef).
Secondaries already present it for AXFR and it is in keys.conf on every pod,
so no new key plumbing is needed.
Add a permanent regression guard for the loop class:
- controller: reconcile the ConfigMap with the primary pod on two different
IPs and assert the config-hash is byte-identical.
- render: render restart-scoped input and assert no pod IP appears in
allow-notify; RenderInput no longer has any pod-IP field.
Zone-scope also-notify (rndc, no restart) legitimately still lists pod IPs;
only restart-scoped config must be pod-IP-independent.
unkinben
aab11457af