DNS Zones and Records

CorePanel ships an authoritative DNS server (PowerDNS) and manages a zone for every domain it hosts. You do not have to run DNS elsewhere — but you can, and CorePanel adapts when you do.

What happens automatically

When a domain is added — as an account’s primary domain, or as an alias or addon — a zone is created for it with everything the domain needs to work:

Record	Purpose
A for the domain and www	Point the website at this server
NS	The nameservers configured for the server
MX	Mail delivery to this server
SPF (TXT)	Authorises this server to send for the domain
DKIM (TXT)	Publishes the domain’s DKIM public key

Subdomains get their A record added to the parent’s zone rather than a zone of their own.

For the domain to actually resolve, it must be delegated to your nameservers at the registrar — see Preparing Your Domain.

The DNS editor

DNS in the panel lists the zones CorePanel serves. Pick one and you get its records, with search, filtering and inline editing.

Supported record types

Type	Notes
A / AAAA	IPv4 / IPv6 address
CNAME	Alias to another name
MX	Mail exchanger — requires a priority
NS	Delegation of a subtree
TXT	Free-form text: SPF, DKIM, DMARC, domain-verification strings
SRV	Service records — priority, weight and port
CAA	Restricts which certificate authorities may issue for the domain
HTTPS	Service binding: ALPN, port, IPv4/IPv6 hints, ECH configuration

Every record carries a TTL. Values are validated before they are stored, so a malformed address or a bad priority is rejected at the panel rather than becoming a zone that fails to load.

Editing safely

A few practical rules:

• Lower the TTL before a planned change, wait for the old TTL to pass, then make the change. Resolvers keep the old answer until it expires.
• Do not remove the NS records of a zone CorePanel serves — the delegation at the registrar points at them.
• A CNAME cannot coexist with other records for the same name, and cannot be used at the zone apex.
• Changes take effect on the authoritative server as soon as they are saved; what the world sees is bounded by the TTL of the records it already cached.

Records managed for you

Some records are maintained by CorePanel and are best changed through the feature that owns them rather than by hand:

Record	Managed by
SPF, DKIM, DMARC	Email authentication
The panel hostname’s A	The server’s basic configuration
Nameserver glue (ns1/ns2 addresses)	The server’s nameserver configuration

The nameserver and hostname records are re-applied every time you save the server configuration, and are written into whichever local zone should own them — the account’s own zone when it hosts the name, otherwise the registrable parent zone.

Private nameservers need the parent zone

If you use ns1.example.com / ns2.example.com as your server’s nameservers, the zone that must exist here is example.com — not just the ns1 name. Publishing only the exact nameserver names leaves the apex, www and the CAA lookup answering SERVFAIL, and that silently blocks certificate issuance: ACME aborts before any challenge is attempted, so there is no failed validation to point at.

Using external DNS

You do not have to delegate a domain to CorePanel. When a domain’s DNS is served elsewhere, CorePanel detects it and adapts what it expects to be able to do — most visibly for mail, where it can tell you which records are missing instead of assuming it published them.

CorePanel re-checks domains daily and requires two consecutive checks agreeing before it changes a domain’s mail capability, so a single DNS hiccup does not flip a working domain into a degraded state.

The Email authentication page shows, per domain, whether SPF, DKIM and DMARC are actually visible in DNS, and gives you the exact record values to paste into an external provider.

From the CLI

DNS zones and records are managed from the panel. The CLI covers account, domain, subdomain, mail and cron operations — see the CLI reference.

Do not run pdnsutil as root

Manage zones through the panel, not with PowerDNS’s own tools. Running pdnsutil as root on a CorePanel server creates PowerDNS’s LMDB database shards with root ownership, which breaks the running DNS server — a failure measured in production, and one that file ACLs do not prevent. If you must use it, run it as the pdns user.