System DNS
Overview
System DNS gives every publicly reachable resource a hostname, automatically, the moment it is provisioned. An instance that comes up on 203.0.113.7 becomes:
vm-203-0-113-7.cloud1.example.com
Named resources use their own name instead:
| Resource | Hostname |
|---|---|
| Instance | vm-203-0-113-7.cloud1.example.com |
| Load balancer | lb-frontend.cloud1.example.com |
| Managed database | db-prod-mysql.cloud1.example.com |
| Kubernetes control plane | k8s-myapp-cp.cloud1.example.com |
Records are created when a resource is deployed, updated when its IP changes, and removed when it is destroyed. Where possible a matching PTR record is set as well, so forward and reverse agree.
The domains are yours. You add one or more base domains, delegate them to your nameservers, and the platform allocates subdomains under them.
What you need first
An authoritative DNS cluster the panel can write to, registered under DNS > Providers. If you do not have one, deploy it with the kit described in PowerDNS Cluster Deployment.
Only PowerDNS providers can be used for System DNS.
Adding a domain
Go to DNS > System Domains and choose Add domain. The wizard has four steps.
Step 1: domain and provider
Enter the base domain, for example cloud1.example.com, and pick the PowerDNS provider that will host it. Set the nameserver hostnames that will appear in the zone's NS records, the record TTL, and which kinds of resource may be named under this domain.
Saving creates the zone on the provider immediately.
Step 2: delegate
The wizard shows the nameserver hostnames to enter at your registrar. Create NS records for the base domain pointing at them, plus A records for the nameserver hostnames themselves if they live under the same parent.
On Cloudflare, both must be DNS only (grey cloud).
Step 3: verify
The panel proves the delegation actually works before it starts writing records. It writes a random TXT record into the zone, then checks two things:
- The parent nameservers really delegate the domain to the nameservers you listed.
- Public resolvers can see the TXT record through that delegation.
If either fails, the reason is shown and you can retry. Delegation can take a few minutes to propagate. The TXT record is removed once verification passes.
Step 4: done
The domain is active and joins the rotation. The page also recommends submitting the domain to the Public Suffix List. This matters if your customers request TLS certificates for these hostnames: Let's Encrypt limits issuance to 50 certificates per week per registered domain, and a domain on the list is treated as a registered domain per customer rather than one shared budget. Using several base domains spreads the load until a listing takes effect.
How domains are chosen
When a resource needs a name, the platform picks the active domain that is carrying the fewest resources, so several base domains fill evenly. That choice is then sticky: a resource keeps its domain for its lifetime, so a name does not move around underneath a customer.
Domain states
| State | Meaning |
|---|---|
| Pending delegation | Created, not yet verified. No records are written. |
| Active | Verified and in use. |
| Degraded | A daily re-check could not confirm the delegation. Existing records are kept and keep resolving, but no new resources are assigned to it. |
| Disabled | Turned off by an administrator. Resources assigned to it are moved to another active domain, or lose their names if there is none. |
Degraded is set automatically and cleared automatically as soon as a check succeeds again. A problem local to your panel, such as a DNS lookup tool being unavailable, will not degrade domains, because that says nothing about whether the delegation is healthy.
Re-enabling a domain that was disabled while degraded returns it to pending delegation rather than straight to active. Verify it again to confirm the delegation before it starts taking new resources.
Disabling a domain that has resources assigned will rename those resources on the next reconciliation. Their current hostnames stop resolving. The confirmation dialog tells you how many resources are affected.
Reverse DNS
When a record is created, the platform also sets the matching PTR record for that IP, so a reverse lookup returns the same hostname. This is what mail servers and reputation systems check.
A PTR that you or your customer set manually is never overwritten. Reverse DNS also requires a reverse zone configured for that IP range; see Private DNS and Reverse DNS.
Keeping records correct
Records are written when a resource changes, and an hourly reconciliation catches anything the immediate path missed, for example if the provider was briefly unreachable. It also removes records for resources that no longer exist and corrects records whose IP or TTL has drifted.
DNS never blocks provisioning. If the provider is unavailable, the resource is still created and its record is written when the provider comes back.
Where names appear
The hostname is shown on the instance, load balancer, managed database and Kubernetes cluster pages, with a copy button, and is included in the API responses for those resources as dns_name.