DNS management for a website

Choose where authoritative DNS is managed

Before editing records, identify the nameservers delegated at the registrar and query the domain's authoritative NS records. The provider answering authoritatively is the system that controls public results.

• Use Core Panel native DNS when you intend to delegate the domain to the PowerDNS nameservers configured for the server.
• Keep using an external DNS provider when its nameservers remain delegated, and reproduce required website, mail, verification, and service records there.
• Do not maintain two different zones and assume they will merge. Resolvers use the delegated authoritative service.

Enable native DNS

Enable a PowerDNS zone to use the nameservers configured under System settings → DNS management . Core Panel protects authoritative SOA and NS records.

1. Configure the public nameserver hostnames under System settings → DNS management.
2. Create registrar glue records when a nameserver hostname is inside a domain it serves.
3. Enable the zone and review its SOA, NS, website, and mail records before changing delegation.
4. Confirm each authoritative nameserver answers from the public internet, then update the domain's nameservers at the registrar.

Manage records

Create and edit A, AAAA, CNAME, MX, TXT, CAA, and SRV record sets. A record set can contain multiple values. Core Panel validates record names, values, and TTLs before publishing them.

Plan TTLs and DNS cutover

TTL controls how long a resolver may reuse a cached answer. Lowering a TTL does not clear answers already cached under the previous value, so make the change at least one old-TTL interval before a planned cutover.

During a migration, record the old and new A, AAAA, MX, CNAME, TXT, and SRV values. Keep the source available for the planned overlap, validate the destination before switching, and restore normal TTLs after the observation period.

Zone operations

The DNS page can:

• Check delegation and authoritative nameserver health.
• Import a BIND-style zone file.
• Export the current zone.
• Enable DNSSEC and display the DS record for the registrar.
• Disable DNSSEC after the parent DS record has been removed.
• Review durable change history and restore a previous snapshot.
• Retry failed synchronization.
• Disable the managed zone.

Changing DNSSEC in the wrong order can make the domain unreachable. Remove the DS record at the registrar before disabling DNSSEC in Core Panel.

When native email is linked, Core Panel reconciles its managed MX, SPF, DKIM, DMARC, submission, and IMAPS values without removing unrelated records.

Enable and disable DNSSEC safely

1. Enable DNSSEC in Core Panel and copy the displayed DS record exactly.
2. Publish that DS record through the registrar or parent-zone operator.
3. Verify the signed zone and parent DS through an independent validating resolver.
4. To disable DNSSEC, remove the parent DS first, wait for the parent-side change to be effective, and only then disable signing in Core Panel.

A stale or incorrect parent DS can cause validating resolvers to return SERVFAIL even when ordinary record values are correct.

Verify authoritative DNS and propagation

• Run the delegation check and confirm every configured authoritative nameserver returns the expected zone.
• Query A and AAAA separately; an obsolete IPv6 record can send only some visitors to the wrong server.
• Check MX, SPF, DKIM, DMARC, and service records independently from website records.
• Compare answers from the authoritative nameservers with independent recursive resolvers. Different cached answers during a TTL window do not necessarily indicate a failed update.

Troubleshoot DNS changes that are not visible

1. Confirm the domain is delegated to the nameservers whose zone you edited.
2. Check for failed synchronization and compare all authoritative servers for inconsistent serials or answers.
3. Verify the exact owner name, record type, value, and TTL, including both IPv4 and IPv6.
4. Check the parent DS and DNSSEC validation state when resolvers return SERVFAIL.
5. Account for the previous TTL before treating a recursive resolver's cached response as a publishing failure.