cPanel DNS Cluster Setup Tutorial (2026): Split DNS to Dedicated Nameservers Without Breaking Zones

Running DNS on the same cPanel box that serves websites is convenient—until it isn’t. A reboot, a DDoS event, or a disk issue can take out DNS and hosting together. This cPanel DNS cluster setup tutorial shows how to move authoritative DNS to dedicated DNS-only nameservers, sync zones from WHM, and cut over with a rollback plan.

The workflow matches hosting in 2026: lots of sites, AutoSSL everywhere, and mail records that must stay correct. Change windows should be boring.

You’ll build a small cluster (two nodes is the realistic minimum). You’ll also decide whether the main cPanel server stays as the “write source.” Then you’ll migrate zones in a controlled, test-first way.

What you’ll build (and what you won’t)

Authoritative DNS served by 2 dedicated DNS-only servers (PowerDNS via cPanel DNSOnly).
Zone sync controlled from WHM using the built-in DNS Cluster feature.
Safe cutover using TTL reduction and staged nameserver changes.
No registrar lock-in: works with any domain registrar as long as you can set custom nameservers/glue.

If you’re also moving hosting, align the DNS work with the migration plan. Changing DNS and web servers separately is a common way to create hard-to-debug issues.

If you want help coordinating the cutover, HostMyCode migrations is set up for that.

Prerequisites checklist (5 minutes)

One existing cPanel/WHM server (your “primary” where zones are managed today).
Two new VPS instances for DNS-only (recommended), each with a static IPv4. IPv6 is optional but nice.
Root access on all servers.
Ability to create/modify glue records (host records) at your domain registrar if your nameservers live under the same domain (e.g., ns1.example.com).
Ports open to the world: UDP/53 and TCP/53 on DNS nodes. Ports open between WHM and DNS nodes: TCP/2087 (WHM API). If you’ll use secure transfers, allow what the DNS software needs internally.

Picking server type: DNS doesn’t need much CPU. It does need stable networking and clean routing.

A small VPS is usually plenty. If you’re serving hundreds of zones or lots of large TXT records, leave extra headroom. For DNS nodes, a HostMyCode VPS is an easy fit.

Step 1: Provision two DNS-only nodes (Ubuntu or AlmaLinux)

cPanel DNSOnly supports the standard hosting distributions. Use what you already maintain confidently. For this tutorial, assume:

DNS1: 203.0.113.10
DNS2: 203.0.113.11
Your WHM/cPanel server: 203.0.113.20

Set hostnames that match the nameservers you plan to publish:

# On DNS1
hostnamectl set-hostname ns1.example.com

# On DNS2
hostnamectl set-hostname ns2.example.com

Patch the OS. Reboot if you picked up a new kernel:

# Ubuntu/Debian
apt update && apt -y full-upgrade
reboot

# Alma/Rocky
dnf -y update
reboot

Step 2: Install cPanel DNSOnly (PowerDNS)

Install DNSOnly on each DNS node. The installer pulls the right packages and wires up PowerDNS.

cd /home
curl -o latest-dnsonly.sh https://securedownloads.cpanel.net/latest-dnsonly
sh latest-dnsonly.sh

After install, confirm something is listening on port 53:

ss -lntup | grep ':53 '

# Quick local query
dig @127.0.0.1 ns1.example.com A +short

If dig returns nothing, that’s expected for many setups. You’re only verifying that the service is up. Zones appear after the node joins the cluster.

Step 3: Lock down DNS nodes (firewall + minimal exposure)

DNS must be reachable publicly on 53/UDP and 53/TCP. Restrict everything else. Here’s a basic UFW example on Ubuntu:

ufw default deny incoming
ufw default allow outgoing

# DNS to world
ufw allow 53/udp
ufw allow 53/tcp

# WHM cluster communication (limit to your WHM IP)
ufw allow from 203.0.113.20 to any port 2087 proto tcp

# SSH (limit to your admin IP if possible)
ufw allow 22/tcp

ufw enable
ufw status verbose

If you need an SSH hardening runbook (keys, safe rollback, 2FA), follow your internal standard.

If you don’t have one, this SSH lockdown tutorial is a solid baseline for DNS nodes too.

Pitfall: Don’t block TCP/53. Large answers (DNSSEC, long TXT records) often retry over TCP.

Step 4: Prepare your domain registrar (nameservers + glue)

If your nameservers are ns1.example.com and ns2.example.com, you need glue records at the registrar for example.com. Glue tells the parent zone which IPs serve your in-zone nameservers.

Create host records (glue):
- ns1.example.com → 203.0.113.10
- ns2.example.com → 203.0.113.11
Do not switch your domain’s nameservers yet.

Glue and reverse DNS (PTR) get mixed up often. PTR helps with mail reputation and hostname consistency. It does not make authoritative DNS work.

If you’re fixing PTR too, use: PTR record setup tutorial.

