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.

When DNS is not managed here

CorePanel drives PowerDNS through its API, into a database it owns. It will not drive a PowerDNS using the bind backend, whose zones are files on disk written by something else — an API write against one of those rewrites those files. If the panel reports

this server has no PowerDNS that CorePanel configured, so DNS is not managed here

then either PowerDNS is not installed, or the /etc/pdns/pdns.conf on this server belongs to something else. The second case is the one worth knowing about: a server being migrated in place from another control panel still has that panel’s nameserver answering for every hosted domain, at the same config path CorePanel’s would use. Writing to it through the API would rewrite the live zones of a server CorePanel does not own yet, so it refuses instead, and says so in corepanel-sys’s log:

systemctl status pdns
journalctl -u corepanel-sys | grep 'DNS management is disabled'

Once CorePanel’s own PowerDNS is installed, restart corepanel-sys — it reads that config once, at startup:

systemctl restart corepanel-sys

What still works while DNS is not managed

Accounts can still be created and imported on such a server, and their sites are served normally. Everything a site needs that is not DNS — the vhost, the document root, the PHP pool, the mailboxes, the certificate registration — is provisioned as usual, and only the zone waits. During a migration this is the point: the panel you are migrating away from is still publishing those exact zones, so nothing is missing from the internet’s point of view, and CorePanel takes them over when its own nameserver replaces the old one.

Anything held this way is reported rather than assumed. An imported account’s job report carries a deferred entry saying its zone was not published, one per site, and one per zone counting the records held from the source.

Two things are refused outright instead of held, because holding them would be a lie:

• Creating a brand-new account. Its domain has no zone anywhere and nothing would come back to publish one.
• Editing a record by hand. You asked to change DNS on a server whose DNS is not CorePanel’s; queueing that silently would report a change that did not happen.

When the zones are published

Once CorePanel’s own PowerDNS replaces the old panel’s, everything held above is written in one pass, per account:

1. the zone for each site — primary, addon and parked domains all get their own;
2. the address record of every subdomain, into the zone that owns it;
3. the account’s own records — verification TXT, CAA, external CNAMEs — merged on top from the old panel’s zone files. An address that pointed at the old server is rewritten to this one; an address pointing at a third party is preserved exactly as it was.

The account’s existing DKIM key is published with the zone, never regenerated: a new key would leave the world unable to verify signatures the server is already producing.

During an in-place migration this happens automatically, as its own step of the cutover. If the old panel’s zone files can no longer be read, the zones are still published from CorePanel’s own records — but the account’s custom records are not carried over, and the migration says so rather than leaving you to discover it.

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.