# DNS Zones and Records > CorePanel runs its own authoritative DNS. Every domain gets a zone with the records it needs, and the editor lets you add anything else the domain requires. Source: https://www.corepanel.net/docs/dns/ Last updated: 2026-08-27 Part of the CorePanel documentation — https://www.corepanel.net/docs --- 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](https://www.corepanel.net/docs/domain-setup). ## 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](https://www.corepanel.net/docs/email/mailboxes#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: ```bash 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: ```bash 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](https://www.corepanel.net/docs/cli). > **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.