How to Set Up White-Label Custom Nameservers for Your Hosting Agency (ns1/ns2)

When running an independent web hosting company or offering managed web services through a digital agency, professional brand presentation is non-negotiable. If your clients inspect their domain DNS settings and see generic nameservers belonging to an upstream wholesale hosting provider, your agency looks like an unverified middleman rather than a reliable cloud infrastructure partner.

Setting up White-Label Custom Nameservers (such as ns1.youragency.com and ns2.youragency.com) reinforces your brand authority, conceals your upstream hosting provider, and allows you to migrate server hardware in the future without forcing clients to update their individual domain registrar configurations on a Linux VPS. In this tutorial, you will learn how to register GLUE records, configure nameservers in WHM, and update DNS zone templates.

1. Understanding GLUE Records: The Foundation of Custom DNS

When you assign nameservers located under your own root domain (e.g., youragency.com using ns1.youragency.com), a circular resolution dependency occurs:

• A browser requests clientdomain.com. The root DNS server directs the browser to query ns1.youragency.com.
• To query ns1.youragency.com, the browser must first resolve the IP address of youragency.com.
• To resolve youragency.com, the browser must query ns1.youragency.com—resulting in an infinite resolution deadlock.

To break this loop, you must register GLUE Records (Child Nameservers) directly with the Top-Level Domain (TLD) registry through your domain registrar. A GLUE record explicitly ties your nameserver hostname directly to a static public IPv4 address at the root registry level.

2. Step-by-Step GLUE Record Registration

Log in to the domain registrar where you purchased your primary agency domain (e.g., Namecheap, GoDaddy, Cloudflare, or Porkbun):

1. Navigate to the Advanced DNS or Custom Nameservers / GLUE Records management section.
2. Create two child host records:
   • Host 1: ns1.youragency.com → Point to your assigned Primary WHM Nameserver IP (e.g., 192.0.2.10).
   • Host 2: ns2.youragency.com → Point to your assigned Secondary WHM Nameserver IP (e.g., 192.0.2.11).
3. Save changes. TLD registries typically propagate GLUE records globally within 2 to 4 hours.

3. Configuring Nameservers in WebHost Manager (WHM)

Once GLUE records are registered, log in to WHM as root or reseller administrator:

1. Navigate to Server Configuration > Basic WebHost Manager Setup.
2. Scroll down to the Nameservers section.
3. In the input fields, enter your custom nameservers:

   Nameserver 1: ns1.youragency.com
   Nameserver 2: ns2.youragency.com

4. Click Assign IP Address next to each nameserver to bind them to your server’s public IPs.
5. Click Add an A Entry for this nameserver to ensure WHM generates corresponding authoritative DNS A records in your primary domain zone file.

4. Updating the Standard DNS Zone Template

To guarantee that every newly created cPanel account automatically uses your custom nameservers in its default zone file:

1. In WHM, navigate to DNS Functions > Edit Zone Templates.
2. Select the Standard Virtual Hosting Template.
3. Verify that the NS records point to your custom hostnames:

   %domain%.   IN  SOA  ns1.youragency.com.  admin.youragency.com. (
               %serial%
               3600
               1800
               1209600
               86400 )
   %domain%.   IN  NS   ns1.youragency.com.
   %domain%.   IN  NS   ns2.youragency.com.

4. Save the template. All future accounts provisioned via WHM or billing modules will inherit your branded DNS structure automatically.

5. Testing DNS Resolution & Propagation via Terminal

Verify that your custom nameservers respond authoritatively using terminal DNS diagnostic utilities:

# Query nameserver directly using dig
dig @ns1.youragency.com youragency.com A +short

# Verify authoritative NS records
dig youragency.com NS +short
# Expected output:
# ns1.youragency.com.
# ns2.youragency.com.

If dig returns your server’s public IP cleanly, your white-label nameserver cluster is fully operational and ready to serve customer traffic.

Troubleshooting Custom DNS Propagation & RFC 2182 Compliance

To ensure global email deliverability and uninterrupted web resolution, custom nameserver deployments must satisfy strict Internet Engineering Task Force (IETF) DNS standards:

• Geographic Diversity & Subnet Isolation (RFC 2182): The IETF mandates that authoritative nameservers should reside on distinct physical subnets (e.g., 192.0.2.x and 198.51.100.x). Binding both ns1 and ns2 to the exact same physical IP address or datacenter rack creates a single point of failure (SPOF) if the primary host loses upstream connectivity.
• Deploying a Free Secondary cPanel DNS Only Cluster: Rather than running standalone DNS, deploy cPanel DNS Only (a free, lightweight distribution of cPanel) on two separate low-cost VPS nodes in different continents. Link your primary WHM server to the DNS cluster using Cluster Configuration in WHM:

  WHM > DNS Functions > Cluster Configuration > Add Cluster Member

  Whenever you add or delete a domain in WHM, zone files sync instantaneously across your global DNS cluster in sub-second intervals.

• Validating Nameserver Health with DNSViz: Paste your domain into DNSViz to analyze your delegation path, verify glue records, check for lame delegations, and confirm DNSSEC cryptographic signatures.

Enterprise Custom Nameserver Health Check & Redundancy Protocol

Ensure your custom nameservers remain 100% resilient during upstream network disruptions:

• Configuring Multi-Datacenter Anycast Routing: For high-volume agencies managing hundreds of customer domains, standard unicast DNS can become a bottleneck during regional fiber cuts. Transition nameserver IPs to an Anycast network routing profile (via Cloudflare or dedicated DNS providers) so queries are answered by the geographically closest edge server.
• Setting Up Secondary Nameserver Synchronization with BIND: If you prefer to manage your own nameserver cluster on Linux VPS, configure authoritative zone transfers via AXFR/IXFR using TSIG cryptographic authentication keys in named.conf:

  key "transfer-key" {
      algorithm hmac-sha256;
      secret "GeneratedBase64SecretKeyHere=";
  };

  This ensures that when a client adds a DNS record in cPanel, the update synchronizes across all secondary nameserver nodes in milliseconds.

• DNSSEC Zone Signing in WHM: Activate Domain Name System Security Extensions (DNSSEC) in WHM DNS Functions > Manage DNSSEC Keys to cryptographically sign your zone files, permanently preventing DNS cache poisoning and man-in-the-middle spoofing attacks.