Setting Up Custom Branded Nameservers (ns1/ns2) for Agencies and Resellers

For a web agency or hosting reseller, using your own custom branded nameservers like ns1.youragency.com and ns2.youragency.com is one of the simplest ways to look more professional and keep control of your clients’ infrastructure. Instead of exposing a third‑party hosting brand in every WHOIS and DNS lookup, you present a consistent, white‑label experience under your own domain. At dchost.com, we see that agencies who invest a bit of time into a clean DNS and nameserver strategy have smoother migrations, fewer support tickets, and more flexibility when they evolve their hosting stack over time.

In this article, we will walk through how custom branded nameservers work, the exact records you need to create, how to set them up on reseller hosting or your own VPS/dedicated server, and what to watch out for when you move dozens of client domains over. We will also share practical tips from our own operations at dchost.com on TTL values, failover, monitoring, and when it makes sense to graduate from a single DNS server to a small, robust cluster.

What Are Custom Branded Nameservers and Why Agencies Love Them

Custom branded nameservers mean that instead of using something generic like ns1.somehost.com, your client domains point to nameservers under your own brand, for example:

• ns1.youragency.com
• ns2.youragency.com

Technically, these are called private nameservers or child hosts at the registry. They still run on physical or virtual servers (reseller platform, VPS, dedicated, or cluster), but the visible brand in WHOIS and DNS tools is yours.

For agencies and resellers, this brings several advantages:

• Brand consistency: Every DNS lookup, WHOIS record and client panel shows your domain, not another provider’s.
• Client stickiness: Because the DNS layer is under your control, switching infrastructure behind the scenes is easier, while clients still keep pointing to ns1/ns2.youragency.com.
• Simpler documentation: Instead of sending each client a different pair of nameservers, you standardise on a single pair for all new projects.
• Less confusion during migrations: You can change A, MX and other records centrally without asking every client to log into their registrar.

If you want a more conceptual background on what private nameservers and glue records are, you can also read our detailed guide to private nameservers and glue records. In this article, we will stay focused on the specific needs of agencies and resellers.

How Custom Nameservers Actually Work (Registrar, Glue, DNS Server)

To avoid treating custom nameservers as a black box, it helps to understand the three main pieces involved:

1. Your domain registrar – Where the parent domain (e.g. youragency.com) is registered. This is where you define the child hosts ns1.youragency.com and ns2.youragency.com, along with their IP addresses. Those child host definitions are what people usually call glue records.
2. Your DNS server(s) – The actual machine(s) that answer DNS queries. This might be a reseller hosting platform, a DNS cluster attached to your WHM/cPanel or DirectAdmin, or your own DNS software (BIND, PowerDNS, etc.) running on a VPS or dedicated server at dchost.com.
3. Client domains – The domains you manage for customers. At their registrars, these domains are configured to “use nameservers” ns1.youragency.com and ns2.youragency.com. The registry then uses your glue records to know which IPs to ask when resolving those domains.

When someone visits clientdomain.com, the following happens in simplified form:

• The resolver asks the .com registry, “Who is authoritative for clientdomain.com?”
• The registry replies, “Use ns1.youragency.com and ns2.youragency.com,” and provides their IPs (from your glue records).
• The resolver then queries your DNS server at those IPs for the A/AAAA, MX, TXT etc. records of clientdomain.com.

If any of these steps are misconfigured (wrong glue IPs, nameserver hostnames not present in DNS, or zones missing on your server), resolution fails. That is why agencies should treat DNS and nameserver setup as part of a wider hosting and DNS audit for new clients; we have a dedicated checklist for that in our hosting and DNS audit guide for agencies.

Pre‑Setup Checklist for Agencies and Resellers

Before you start changing registrar settings and asking clients to switch nameservers, take a moment to validate the groundwork. Here is a practical checklist we use when helping dchost.com resellers and VPS customers roll out their own ns1/ns2.

1. Decide Your DNS Stack

You have three common options for where your authoritative DNS will live:

