DNS

Loopback centralizes DNS so Kubernetes API hostnames, application names, and delegated customer zones share one automation path. At a high level you work with domains, DNS records, DNS record zones (pattern-constrained delegation), and project/workspace DNS zones that scope who may edit which names.

Domain objects (organization)

Organizations hold domains - registered names Loopback can manage. Records for a domain are exposed under organization DNS APIs. Creating or updating records triggers provider sync in the execution tier: automation chooses create/update/delete at the DNS provider based on record lifecycle (for example active vs pending removal).

DNS providers

Deployment configuration maps domain settings to provider implementations (for example Cloudflare). The exact provider matrix is deployment-specific; the sync behavior is common across providers.

DNS record zones

Record zones tie a domain to optional project and/or workspace scope and carry pattern lists - wildcard-friendly allow lists for record names (for example *.api.example.dev). APIs under project and workspace enforce that only names matching those patterns can be created, using single-level wildcard semantics.

This is how you give a team self-service DNS inside a sandbox without handing them the whole zone.

Workspace and Kubernetes hostnames

Kubernetes workspaces carry DNS settings as part of workspace metadata (API hostname, provider choice such as Cloudflare vs operator-managed DNS). Provisioning registers or updates records as the control plane address becomes known.

Related reading

• Organizations billing and DNS
• Project resources
• Workspace overview
• Reconciliation (DNS entity reconciliation)
• Technical verification