Complete Guide to DNS Zones in cPanel and WHM: Fixing 'DNS Entry Already Exists', killdns CLI, and Advanced Templates
Back to blog

Complete Guide to DNS Zones in cPanel and WHM: Fixing 'DNS Entry Already Exists', killdns CLI, and Advanced Templates

10/3/2026 · 5 min · Servers

1. Why the 'DNS Entry Already Exists' Error Occurs (named.conf and /var/named/)#

The DNS daemon (typically BIND or PowerDNS) maintains an authoritative zone list inside /etc/named.conf, with individual record files located under /var/named/.

The Sorry, a DNS entry already exists message generally occurs under three conditions:

  1. The zone already exists and is tied as the primary domain of an active cPanel account.
  2. The domain was migrated or incompletely removed, leaving orphan zone files or directives behind.
  3. You are trying to add the domain as an addon or alias to another account while the existing zone remains registered in the server's index.

2. cPanel User-Level Resolution: Resetting the DNS Zone#

If you do not have administrative access to WHM or SSH and only manage your personal cPanel account, the interface prevents you from outright deleting the primary domain zone. The solution here is to perform a zone reset.

Resetting replaces corrupt or misconfigured entries with clean records pointing to the hosting server's default web, mail, and FTP IP addresses:

  1. Log into your cPanel account.
  2. Under the Domains section, click on Zone Editor.
  3. Locate the affected domain (domain.com) and click Manage.
  4. In the top right corner of the record table, click the gear icon or the Actions dropdown.
  5. Select Reset DNS Zone.
  6. Review and confirm the prompt. Note that custom external records (such as Google Workspace MX entries or external CDN CNAMEs) will need to be re-added afterward.

cPanel rebuilds the zone file with default records, restoring correct routing without touching your hosting files or email accounts.


3. WHM Administrative Resolution: Zone Resets and Clean Recreations#

If you have reseller or administrative access to WHM, you can manage and rebuild zones directly across the server.

Method 1: Direct zone reset#

When you simply need to restore a domain's DNS records back to default template values:

  1. Log into WHM.
  2. In the navigation search bar, type Reset a DNS Zone.
  3. Select the domain from the list and click Reset.

The existing zone file is overwritten with the server's standard template.

Method 2: Delete and recreate the zone#

If the error appeared because you are transferring a domain between accounts and WHM reports that the entry already exists:

  1. In WHM, search for Delete a DNS Zone.
  2. Select the conflicting domain and confirm deletion. This removes the zone file and its entry from named.conf.
  3. Go to Add a DNS Zone.
  4. Enter the hosting IP and domain name to create a fresh zone linked to the desired account.

4. Surgical SSH Command-Line Resolution: Purging Orphan Zones with killdns#

Sometimes a domain does not show up in WHM zone lists, yet trying to assign it to an account still triggers the already exists warning. This indicates an orphan zone: a stale .db file remains in /var/named/ or an unindexed entry exists inside /etc/named.conf.

Manually editing DNS configuration files can lead to syntax issues with BIND. cPanel provides a purpose-built script to handle orphan removal safely.

Connect to your server via SSH as root and run:

/usr/local/cpanel/scripts/killdns domain.com

What killdns does behind the scenes#

When you invoke this command, the script runs a complete cleanup sequence:

Once the command finishes, you can re-add the domain or create its zone through the interface without encountering errors.


5. Anatomy of cPanel DNS Zone Templates (/var/cpanel/zonetemplates/ and the $ip Variable)#

When a zone is reset or generated from scratch, cPanel populates it according to template definitions stored under:

cd /var/cpanel/zonetemplates/
ls -lah

Core template files include:

Inside the template, the $ip placeholder automates addressing:

@     14400  IN  A   $ip
www   14400  IN  A   $ip
mail  14400  IN  A   $ip

cPanel dynamically binds $ip using settings from WHM → Basic WebHost Manager Setup. If the account holds a dedicated IP, cPanel transparently binds $ip to that dedicated address.

6. The Bermuda Triangle of DNS: Best Practices and RFCs for MX, A, and CNAME#

DNS template errors represent a frequent cause of critical delivery incidents (L2/L3 tickets).

❌ Error 1: MX record pointing to an IP address#

MX records must always reference a Fully Qualified Domain Name (FQDN), never a raw IP.

❌ Error 2: MX record pointing to a CNAME alias#

A direct violation of RFC 2181. Major MTAs (Google Workspace, Microsoft 365) may delay delivery, degrade reputation, or reject transactions entirely. The hostname specified in the MX record must resolve directly to A/AAAA records.

❌ Error 3: mail host configured as a CNAME#

Setting mail IN CNAME domain.com introduces extraneous resolution hops, increases failure points during apex updates, and complicates network forensics.

7. Hardened Production Zone Template (SOP) and dig Validation Workflow#

It is recommended to maintain the following baseline inside /var/cpanel/zonetemplates/standard:

$TTL 14400
@  86400  IN  SOA  ns1.domain.com. root.domain.com. (
    $serial
    3600
    1800
    1209600
    86400 )

@      14400  IN  NS    ns1.domain.com.
@      14400  IN  NS    ns2.domain.com.

@      14400  IN  A     $ip
www    14400  IN  A     $ip
mail   14400  IN  A     $ip
ftp    14400  IN  A     $ip

; --- Client Autodiscover Records ---
autoconfig   14400  IN  A     $ip
autodiscover 14400  IN  A     $ip

; --- Email Routing ---
@      14400  IN  MX 10 mail.domain.com.

; --- Anti-Spoofing Hygiene ---
@      14400  IN  TXT "v=spf1 a mx ip4:$ip ~all"
_dmarc 14400  IN  TXT "v=DMARC1; p=none; aspf=r;"

Command-line validation workflow#

dig @127.0.0.1 MX domain.com +short
dig @127.0.0.1 A mail.domain.com +short
dig @8.8.8.8 MX domain.com +short
dig @1.1.1.1 MX domain.com +short

8. DNS Propagation, TTL Management, and Operational Checklist#

Whenever a DNS zone is recreated or reset, records revert to the default TTL (Time to Live) values defined in the server template (typically between 14400 and 86400 seconds).

Even if your local nameserver answers queries immediately with updated records, public resolvers and ISPs (such as 1.1.1.1 and 8.8.8.8) cache older responses until the previous TTL expires. Planning DNS resets during low-traffic windows helps ensure smooth transition while global propagation completes over the following one to four hours.

Was this article helpful?

Leave a quick reaction to help prioritize future technical guides:

CC BY-NC

This post is licensed under CC BY-NC.

Comments

Join the discussion below.

0 comments