Holding records in different namespace than zone

[Hobart2967]

I currently have the folllowing setup:

• I have zones configured in namespace default
• My operator listens from namespace dns-system
• And per website, I want to enable configurability of records for a zone.

All deploys, but the operator states: "Record not selected by any DNSZone recordsFrom selector". I guess this is because it is not looking in all namespaces, but just the ones the zone is configured in. Would be nice to have such a thing!

[Hobart2967]

Any thoughts on this? I would dare to contribute, but I am not firm with rust (yet). Still on my bucket list :D

[ebourgeois]

Hi @Hobart2967 , this is by design, for security reasons I do not cross the namespace boundaries. You shoudl create your DNSZones in the same namespace as your records. If you don't want users to affect or even see the DNSZone CR, then add RBAC for that, but this is by design.

But perhaps I am not fully understanding based on the above?

[Hobart2967]

Basically I want to centralize the management of zones, but enable the management of associated records to the namespaces

so basically:
zones: Platform Team responsibility
records: Product Teams responsibilty (self-service)

[Hobart2967]

And: Actually keep responsibilites mirrored with the namespaces

[Hobart2967]

Add-On: This is actually also the way how AWS manages security through Route53 when using a multi-account setup.
Zones themselves are hosted within the main account, while records can be managed in sub-accounts @ebourgeois

[Hobart2967]

And about the security reasons: One could use and implement policies for these too, so it's fully managed by k8s then. I dont see a security flaw there.

[ebourgeois]

Hi @Hobart2967 — thanks for laying out the use case so clearly, and for the Route53 comparison. The "zones = platform team, records = product teams" split is a legitimate and common pattern, and I want to support it. I want to explain why I can't support it via cross-namespace label selection specifically, and then suggest two ways to get the same outcome today.

Why not cross-namespace selectors: the zone would admit records based on their labels — and labels are controlled by whoever writes the record. If a DNSZone in dns-system selected records across all namespaces, then any team that can create a record in their own namespace could inject any name into the shared zone: a TXT record at _acme-challenge.someothersite.example.com (which passes a DNS-01 challenge and mints a valid TLS cert for someone else's hostname), a CNAME over another team's production name, an MX for the apex, etc. Kubernetes RBAC can't close that hole — RBAC grants verbs on resources per namespace ("team-b may create ARecords in team-b"), but it can't constrain spec contents, so it can't say "team-b's records may only use names under team-b.example.com". The enforcement would have to be custom admission policy that every cluster admin must remember to install correctly, which is default-open — the wrong direction for a boundary like this.

On the Route53 analogy: I'd actually point to it as supporting the current design. AWS never lets a sub-account tag a record and have it appear in the parent account's zone. Cross-account DNS there is either NS delegation of a subdomain to a zone the sub-account owns, or an explicit, name-scoped IAM grant issued by the zone owner. There's always an owner-side grant; a cluster-wide label selector has no equivalent.

What works today — two options:

Option 1: platform-owned zone, deployed into each team's namespace. The DNSZone CR is just a few lines of YAML — your platform team can own it in Git and deploy one per product namespace (FluxCD), while RBAC makes it read-only for the team. Responsibilities stay exactly mirrored to namespaces, which is what you asked for:

# Product teams get this Role in their namespace:
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: dns-record-editor
  namespace: team-b
rules:
  - apiGroups: ["bindy.firestoned.io"]
    resources: ["arecords", "aaaarecords", "txtrecords", "cnamerecords",
                "mxrecords", "srvrecords", "caarecords"]
    verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]
  - apiGroups: ["bindy.firestoned.io"]
    resources: ["dnszones"]
    verbs: ["get", "list", "watch"]   # visible but not editable

The zone spec is centrally managed (in Git, by you), the zone records are self-service (in the namespace, by the team), and the operator never has to guess whether a record was authorized — namespace membership is the authorization.

Option 2: subdomain delegation — the actual Route53 multi-account pattern. Give each team their own zone (team-b.example.com) in their namespace, and have the parent zone in dns-system hold the NS delegation records. Each team fully self-services within a namespace-scoped blast radius; nobody can mint certs or hijack names outside their subdomain. This is the closest 1:1 mapping to how AWS does it.

Longer term: I'm open to an explicit opt-in design — something shaped like Gateway API's ReferenceGrant, where the zone owner lists which namespaces may contribute records and scopes each grant to an FQDN suffix (e.g. {namespace: team-b, fqdnSuffix: team-b.example.com}), enforced by the operator and a ValidatingAdmissionPolicy. That keeps the grant on the zone-owner side where it belongs. If that shape would work for your setup, I'd welcome the design discussion here — and it might be a friendlier first Rust contribution than it sounds. :)