• Reseller hosting DNS: Many cPanel/WHM and DirectAdmin reseller plans already include a shared DNS cluster. You simply brand it with your own ns1/ns2 hostnames. This is the fastest way to start.
• Your own VPS or dedicated DNS server(s): Ideal if you want full control, custom records at scale, or to integrate DNS automation (Ansible, Terraform, API). One or more VPS/dedicated servers from dchost.com can serve DNS only, while websites and email live elsewhere.
• Hybrid with external DNS providers: Some agencies prefer to use a specialised DNS or CDN provider but still keep branded ns1/ns2 names pointing there. If you are undecided between keeping DNS on hosting or external providers, see our comparison of Cloudflare DNS vs hosting DNS strategies.

2. Reserve Stable IP Addresses

Your ns1 and ns2 hostnames each need an IP address (IPv4, and optionally IPv6). On a shared reseller platform, these are usually provided to you. On your own VPS/dedicated server, you can:

• Use two different IPs on the same server for ns1 and ns2 (acceptable for small setups, though not real redundancy).
• Or better, use two separate servers with different IPs and locations, then run DNS on both for real high availability.

Because IP changes require updating glue at the registrar and waiting for caches to expire, choose addresses you expect to keep long term. If you are planning a wider infrastructure refresh, it is smart to align nameserver work with your overall capacity planning instead of doing it twice.

3. Confirm Panel Support (cPanel/DirectAdmin/Other)

Most agencies today either use reseller hosting or manage their own WHM/cPanel or DirectAdmin servers. Both panels can be configured to serve zones from your ns1/ns2 hostnames.

• On reseller hosting: your provider (for example, dchost.com) usually pre‑configures the DNS cluster, and you only brand the nameservers.
• On your own VPS/dedicated server: you may run DNS on the same server as websites, or offload to a separate DNS‑only node. We help many agencies do this when they outgrow basic reseller setups.

4. Plan TTL and Migration Strategy

Whenever you change nameservers, you are effectively changing which DNS servers are authoritative. That means some resolvers will cache the old answers for a while. To minimise confusion and propagation delays:

• Lower TTLs (for example from 1 day to 5–15 minutes) on key records a couple of days before any big migration.
• Only after TTLs are low, change nameservers at the registrar.
• Once everything is stable, you can raise TTLs again for better caching.

We explain these TTL trade‑offs in detail in our DNS TTL best practices guide. For now, keep in mind that nameserver changes are easier when you control DNS on both the old and new side (for example, when you already manage the client’s zone).

Step‑by‑Step: Creating ns1/ns2 on Your Agency Domain

Let us go through the sequence you will follow for almost any stack. The interface labels will differ between registrars and panels, but the logic is always the same.

Step 1: Create Glue Records (Child Hosts) at the Registrar

Log into the registrar where your agency domain is registered (youragency.com). Look for a section named something like:

• “Host records”
• “Child nameservers”
• “Glue records”
• “Register nameserver”

There you will create:

• ns1.youragency.com → 203.0.113.10 (example IPv4)
• ns2.youragency.com → 203.0.113.11

If you also have IPv6, many registrars let you add those as well (AAAA glue). Be careful to enter the correct IPs; typos here can take your whole nameserver infrastructure down. On some registrars, changes to glue can take a few hours to appear everywhere, even though they save immediately.

For more screenshots and registrar‑specific notes, again, our article on private nameservers and glue records goes deeper into the nuances.

Step 2: Create Matching A/AAAA Records in DNS for Your Agency Domain

Glue only lives at the registry level. You must also have matching DNS records in the zone of youragency.com, served by whichever DNS platform you currently use for your own website.

In the DNS zone for youragency.com, create:

• ns1.youragency.com A 203.0.113.10
• ns2.youragency.com A 203.0.113.11
• Optionally, AAAA records if you offer IPv6.

If your own domain will also move to these nameservers, you may want to keep its zone on the current DNS provider until everything is tested. It is perfectly fine for a while if ns1/ns2.youragency.com point to IPs on your future DNS servers but the zone for youragency.com is still hosted elsewhere, as long as the A/AAAA records there are correct.

