Back to blog

Private Nameservers for Reseller Hosting: Set Up ns1.yourbrand.com

IM Host EditorialOctober 14, 20267 min read
Private Nameservers for Reseller Hosting: Set Up ns1.yourbrand.com

Private nameservers are DNS server names under your own domain, such as ns1.yourbrand.com and ns2.yourbrand.com, that point to your hosting provider's DNS server IP addresses. To set them up, you register them as child nameservers (glue records) at the registrar of yourbrand.com, create matching A records, and then use them for your clients' domains. Clients see your brand in their DNS settings instead of your host's.

What private nameservers are

Every domain is delegated to a set of nameservers that answer DNS queries for it. On a reseller account those are normally your host's nameservers. Private nameservers, also called vanity, branded or child nameservers, are simply new names for the same DNS servers. Nothing changes in how DNS is served; only the names your clients type in at their registrar change.

Why glue records are needed

There is a chicken-and-egg problem. To find the address of ns1.yourbrand.com, a resolver would normally ask the nameservers of yourbrand.com, which are ns1.yourbrand.com itself. Glue records break the loop: the registry for the TLD (.com, .net and so on) stores the IP address of ns1.yourbrand.com directly and hands it out together with the delegation.

You create glue records through your domain registrar, usually in a section called "child nameservers", "register nameservers", "host records" or "glue records". The name differs between registrars; the function is the same.

Step-by-step setup

1. Pick the names

Use ns1 and ns2 on your main brand domain. Keep them short and permanent, because you will give them to every client and changing them later means every client has to update their domain.

2. Get the IP addresses from your host

Ask your hosting provider's support which IP addresses your private nameservers should point to. They must be the addresses of the DNS servers that actually hold your clients' zones. Pointing the names at a server that does not run DNS for your accounts is the most common mistake in this whole process.

3. Register the child nameservers at your registrar

At the registrar of yourbrand.com, create two child nameservers, each with its IP address:

ns1.yourbrand.com   203.0.113.10
ns2.yourbrand.com   203.0.113.11

These are documentation example addresses; use the ones your host gives you. Many registries expect at least two nameservers for a delegation, so set up both even if your host gives you closely related addresses.

4. Create A records for the nameserver names

The zone of yourbrand.com must also contain A records for ns1 and ns2 with exactly the same IP addresses as the glue:

ns1    IN  A   203.0.113.10
ns2    IN  A   203.0.113.11

Create them wherever that zone is hosted; if your brand domain lives on your reseller account, that is the Zone Editor in cPanel or the DNS editor in WHM. Glue and A records must match. A mismatch causes intermittent failures that are hard to trace, because some resolvers use the glue and others use the A record.

5. Apply the nameservers in WHM

New accounts should be created with your private nameservers in their zones. Depending on how your reseller account is configured, you either set your nameservers in WHM yourself or ask your host's support to apply them to your reseller account. If you use WHMCS, also update the nameserver fields on the server entry so welcome emails show the right names; our guide to connecting WHMCS to reseller hosting shows where that is.

Existing accounts keep the NS records they were created with, so their zones may still list the old names. Update those zones before you move the clients over.

6. Point client domains to your nameservers

At each client domain's registrar, set the nameservers to ns1.yourbrand.com and ns2.yourbrand.com. This works only after the glue records exist; registrars usually reject a nameserver name that the registry does not know.

Propagation: what to expect

The TLD registry usually publishes new glue records and nameserver changes within minutes to a few hours. Resolvers that cached the old delegation keep using it until its TTL expires, and delegation TTLs at the TLD level can be as long as about 48 hours. During that window some visitors still reach the old nameservers, so keep them serving the same records until the change has settled.

Testing with dig

Run these from any Linux or macOS terminal, or from a Linux server:

# 1. Do the nameserver names resolve?
dig +short A ns1.yourbrand.com
dig +short A ns2.yourbrand.com

# 2. Is the glue published at the .com registry?
dig NS yourbrand.com @a.gtld-servers.net

# 3. Does your nameserver answer for a client domain?
dig @ns1.yourbrand.com clientdomain.com SOA

# 4. Follow the whole delegation chain
dig +trace clientdomain.com

What to look for:

  • Test 1 should return the IP addresses your host gave you.

  • Test 2 asks a .com registry server directly. In the ADDITIONAL section you should see A records for ns1 and ns2 with the same IPs. For a .net domain the same servers apply; for other TLDs, find the registry's servers with dig NS org, replacing org with your TLD.

  • Test 3 should show the aa (authoritative answer) flag. A status of REFUSED means that nameserver does not hold a zone for the domain.

  • Test 4 shows each step from the root to your nameservers, which helps pinpoint where a delegation breaks.

On Windows, nslookup -type=NS yourbrand.com gives a quick check, although dig shows far more detail.

Common errors and fixes

  • "Nameserver does not exist" at the registrar: the child nameservers were not registered yet, or there is a typo. Register the glue first.

  • Glue IP differs from the A record: update one to match the other, then verify both with tests 1 and 2.

  • REFUSED or SERVFAIL from your nameserver: the IP is not the DNS server holding your zones, or the client's zone has not been created on the server yet.

  • Old nameserver names in client zones: accounts created before the change still list the old NS records. Update them.

  • Brand domain about to expire: if yourbrand.com lapses, every client domain using your nameservers stops resolving. Renew it for several years and keep auto-renew on.

  • Leftover DNSSEC records: if a client domain has DS records at its registrar from a previous provider, remove or update them when moving it to your nameservers, or validating resolvers will fail to resolve it.

The white-label benefit

Branded nameservers are a small detail with real effects. Clients see your company name in their domain settings, support questions come to you, and the service looks like your own infrastructure. There is a practical advantage too: if you later move to a different server, you can update the glue and A records for ns1 and ns2 instead of asking every client to change nameservers, as long as the new server serves the same zones. For more on building a branded service, read reseller hosting vs white label for agencies and the guide to DNS and email setup for reseller hosting clients.

Frequently asked questions

Do I need a separate domain for private nameservers?

No. Your main brand domain works well. Some resellers prefer a dedicated short domain, which also works, as long as you keep it renewed.

How many private nameservers do I need?

At least two. Most registries expect two or more nameservers for a delegation.

Can I set up private nameservers before I have hosting?

You can register the names, but you need the correct DNS server IP addresses from your host, so arrange the hosting first.

Do private nameservers affect speed or SEO?

Not in any meaningful way. The same DNS servers answer the same queries; only the names are different.

Private nameservers with IM HOST reseller hosting

IM HOST reseller hosting is white-label: your logo and company name appear on cPanel/WHM, and branded nameservers complete the picture. If you still need a brand domain, you can register one through IM HOST domain names, then ask support which nameserver IP addresses to use for your reseller account.

More from our blog

Discover more practical guides and product insights from the IM Host team.

View all articles