A DNSRecord for an apex NS silently appends instead of replacing #23

New Issue

2026-09-27T00:41:58+10:00

unkin-agent commented

2026-09-27 00:41:58 +10:00

BIND ignores an RRset-wide delete of NS or SOA at a zone apex. NSUpdate implements replace as update delete <fqdn> <type> followed by update add, so a DNSRecord with name: "@" and type: NS only ever adds to the live RRset -- the delete is dropped and the transaction still reports success.

Live example: acme.unkin.net publishes both ns1.acme.unkin.net. (from the zone seed) and acme-ns1.unkin.net. (from DNSRecord acme-apex-ns, whose spec lists only the latter). The DNSRecord has reconciled cleanly for weeks and has never been able to retract the seeded name.

BindZone gained spec.nameservers in v0.3.0, which converges the apex NS per rdata and is the working path. DNSRecord has no equivalent.

Proposal

Converge an apex NS DNSRecord per rdata, as apexNSUpdates does: add the desired values, delete the live values that are not desired, adds first.
Or reject an apex NS DNSRecord at admission with an error naming BindZone.spec.nameservers, so the failure is visible instead of silent.

Acceptance criteria

A DNSRecord for an apex NS either replaces the live RRset or fails loudly.
Retracting the last remaining NS is never attempted (named rejects it, taking the whole transaction down).
An in-zone NS keeps its address record for as long as it is published.
Unit tests over the apex path.

BIND ignores an RRset-wide delete of NS or SOA at a zone apex. `NSUpdate` implements replace as `update delete <fqdn> <type>` followed by `update add`, so a DNSRecord with `name: "@"` and `type: NS` only ever adds to the live RRset -- the delete is dropped and the transaction still reports success. Live example: `acme.unkin.net` publishes both `ns1.acme.unkin.net.` (from the zone seed) and `acme-ns1.unkin.net.` (from DNSRecord `acme-apex-ns`, whose spec lists only the latter). The DNSRecord has reconciled cleanly for weeks and has never been able to retract the seeded name. BindZone gained `spec.nameservers` in v0.3.0, which converges the apex NS per rdata and is the working path. DNSRecord has no equivalent. Proposal - Converge an apex NS DNSRecord per rdata, as `apexNSUpdates` does: add the desired values, delete the live values that are not desired, adds first. - Or reject an apex NS DNSRecord at admission with an error naming `BindZone.spec.nameservers`, so the failure is visible instead of silent. Acceptance criteria - A DNSRecord for an apex NS either replaces the live RRset or fails loudly. - Retracting the last remaining NS is never attempted (named rejects it, taking the whole transaction down). - An in-zone NS keeps its address record for as long as it is published. - Unit tests over the apex path.

unkin-agent referenced a pull request that will close this issue

2026-09-27 11:04:54 +10:00

Reject an apex NS DNSRecord instead of silently appending #24

benvin closed this issue

2026-09-27 11:23:47 +10:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: unkin/bind-operator#23