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:
- The zone already exists and is tied as the primary domain of an active cPanel account.
- The domain was migrated or incompletely removed, leaving orphan zone files or directives behind.
- 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:
- Log into your cPanel account.
- Under the Domains section, click on Zone Editor.
- Locate the affected domain (
domain.com) and click Manage. - In the top right corner of the record table, click the gear icon or the Actions dropdown.
- Select Reset DNS Zone.
- 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:
- Log into WHM.
- In the navigation search bar, type Reset a DNS Zone.
- 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:
- In WHM, search for Delete a DNS Zone.
- Select the conflicting domain and confirm deletion. This removes the zone file and its entry from
named.conf. - Go to Add a DNS Zone.
- 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:
- Identifies and removes the orphaned zone file from
/var/named/. - Strips the matching
zone "domain.com"directive block from/etc/named.conf. - Flushes the local DNS server caches (whether running BIND or PowerDNS).
- Updates cPanel's internal domain cache, allowing you to add the domain again without conflicts.
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:
standard: The baseline template for IPv4 zones.standardipv6: The dual-stack template for IPv6-enabled zones.simple: A streamlined template utilized for specific addon domain assignments.
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.
- Incorrect:
@ IN MX 10 192.0.2.10 - Correct:
@ IN MX 10 mail.domain.com.
❌ 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:
This post is licensed under CC BY-NC.



Comments
Join the discussion below.
0 comments