cPanel Nameserver Setup Guide Tutorial (2026): Configure Glue Records, WHM DNS, and Reliable Domain Delegation

Most cPanel DNS outages don’t come from “DNS propagation.” They come from broken delegation. Common causes include missing glue records, A/AAAA mismatches, or a registrar pointing at nameserver hostnames that never answer on port 53.

This cPanel nameserver setup guide tutorial walks you through a clean, production-ready setup on a VPS or dedicated server. It also includes checks you can run before you switch any live traffic.

You’ll set your server’s DNS identity in WHM, add correct registrar glue, clean up zone defaults, and confirm delegation from outside your network.

The goal is simple: your domain should resolve the same way for every resolver, not only from your own laptop.

What you’re building (and what you’re not)

This tutorial sticks to the classic cPanel model. Your WHM/cPanel server runs authoritative DNS (BIND/named) and serves as the nameserver for your domains.

You will set: ns1/ns2 hostnames, IP mapping, registrar glue, and sane zone templates.
You will verify: delegation, authoritative answers, SOA/NS correctness, and recursion is disabled.
You won’t do here: DNS clustering (multi-server zone sync). That’s a different design with different failure points.

If you need a server that can run cPanel plus DNS reliably, start with a VPS that has steady networking.

Make sure it also has enough RAM for named + mail + web.

A HostMyCode VPS works well for a single-node cPanel setup. If you’d rather not babysit updates, basic hardening, and routine health checks, managed VPS hosting is the practical option.

Prerequisites checklist (10 minutes)

A working cPanel/WHM installation with root access.
At least one static public IPv4 address. IPv6 is optional but recommended.
Two nameserver hostnames you control (example: ns1.example.com, ns2.example.com).
Registrar access for the domain you’ll delegate.
Firewall allows inbound DNS: UDP/53 and TCP/53.

Important reality check: if you only have one IP, you can point ns1 and ns2 to the same address. It will function, but it’s not resilient.

Treat it as a stopgap.

Step 1 — Choose your nameserver hostnames and IP plan

Use nameserver hostnames under the same domain you’ll host. The usual pattern looks like this:

ns1.yourdomain.tld → Server IPv4 (and optional IPv6)
ns2.yourdomain.tld → Second IPv4 (preferred) or same IPv4 (temporary)

If you have two IPs, assign them now. If you’re on a dedicated server or a larger VPS plan, request a second IP before you delegate anything.

Retrofitting this later is tedious, especially after you’ve pointed multiple domains at the server.

Step 2 — Configure basic WHM nameserver settings

Log into WHM as root and open:

WHM → Basic WebHost Manager® Setup

Fill these in carefully:

Nameserver 1: ns1.yourdomain.tld
Nameserver 2: ns2.yourdomain.tld
Nameserver 1 IP Address: your server IP (or dedicated IP for ns1)
Nameserver 2 IP Address: second IP (ideal) or same IP (temporary)

WHM will offer to “Assign IP Addresses to Nameservers.” Let it handle that step.

Still, don’t trust it blindly. You’ll confirm the result from the outside in Step 7.

Step 3 — Confirm your DNS service and disable recursion (authoritative-only)

A hosting nameserver should be authoritative-only. Open resolvers get abused and often end up blacklisted.

In WHM:

WHM → Service Configuration → Name Server Selection → ensure BIND/named is selected (typical cPanel default).
WHM → Service Manager → ensure named is enabled and running.

Now confirm recursion is off (or at least tightly restricted). Many cPanel installs already handle this, but verify it anyway.

sudo named-checkconf -p | sed -n '1,160p' | sed -n '/options {/,/};/p'

In the options block, look for:

recursion no; (ideal for authoritative-only)
or allow-recursion { ... }; limited to localhost/your networks

If you see permissive recursion settings, fix them using the cPanel-managed configuration. Avoid editing random include files by hand.

If you want to lock down the host in parallel, follow the hardening approach in cPanel CSF Firewall setup tutorial, then come back here.

Step 4 — Open DNS ports (UDP/TCP 53) without opening the world

DNS uses UDP and TCP on port 53. UDP handles most queries.

TCP matters for large responses and some edge cases. That includes DNSSEC-related traffic.

If you use CSF (common on cPanel servers):

WHM → Plugins → ConfigServer Security & Firewall
Allow inbound TCP_IN and UDP_IN port 53

From a shell, confirm the server is actually listening:

sudo ss -lunpt | awk 'NR==1 || /:53 /'

If named isn’t listening on :53, restart it.

Then check the service logs:

sudo systemctl restart named
sudo journalctl -u named --no-pager -n 80

