DNS zones and access control

DNS is both a developer convenience and a security boundary. Loopback treats it that way by combining:

Organization-level domains and records for the names you truly own.
Delegated pattern zones at organization / project / workspace scope so teams can self-service only the names you allow.
RBAC that can separate who manages the apex domain from who can create *.api.staging.example.com.

This page expands DNS overview with governance and wildcard guidance for buyers.

Concepts at a glance

Concept	What it means for users
Domain	A registered name Loopback can manage under your org (ownership and billing live here).
DNS records	Concrete A/AAAA/CNAME/TXT (and friends) attached to a domain.
DNS record zone	A delegation contract: “inside this domain, only names matching these patterns may be edited from this scope.”
Project / workspace DNS zones	The same idea narrowed to a team or environment—ideal for least privilege.

Why pattern-based zones exist

Without patterns, either:

Everyone shares one DNS admin role (risky), or
You manually ticket every record (slow).

Pattern zones let you say:

“Team A may create only *.dev.project-a.example.com.”
“Workspace prod-checkout may manage only api.checkout.example.com and *.api.checkout.example.com.”

Loopback enforces single-level wildcard semantics for matching (one * segment per pattern, not arbitrary recursive globbing). If you need complex rules, split zones or use multiple narrower patterns.

Wildcards: power and pitfalls

Wildcards (*.something) are invaluable for:

Multi-tenant apps that mint per-tenant hostnames.
Ephemeral preview environments (pr-123.example.dev).

Risks:

Over-broad wildcards + weak TLS issuance processes = unexpected certificate coverage.
Accidental overlap between prod and non-prod patterns.

Best practice: use separate domains or separate zone objects for prod vs non-prod, and keep apex and email-critical records under infra-only roles.

RBAC story (how fine-grained it can be)

Loopback separates capabilities such as:

Org-wide DNS vs project DNS vs workspace DNS.
Read vs create/update/delete on records.
Zone administration vs record administration (depending on deployment).

This maps cleanly to enterprise patterns:

Platform team owns apex and MX/SPF/DKIM.
Product teams own service subdomains via pattern zones.
Auditors get read-only visibility without write.

For the broader RBAC philosophy, see Auditing and fine-grained access.

Kubernetes workspace DNS (how it intersects)

Kubernetes workspaces receive API server DNS under operator-managed domains during provisioning. That is not the same as your application DNS zones—plan both:

Cluster access hostname stability for kubectl.
Application ingress names for customers.

See Kubernetes install flow for the control plane DNS story.

Operational checklist

[ ] Inventory who can edit apex records (should be tiny).
[ ] Create pattern zones per team/environment; avoid one mega-wildcard unless you accept the risk.
[ ] Align certificate issuance (ACME, corporate CA) with wildcard scope.
[ ] Ensure deleting a workspace does not silently orphan paid DNS assets—define ownership up front.