Step 3: Configure Your DNS Server / Hosting Panel to Answer for Client Zones

Next, your actual DNS servers must be configured to:

• Listen on the IPs you assigned to ns1/ns2.
• Serve authoritative zones for your client domains.
• Present themselves as ns1.youragency.com and ns2.youragency.com in SOA/NS records.

How this looks depends on your stack:

• Reseller on cPanel/WHM: In WHM’s “Basic WebHost Manager Setup” you define your default nameservers. Your provider’s DNS cluster already listens on its IPs; you are simply branding them. On the client side, their zones will list ns1/ns2.youragency.com as NS records.
• Own WHM/cPanel server: In WHM you do the same, but you are also responsible for making sure the BIND or PowerDNS service is running and ports 53 (UDP/TCP) are reachable. A second server running DNS‑only can be configured as ns2.
• DirectAdmin: Under “DNS Administration” and “Nameservers” you set your custom hostnames and ensure each zone is created with those NS records. If you run multiple DirectAdmin servers, you can use one as master and another as a DNS‑only slave.
• Custom DNS on a VPS/dedicated server: Install and configure BIND, PowerDNS, or another authoritative DNS server. Create zones for each client domain and include NS records that point to ns1/ns2.youragency.com. Make sure firewall rules (for example using ufw/firewalld/iptables configuration) allow inbound DNS traffic on port 53.

Step 4: Point Client Domains to Your New Nameservers

Once your glue records are live and your DNS servers are answering properly for at least a few test domains, you can start switching real client domains:

1. Log into the domain’s registrar (or provide clear instructions to the client).
2. Change “Use these nameservers” to ns1.youragency.com and ns2.youragency.com.
3. Save and wait for propagation (typically minutes to a few hours, depending on resolver caches).

Before you do this, ensure that:

• The zone for that domain already exists on your DNS server and includes correct A, MX, TXT, CNAME and other records.
• TTL values for key records (especially old NS and A records) were lowered in advance, if possible.
• Your monitoring is ready to alert you if the site or email becomes unreachable.

Step 5: Test Resolution and Email Thoroughly

During and after migration, always verify:

• Using dig or online DNS tools, check that querying clientdomain.com’s NS records shows ns1/ns2.youragency.com.
• Ensure A/AAAA records return the correct IPs for the website.
• Check MX, SPF, DKIM and DMARC records to confirm email flows correctly; for a refresher on email DNS, see our guide to SPF, DKIM and DMARC on hosting and VPS.

Have a small pilot group of friendly clients you can move first, get feedback from, and only then roll out to the entire portfolio.

Example: Custom Nameservers on a cPanel/WHM Reseller

Many agencies start with a cPanel reseller account and later add VPS or dedicated servers as they grow. On a reseller platform, the provider typically already runs a redundant DNS cluster; you are simply replacing their ns1/ns2 brand with yours.

The high‑level flow looks like this:

1. Ask support which IPs your reseller nameservers should point to (often they provide a pair like 198.51.100.10 and 198.51.100.11).
2. At your registrar, create glue records: ns1.youragency.com → 198.51.100.10, ns2.youragency.com → 198.51.100.11.
3. In WHM’s “Basic WebHost Manager Setup”, set those hostnames as your default nameservers.
4. Wait for glue to propagate, then update client domains to use ns1/ns2.youragency.com as nameservers.

Under the hood, the DNS queries are still answered by the provider’s cluster, but nobody sees their brand. This setup works especially well if you manage many small brochure sites and want simple white‑label hosting. When you are ready to move a subset of clients to a dedicated VPS or cluster, you can keep the same ns1/ns2 hostnames but change the underlying IPs, coordinating TTLs as described earlier.

Example: Custom Nameservers on Your Own VPS or Dedicated Server

Agencies that want deeper control, custom limits, or advanced automation often move from pure reseller hosting to their own VPS or dedicated server at dchost.com. With that move, you also take responsibility for running DNS, which is where branded nameservers fit naturally.

A typical architecture we help agencies deploy is:

• One or two web hosting VPS/dedicated servers running cPanel, DirectAdmin or a custom stack (Nginx/Apache, PHP‑FPM, databases).
• One or two small DNS‑only VPS servers in different data centres, running BIND or PowerDNS.
• ns1.youragency.com pointing to DNS server 1; ns2.youragency.com pointing to DNS server 2.

Key implementation steps:

1. Provision the servers at dchost.com and secure them following a basic hardening checklist (see our firewall configuration guide for VPS servers and VPS security hardening guide).
2. Install your DNS software and configure zones for a few test domains.
3. Configure zone transfers (AXFR/IXFR) between master and slave DNS servers, if you use more than one.
4. Create glue records at your registrar for ns1/ns2, pointing to the DNS server IPs.
5. Integrate DNS provisioning with your hosting panel or deployment scripts, so new client sites automatically get DNS zones.

This way, if you later move a busy WooCommerce site from one web server to another, you only change its A record on your DNS master, and all resolvers worldwide will pick up the change as the TTL expires. Your clients still only ever see ns1/ns2.youragency.com as nameservers.

Operating Custom Nameservers at Scale: Processes That Save Time

Once you have 20, 50 or 100+ domains pointing to your ns1/ns2, the technical setup is only half the story. The other half is process: how you add, change and audit DNS records so you do not accidentally break email or SEO for a client during a busy week.

Standardise DNS Templates for New Clients

Most agency projects follow similar patterns: WordPress with one or two subdomains, maybe a separate mail provider, verification TXT records, and so on. Use your panel’s DNS templates or your own automation (API/Ansible) to create a standard zone on day one:

• Root domain A/AAAA records pointing to the correct web server IP.
• www CNAME pointing to the root domain (or its own A record if you prefer).
• MX and SPF records aligned with your email architecture. For multi‑tenant email setups, see our guide to multi‑tenant email and DNS architecture for agencies.
• TXT records reserved for future verifications (mail providers, search console, etc.).

This reduces one‑off manual work and lowers the chance of forgetting something critical.

Use Sensible TTL Defaults

For steady‑state operation, good defaults might be:

• NS and SOA: 1–2 days (rarely change).
• A/AAAA for web: 5–30 minutes (allows reasonably quick failover while still caching well).
• MX and SPF/DKIM/DMARC: 1–4 hours (mail setups change less often).

During migrations and major changes, temporarily lower TTLs a few days ahead so you can move quickly, then raise them back afterwards. Having your own ns1/ns2 means you can orchestrate these TTL changes centrally instead of relying on whatever DNS configuration a previous provider had in place.

Keep a DNS Change Log

For each client domain, keep a simple log (ticket, spreadsheet, or Git‑backed YAML/JSON) of significant DNS changes:

• When you moved it to your custom nameservers.
• When you changed web hosting IPs.
• When you switched email providers.

When something “suddenly” breaks weeks later, you can quickly correlate complaints with DNS history instead of guessing. This is especially useful for agencies with rotating staff or multiple people touching infrastructure.

Security and Reliability Considerations for Branded Nameservers

As soon as your own ns1/ns2 are in production, you are no longer just “a web designer” in the eyes of your clients; you are effectively part of their infrastructure team. It is worth taking a few extra steps to make that infrastructure trustworthy.

1. Hardening Your DNS Servers

On a VPS or dedicated server, basic hardening includes:

• Keeping the OS and DNS software updated.
• Limiting access to SSH (key‑based auth, non‑root user, firewall rules).
• Rate‑limiting or filtering abusive DNS queries if you become a reflection/amplification target.

We cover general server‑hardening practices and firewall rules in detail in our articles on VPS security hardening and VPS firewall configuration.

2. DNSSEC (When and How)

DNSSEC adds cryptographic signatures to your DNS, making it much harder for attackers to spoof responses. However, it also introduces operational complexity: you must manage keys and make sure DS records at the registry match your keys.

Our recommendation for agencies:

• Start without DNSSEC until your basic ns1/ns2 operations are solid and documented.
• Enable DNSSEC first on your own domain youragency.com and one or two low‑risk client domains to gain experience.
• Once comfortable, gradually roll it out to more important client domains.