Step 5: Add DNS nodes to WHM’s DNS Cluster

Now tell WHM where to push zone changes.

Log in to WHM as root.
Go to Home → Clusters → DNS Cluster.
Click Enable DNS Clustering if it’s not already enabled.
Click Add a new server to the cluster.

For each DNS node:

Cluster Member Hostname: ns1.example.com (then add ns2 next)
Remote Server Type: cPanel DNSOnly
DNS Role: typically Synchronize Changes (WHM pushes zones)
Authentication: use the recommended WHM API token method (preferred in 2026) rather than older password auth

On the DNS-only node, create an API token (or use the mechanism cPanel recommends for your version). Then test the connection from WHM.

Don’t continue until the node shows as connected.

Sanity check: With both nodes added, WHM should list them as “Active.” If one is “unreachable,” fix routing and firewall rules first. Zone sync is only as reliable as that link.

Step 6: Reduce TTL before the cutover (so changes propagate quickly)

TTL is your recovery lever. Lower it ahead of time. Let caches expire. Then make the registrar change.

For typical hosting zones, 300 seconds works well as a temporary setting.

In WHM, edit one test domain first:

Home → DNS Functions → Edit DNS Zone
Select the domain.
Set the zone’s default TTL (and key records if needed) to 300.
Save.

Wait at least the old TTL. Until then, many resolvers will keep serving cached answers.

If you’re unsure what’s still cached during the window, use DNS propagation troubleshooting to see which resolvers still return old data.

Step 7: Push and verify zone sync (test domain first)

Use a low-risk domain as your canary. Make a small change in WHM. Then confirm both DNS nodes serve it.

From your laptop (or any external system), query each DNS node directly:

dig @203.0.113.10 example.com SOA +noall +answer
dig @203.0.113.11 example.com SOA +noall +answer

dig @203.0.113.10 www.example.com A +noall +answer
dig @203.0.113.11 www.example.com A +noall +answer

What you want to see:

SOA exists and matches your zone’s serial behavior.
A/AAAA/CNAME records match what WHM shows.
Mail records exist (MX, TXT for SPF/DKIM/DMARC) if you send mail for the domain.

Quick diagnostic if the zone is missing:

# On WHM server (paths vary by distro/cPanel version)
/usr/local/cpanel/scripts/rebuilddnsconfig

# Re-sync zones to cluster (from WHM UI) or use the DNS cluster tools.

Step 8: Validate email-related DNS records before flipping nameservers

Websites often “seem fine” during a DNS change because browsers hit cached A records. Mail is less forgiving. A missing MX, SPF, or DKIM record can cause immediate bounces.

Before switching nameservers at the registrar, confirm these answers come from DNS1 and DNS2:

MX points to the right host(s).
SPF TXT exists and matches your sender policy.
DKIM selector TXT exists (common: default._domainkey).
DMARC TXT exists (_dmarc).

dig @203.0.113.10 example.com MX +short
dig @203.0.113.10 example.com TXT +short
dig @203.0.113.10 default._domainkey.example.com TXT +short
dig @203.0.113.10 _dmarc.example.com TXT +short

If you want a mail-DNS checklist you can reuse (SPF/DKIM/DMARC/rDNS/ports), see: VPS email setup tutorial. You’re not building mail here, but the validation steps are the same.

Step 9: Switch the registrar nameservers (controlled cutover)

Once the test domain looks correct on both DNS nodes, move delegation at the registrar for that domain.

At the registrar, set nameservers to:
- ns1.example.com
- ns2.example.com
Wait for delegation to update (often minutes, sometimes longer).
Confirm delegation using dig against the TLD nameservers:

# Check delegation (looks up NS via the chain)
dig example.com NS +trace

You should see the chain delegate to ns1 and ns2. After that, answers should come from your new IPs.

If something goes wrong: The fastest rollback is switching nameservers back at the registrar. This is also why you lowered TTL first. Keep the old DNS serving correct data until the new delegation is stable.

Step 10: Migrate the rest of your zones (batch plan)

After the test domain holds steady, migrate in batches. It reduces blast radius and keeps troubleshooting manageable.

A practical batch approach:

Pick 10–20 domains.
Lower TTL to 300 at least a day ahead if current TTL is high.
Verify zone sync to DNS1/DNS2.
Switch nameservers in one registrar session.
Monitor web + mail for 30–60 minutes.

If you manage client domains, document where registrar access lives and where glue was set. That one note prevents the 2 a.m. “who owns this domain” problem.

Operational checks after cutover (don’t skip these)

After delegation points at your new nameservers, run a few quick checks. They catch most production mistakes before users do.

1) Confirm each nameserver answers authoritatively

dig @203.0.113.10 example.com SOA +noall +answer
dig @203.0.113.11 example.com SOA +noall +answer

If you see aa (authoritative answer) in the flags on verbose output, you’re set.