Step 5 — Create glue records at the registrar (this is the part people skip)

Glue records are required when your nameservers live under the same domain you’re delegating.

Example: if example.com uses ns1.example.com, resolvers need the IP for ns1.example.com before they can ask it about example.com.

That “bootstrap” IP mapping comes from the registrar/registry, not from your zone file.

At your registrar, this is usually under a menu like:

“Register Host / Hostnames”
“Glue Records”
“Child Nameservers”

Create host records for:

ns1.example.com → your server IPv4 (and IPv6 if you’ll publish AAAA)
ns2.example.com → second server IPv4 (preferred) or same IPv4 (temporary)

Pitfall: adding A records inside your cPanel zone file is not glue. You still need the registrar-side host record.

Without it, resolution can fail intermittently, especially when caches expire.

Step 6 — Point the domain’s delegation to your nameservers

Still at the registrar, set the domain’s nameservers to:

ns1.example.com
ns2.example.com

Give it a few minutes. Then validate from an external system (not from the server itself).

Step 7 — Verify delegation and authoritative answers with dig

Run these from your laptop or any Linux box that isn’t on the same server network.

Check what the parent (TLD) thinks your nameservers are

dig NS example.com +trace

In the output, confirm:

The NS set for example.com matches ns1/ns2 you configured
You see glue A records for ns1/ns2 at the parent level

Query your nameserver directly

dig @ns1.example.com SOA example.com +noall +answer
dig @ns1.example.com NS example.com +noall +answer
dig @ns1.example.com A www.example.com +noall +answer

Repeat the same queries for ns2. Even if ns2 shares the same IP, it should still answer cleanly as its own hostname.

If it doesn’t, fix the glue and hostname/IP mapping first.

Confirm you’re getting authoritative responses

dig @ns1.example.com A example.com +norecurse

You should get an answer without the server acting as a general-purpose resolver.

To test recursion directly, try a domain your server isn’t authoritative for. It should not resolve it for you:

dig @ns1.example.com A google.com

An authoritative-only server should refuse recursion or return nothing useful.

If it resolves normally, you’ve built an open resolver. Lock it down before you delegate anything else.

Step 8 — Set correct A/AAAA records for ns1/ns2 inside the zone (good hygiene)

Glue lives at the registrar, but you should still publish A/AAAA records for your nameserver hostnames inside your authoritative zone.

This keeps the zone consistent and avoids surprises later.

In WHM, edit the zone here:

WHM → DNS Functions → Edit DNS Zone → select example.com

Add or confirm:

ns1   14400   IN   A     203.0.113.10
ns2   14400   IN   A     203.0.113.11
; Optional IPv6
ns1   14400   IN   AAAA  2001:db8::10
ns2   14400   IN   AAAA  2001:db8::11

TTL tip: during initial setup, keep TTLs moderate (3600–14400). Save 86400 for later, after you’ve seen stable answers for a few days.

Step 9 — Fix common cPanel zone defaults before you onboard more domains

If you’ll host multiple domains (or you’re reselling), fix your defaults now. Every new account inherits these templates.

Small mistakes multiply fast.

WHM → DNS Functions → Edit Zone Templates

Review these items:

SOA MNAME should be your primary nameserver (usually ns1).
SOA RNAME should be a valid mailbox format (e.g. hostmaster.example.com).
Default NS records should match ns1/ns2 exactly.
Default A record for @ should point to the correct web IP for the account.

If you also host email, align DNS early. It’s easier than cleaning up deliverability later.

For SPF/DKIM/DMARC and PTR, follow: Email authentication setup guide.

Step 10 — Confirm the server hostname, rDNS, and resolver settings (quick sanity)

This quick pass prevents annoying “web works but monitoring/mail checks fail” problems.

Check your server hostname

hostname -f

On a cPanel server, the hostname should be an FQDN like server1.example.com, not the apex domain.

Check rDNS (PTR) for the server IP (recommended)

PTR isn’t required for authoritative DNS, but it matters for email deliverability and some security tools.

If you host mail, set PTR correctly using: Reverse DNS setup tutorial.

Check your resolver config (server should resolve external updates safely)

cat /etc/resolv.conf

Use stable resolvers (often your provider’s). Avoid pointing the server at itself unless you have a specific reason and you understand the tradeoffs.

Step 11 — Add a new domain in cPanel and validate the zone end-to-end

Before you migrate anything real, create a test cPanel account. Then validate the whole path:

Create account in WHM
Confirm the zone exists
Confirm NS delegation works
Confirm web A record resolves globally

Useful commands:

# On the server: verify the zone file exists
sudo ls -lah /var/named | head
sudo grep -R "example.com" -n /var/named | head

# External: check authoritative answer for the new domain
dig @ns1.example.com A newdomain.tld +noall +answer
dig NS newdomain.tld +noall +answer

If you’re moving a site off shared hosting, the usual flow is: lower TTL, stage content, then cut DNS.

For a full staging and cutover process, use: Web hosting migration tutorial.

Troubleshooting: the 7 DNS failures you’ll actually see

1) Domain points to ns1/ns2, but resolution fails for some users

Likely cause: glue missing or wrong at the registrar.
Fix: update registrar host records to the correct IPs, then re-check dig NS example.com +trace.

2) ns1 answers, ns2 times out

Likely cause: firewall blocks port 53, wrong IP for ns2 glue, or ns2 hostname doesn’t resolve.
Fix: confirm inbound UDP/TCP 53, confirm dig A ns2.example.com +trace, confirm ss -lunpt shows listening.

3) dig works on the server but fails externally

Likely cause: you tested against localhost or internal routing; public DNS is blocked.
Fix: test from an external network and check provider security groups/firewall rules.

4) Random SERVFAIL during +trace

Likely cause: broken DNSSEC at the registrar (DS record exists but your zone isn’t signing correctly).
Fix: if you didn’t intentionally enable DNSSEC, remove DS at the registrar first. Then revisit DNSSEC later with a maintenance window.

5) You changed zone records but resolvers still show the old values

Likely cause: TTL caching (expected) or you didn’t increment SOA serial (some tooling depends on it).
Fix: in WHM zone editor, ensure changes are saved; check SOA serial increments. Query authoritative directly: dig @ns1.example.com.

6) Nameserver hostnames resolve to the wrong IP after a server move

Likely cause: glue at registrar still points to the old IP, even if your zone A record changed.
Fix: update glue host records. This is separate from zone editing.

7) Your server becomes a “DNS amplifier” target

Likely cause: recursion enabled or overly permissive.
Fix: disable recursion, restrict allow-query-cache, and consider rate limiting at the network edge.

Operational checklist for production cPanel DNS

Registrar glue host records exist for ns1/ns2 and match your intended IPs.
Domain delegation points to ns1/ns2 (not old nameservers).
Both nameservers answer on UDP/TCP 53 from outside your network.
BIND is authoritative-only (no open recursion).
Zone template defaults are correct (SOA, NS, sensible TTLs).
Basic monitoring checks exist (port 53, SOA query, and NS query).

If you want simple uptime and resource alerts for DNS alongside web and mail, set up lightweight checks using: Server monitoring tutorial.

DNS failures are often firewall or networking issues. Early alerts save a lot of time.

Summary: a stable nameserver setup is mostly about delegation discipline

WHM makes it easy to type ns1/ns2 into a form. Stability comes from getting glue right, keeping port 53 reachable, and proving your server answers authoritatively from outside your network.

Nail those three, and most “propagation issues” disappear.

If you’re building on new infrastructure, match the server to the job. A HostMyCode VPS is a solid baseline for a single cPanel host.

If you’re running many accounts or need more IP space for cleaner separation, dedicated servers are usually the better fit.

Want predictable WHM/cPanel nameserver behavior without fighting your network? Start with hosting that’s built for control panels. Choose a HostMyCode VPS for full hands-on control, or use managed VPS hosting if you prefer routine server care handled while you focus on your sites and customers.

FAQ

Do I really need two nameservers?

Yes for resilience. Some registries and corporate resolvers expect at least two NS records.

If you only have one IP today, you can run ns1/ns2 on the same IP temporarily. Plan to add a second IP or a second DNS node.

What’s the difference between glue records and A records in my zone?

Glue records live at the registrar/registry and bootstrap your in-zone nameservers. A records in your zone are normal DNS data.

You usually want both, but glue is the one that prevents circular lookups.

Why do I need TCP/53 if UDP/53 works?

Large responses (DNSSEC, long TXT records, some NS/SOA responses) can fall back to TCP. If TCP/53 is blocked, resolution can become flaky in ways that look random.

How can I test if my nameserver is accidentally recursive?

Run dig @ns1.example.com A google.com. If it resolves like a normal resolver, recursion is enabled and you should lock it down to avoid abuse and blacklisting.

Should I enable DNSSEC on cPanel nameservers?

DNSSEC is useful, but it’s unforgiving. Only enable it if you can manage keys, DS records at the registrar, and planned rotations.

A mismatched DS record causes hard failures (SERVFAIL), not “slow propagation.”