If you are curious about the full DNSSEC lifecycle and how to avoid outages during key rollover, we wrote a practical piece on that in our DNSSEC setup guide.

3. Monitoring and Alerting

Because everything points to your ns1/ns2, a DNS outage becomes a very visible issue. At minimum, set up:

• Uptime checks for your DNS servers (port 53, and optionally a test query).
• Health checks for a few critical client domains (HTTP/HTTPS checks).
• Alerting channels (email, chat, SMS) with clear on‑call responsibility inside your team.

A DNS or hosting monitoring stack like Uptime Kuma, Prometheus/Grafana, or a third‑party uptime service is usually sufficient for agencies; the key is to keep it simple enough that it is actually maintained.

Common Mistakes When Setting Up Custom Nameservers

Having helped many resellers and agencies migrate to branded nameservers at dchost.com, we see the same pitfalls repeatedly. Watching for these will save you a lot of headaches.

• Wrong or missing glue records: If ns1/ns2 are registered with the wrong IPs, or not registered at all, nothing downstream will work. Always double‑check IPs and wait for the registrar to confirm changes.
• Forgetting to create the DNS records for ns1/ns2 in the youragency.com zone: Glue alone is not enough; resolvers will also look up ns1/ns2 via normal DNS.
• Changing nameservers before copying zones: If you change a client domain’s nameservers to ns1/ns2.youragency.com before creating its zone on your DNS server, visitors will see NXDOMAIN or timeouts.
• TTL set too high before migrations: If old records have 2–3 day TTLs, some users may still hit the old servers long after you think the migration is finished.
• Mixing different DNS stacks per client without documentation: Some clients on external DNS, some on your ns1/ns2, with no clear record of who is where. This makes troubleshooting much harder.

For a broader list of DNS pitfalls beyond nameservers, our article on the most common DNS mistakes is worth a bookmark.

When to Move from Reseller DNS to Your Own VPS or Dedicated DNS Cluster

Many agencies start by white‑labelling their provider’s DNS via custom ns1/ns2 and then, as their portfolio grows, move to their own infrastructure. Some signals that it might be time to consider a dedicated DNS cluster on VPS or bare‑metal servers at dchost.com:

• You want tighter SLAs or more transparent monitoring than a typical reseller setup offers.
• You need advanced DNS features (GeoDNS, weighted records, complex TXT/SPF management, API integration).
• You are planning multi‑region hosting or complex SaaS architectures and want DNS to be part of your automation codebase.
• You simply want to de‑risk platform mergers or ownership changes in third‑party hosting; we discussed this risk in our article on VPS provider mergers and what they mean for your servers.

The nice thing is that your branding does not have to change: ns1/ns2.youragency.com can keep their names forever. You only update their IPs to point to your new DNS servers, coordinate TTLs, and your clients keep using the same nameservers they have always seen.

Conclusion: Make Nameservers Part of Your Agency’s Infrastructure Strategy

Custom branded nameservers are one of those small infrastructure decisions that quietly pay off for years. Once you standardise on ns1/ns2.youragency.com, every new project has a predictable DNS baseline, your brand appears consistently across hosting and domain tools, and future migrations become mostly an internal exercise instead of a client‑by‑client fire drill.

From the dchost.com side, we see the smoothest agency operations where DNS, hosting, and email are treated as a single architecture instead of separate afterthoughts. That often starts with a reseller plan and branded nameservers, then gradually evolves into a mix of VPS, dedicated servers or even colocation, with DNS running on a small, hardened cluster. Wherever you are on that path, our team can help you design and implement a practical setup that fits your portfolio size and technical preferences.

If you are ready to roll out your own ns1/ns2, or want to discuss when to move from white‑label reseller DNS to fully independent infrastructure on VPS or dedicated servers, reach out to us at dchost.com. We will gladly review your current domains, registrars and hosting stack, and propose a step‑by‑step plan that keeps your clients online while you quietly gain more control over your own brand and infrastructure.