2) Check for “split-brain” zones

Split-brain is usually a sync problem. DNS1 has a newer serial than DNS2, or the old server still answers differently.

dig @203.0.113.10 example.com SOA +short
dig @203.0.113.11 example.com SOA +short

Serials should match. At minimum, they should move together after changes. If they drift, pause migration and fix cluster sync first.

3) Verify SSL dependencies (CAA records and validation)

If you use CAA, confirm those records exist on the new authoritative servers. A missing CAA record can block issuance, depending on your policy.

dig @203.0.113.10 example.com CAA +noall +answer

AutoSSL and Let’s Encrypt depend on correct DNS. If renewals fail after cutover, troubleshoot systematically: SSL renewal troubleshooting.

Hardening and reliability tips specific to DNS-only nodes

DNS nodes are small, internet-facing, and they attract noise. You can’t hide port 53. Keep everything else lean.

Keep the OS minimal: no extra web panels, no mail stack, no databases.
Patch regularly: schedule updates and reboots; do it during low-traffic windows.
Rate-limit abusive traffic: if you see floods, basic firewall limits help. If you need hosting-safe firewall guidance, start from your known-good patterns (and document every exception).
Separate DNS from hosting load: don’t co-locate with your busiest web node.

DNS also benefits from geographic spread. If you move beyond “two nodes in one region,” place DNS1 and DNS2 in different locations. Keep latency reasonable for your audience.

Troubleshooting: common failures and fast fixes

Problem: Domain delegates to ns1/ns2 but queries time out

Check firewall allows UDP/53 and TCP/53.
Confirm PowerDNS is listening: ss -lntup | grep ':53 '
Confirm the server’s provider security group rules (if applicable) allow 53 inbound.

Problem: DNS1 answers, DNS2 returns SERVFAIL

Compare SOA serials on both nodes.
Re-check WHM cluster membership status.
Look at DNS logs on DNS2 (paths vary). On systemd systems: journalctl -u pdns -n 200 --no-pager

Problem: Some records missing after cutover (often TXT/DKIM)

Confirm you aren’t editing zones in two places (WHM + registrar DNS, or WHM + Cloud DNS).
Ensure the domain is actually delegated to your nameservers: dig example.com NS +short
Force a zone sync from WHM and re-test.

Problem: Email bounces right after DNS move

MX record wrong or missing.
SPF missing or too strict for your sender path.
DKIM selector not present on the new DNS.

If you need a mail-focused debug flow for cPanel environments, use: cPanel email troubleshooting.

Production checklist (printable)

[ ] Two DNS-only nodes installed and patched
[ ] Port 53/UDP + 53/TCP open to the world
[ ] WHM-to-DNS nodes connectivity verified (cluster status Active)
[ ] Glue records created (if using ns1/ns2 under the same domain)
[ ] TTL reduced to 300 ahead of change window
[ ] Test domain delegated and verified (SOA, A/AAAA, MX, TXT)
[ ] Batch migration schedule defined (domain list + registrar access)
[ ] Rollback plan documented (revert nameservers + expected cache time)
[ ] Post-cutover monitoring (web + mail) for at least 60 minutes

Summary: the simplest way to stop DNS being your single point of failure

Moving authoritative DNS off the web server pays off quickly. Maintenance windows get easier. “Everything is down” incidents drop. DNS becomes its own clean layer.

Stick to a test-domain-first cutover. Keep TTL low during the move. Don’t change delegation until mail records validate on both nodes.

If you want DNS-only nodes on predictable networking with room to grow, start with a HostMyCode VPS for each nameserver. If you’d rather not run the cutover yourself, managed VPS hosting can handle provisioning, firewall rules, and routine updates.

If you’re splitting DNS off your cPanel server to reduce downtime risk, HostMyCode can provision the DNS-only nodes and help you plan a low-risk nameserver cutover. Pair HostMyCode VPS with migration support so DNS, SSL, and email changes land in the right order.

FAQ

Do I need two DNS servers, or is one enough?

One works technically, but it’s fragile. Two authoritative nameservers is the practical minimum so a single node failure doesn’t take DNS offline.

Should my WHM server still run DNS after moving to a cluster?

You can keep it running during migration, then decide. Many admins leave it enabled for local resolution but rely on DNS-only nodes for public authoritative DNS.

How long should I keep TTL at 300?

Keep it low during the whole migration window and for a day after the last domain cutover. Then raise it to 3600 or higher once everything is stable.

Will this affect AutoSSL or Let’s Encrypt?

Only if records are missing or delegation is wrong. Validate A/AAAA, CAA (if used), and that your authoritative DNS answers correctly from both nodes before renewals run.

What’s the fastest rollback if users report issues after switching nameservers?

Change the domain’s nameservers back at the registrar. With TTL lowered ahead of time, most resolvers will converge quickly.