Renaming a DNSRecordSet owner name deletes the record that was just written

[aflor024]

What needs to happen

When a DNSRecordSet's owner name changes to a different spelling of the same DNS name — for example from the absolute api.example.com. to the relative api — the dnsrecordset-powerdns controller should end up with the record present in PowerDNS. Today it deletes it.

Why this matters

The record disappears from PowerDNS while the DNSRecordSet still reports Programmed=True, so the hostname returns NXDOMAIN with nothing in the resource status to indicate a problem. The reconciler has no periodic requeue, so recovery waits on the next watch event — the informer resync is 10h by default.

This is reachable in production right now. Gateway DNS moved to relative owner names shipped in network-services-operator v0.24.8, and enableDNSIntegration is on in staging and production, so every gateway-managed record undergoes exactly this rewrite once.

It also re-opens the conflict in the gateway DNS dual-write issue: deleting a CNAME and recreating it against an A/AAAA still present at the same name is the 422 that pins ControllerReconcileErrorRatioCritical high for this controller.

Desired outcome

A spelling change to an owner name that resolves to the same qualified PowerDNS name is a no-op against PowerDNS — no delete is issued, and the record stays programmed throughout.

More generally, the cleanup path never deletes a qualified RRset name that an existing DNSRecordSet still owns under some other spelling. A genuinely removed owner name must still be cleaned up.

Related

• Gateway DNS relative owner names — makes this reachable fleet-wide
• Gateway DNS dual-writes CNAME and A/AAAA — the 422 conflict this feeds
• DNSRecordSet delete can orphan the PowerDNS RRset: no finalizer on PDNS controller + dead cleanup path #58 — the other half of the unguarded cleanup path, where a delete orphans the RRset instead

[aflor024]

qualifyOwner in internal/pdns/client.go:759 maps three owner-name forms to
one absolute RRset name: @/empty to the zone apex, a name with a trailing dot
passed through as-is, and anything else suffixed with the zone. So
api.example.com. and api both qualify to api.example.com.

The work queue, however, is keyed on the raw spec.records[].name. The update
handler at internal/controller/dnsrecordset_powerdns_controller.go:440
enqueues both sides of the event:

enqueueRecordSetRequests(evt.ObjectNew, q)
enqueueRecordSetRequests(evt.ObjectOld, q)

A rename therefore yields two requests for the same RRset:

• (zone, CNAME, "api") — splitRecordSetsByName finds the owning
  DNSRecordSet, so this calls ReplaceRRSet and writes api.example.com.
• (zone, CNAME, "api.example.com.") — no DNSRecordSet carries that name
  any more, so owner == nil and the delete branch at line 127 calls
  DeleteRRSet, which qualifies to the same api.example.com.

DeleteRRSet (internal/pdns/client.go:361) issues an unconditional
ChangeType: DELETE with no ownership or existence check.

Both are plain q.Add with MaxConcurrentReconciles: 4, so ordering is a
race. Delete-then-create converges; create-then-delete loses the record. The
successful ReplaceRRSet is what writes Programmed=True, which is why the
status disagrees with PowerDNS.

Before NSO #318 this path was effectively unreachable: owner names were stable,
so ObjectOld and ObjectNew produced identical queue items and the workqueue
deduped them. The stale-name delete only fired on a genuine record removal.

Suggested fix — key the queue on qualifyOwner(name, zone) rather than the raw
spec name, which collapses the two requests into one and closes the whole
class, including future renames. A narrower fix is to skip the delete when the
stale name qualifies to a name an owning DNSRecordSet still holds.

Fix is up in #75.