## Why
New forward records (netbox, logs-ingest .k8s.syd1.au.unkin.net) stopped
appearing in DNS after #287. Root cause is a half-completed migration, not
an external-dns fault:
- #287 (step 2/3) repointed external-dns RFC2136 updates from the legacy VM
`ausyd1nxvm2127.main.unkin.net` to the in-cluster `bind-externaldns-primary`.
- external-dns is writing correctly: the in-cluster bind (198.18.200.8 /
bind-resolvers 198.18.200.7) HAS netbox + logs-ingest A records and their
external-dns TXT ownership records (SOA serial 5).
- But the estate's client-facing resolvers (e.g. 198.18.2.160) still source
the zone from the legacy VM authoritative, which is alive but now FROZEN:
it keeps old names (identity, argocd, grafana resolve fine) and never
receives the new writes. Step 3 (cut resolver/delegation reads over to the
in-cluster bind) was never done, so writes moved ahead of reads.
Reverting restores external-dns writes to the legacy authoritative that
clients actually read, immediately unblocking new-record publication. This
is exactly the rollback path documented in #287 ("The legacy VM is untouched
and still authoritative"). Re-attempt the cutover only after step 3 lands.
## Changes
- `--rfc2136-host` back to `ausyd1nxvm2127.main.unkin.net`.
- TSIG secret ref back to Vault-backed `externaldns-tsig` (still present in
the namespace).
## Note
The per-cycle PTR add/remove thrash on 198.18.200.4 and the "Couldn't parse
... as an IP address" debug lines are a separate, cosmetic external-dns
rfc2136 multi-target-PTR quirk; they are NOT the cause of the missing A
records and are unaffected by this change.
Claude-Session: https://claude.ai/code/session_015ur3i7D2azsMAWTSVABApv
unkinben
0ec308b76e