LiveChat 
Support 
How to Set Up Vanity Nameservers (Private/Custom DNS) the Right Way
Vanity nameservers let you replace your host’s generic DNS hostnames with branded ones like `ns1.yourdomain.com` and `ns2.yourdomain.com`. To set them up correctly, you register glue records (child nameservers) at your domain registrar, create matching DNS records so those hostnames resolve, and then point your domain to use them. The single step most people skip is the glue record, and without it your custom nameservers cannot resolve at all.
This guide is a focused technical walkthrough of that process. If you are evaluating vanity nameservers as part of a broader reseller or agency offering, the business case lives in our post. Here we stay on the wiring.
Key Takeaways
• Vanity nameservers are branded DNS hostnames (`ns1.yourdomain.com`) that hide your host’s identity behind your own domain.
• The mandatory and most-forgotten step is registering glue records (child nameservers) at your registrar — these supply the IP address for your nameserver hostname.
• You need at least two IP addresses (one per nameserver) for proper redundancy; many hosts support this, but confirm before you start.
• The full chain is: register glue → create matching A records in the DNS zone → point the domain to the new nameservers → wait for propagation.
• Skipping glue records causes a circular dependency that breaks DNS resolution entirely.
What are vanity nameservers and why use them?
A vanity nameserver (also called a private or custom nameserver) is simply a DNS nameserver that answers under your own domain name instead of your provider’s. Functionally it behaves identically to any other nameserver — it serves the authoritative DNS records for the domains pointed at it. The difference is cosmetic but strategically important: a `whois` or `dig` lookup shows your brand, not the underlying infrastructure provider.
People adopt vanity nameservers for a few consistent reasons:
- White-label branding. Resellers and agencies want every customer-facing touchpoint to carry their own name. Generic host nameservers leak the supplier’s identity in DNS lookups.
- The appearance of owned infrastructure. A domain pointed at `ns1.yourbrand.com` looks like it runs on your own hosting platform, which matters for positioning.
- Provider portability. When clients are pointed at *your* nameservers rather than a specific host’s, you can migrate the underlying platform later without asking every client to change their nameservers — you just repoint the glue records.
That last point is the underrated operational win. Vanity nameservers add a layer of indirection between your clients and your supplier, and that indirection is what gives resellers flexibility.
What do you need before you start?
Setting up vanity nameservers correctly depends on a short list of prerequisites. Confirm all of them before touching any DNS settings.
| Requirement | Why it matters |
|---|---|
| Access to your domain registrar control panel | Glue records (child nameservers) are registered at the registrar, not the host. |
| Two IP addresses for your nameservers | Best practice is `ns1` and `ns2` on separate IPs for redundancy. |
| A host that supports private nameservers | The DNS server must be configured to answer authoritatively for your hostnames. |
| Access to your DNS zone for the domain | You must create A records so the nameserver hostnames resolve. |
| Patience for propagation | Nameserver and glue changes can take time to circulate globally. |
If your provider only offers a single shared IP, you can sometimes point both `ns1` and `ns2` at the same address, but two distinct IPs is the resilient configuration and the one we recommend.
How do you set up vanity nameservers step by step?
The process has four stages. Do them in order — the sequence is what prevents the broken-DNS trap described later.
- Register the glue records (child nameservers) at your registrar. In your registrar’s domain management area, find the section labeled “Child Nameservers,” “Register Nameservers,” “Host Records,” or “Glue Records.” Create `ns1.yourdomain.com` and point it at your first server IP. Create `ns2.yourdomain.com` and point it at your second IP. This is the step that registers the glue — the IP address stored at the registry level for your nameserver hostname.
- Create matching A records in your DNS zone. In the DNS zone for `yourdomain.com`, add an A record for `ns1` pointing to the same IP, and an A record for `ns2` pointing to its IP. This ensures the hostnames resolve correctly once the domain is using them as its own nameservers.
- Point your domain to use the new nameservers. Still at the registrar, change the domain’s nameservers from the host’s defaults to `ns1.yourdomain.com` and `ns2.yourdomain.com`. From now on, your domain delegates authority to your branded nameservers.
- Wait for propagation and verify. Nameserver delegation and glue updates propagate across the internet over time. Use a lookup tool such as `dig ns1.yourdomain.com` or `dig NS yourdomain.com` to confirm the hostnames resolve to the correct IPs and the delegation is live.
Once a domain is delegated to your vanity nameservers, you (or your clients) can point other domains at `ns1.yourdomain.com` / `ns2.yourdomain.com` too — the glue you registered makes those hostnames globally resolvable.
Why are glue records the step everyone forgets?
Here is the failure mode that derails most first-time setups, and it is worth stating plainly: without glue records, your vanity nameservers create a circular dependency that DNS cannot resolve.
Think it through. You tell `yourdomain.com` to use `ns1.yourdomain.com` as its nameserver. But to *find* `ns1.yourdomain.com`, a resolver has to look up the A record for `ns1` — which lives in the DNS zone served by… `ns1.yourdomain.com`. The nameserver needs to be located before it can answer, but the answer is the only place its location is stored. That is the loop.
Glue records break the loop. A glue record is an A record stored at the registry level, attached to the parent zone’s delegation, that tells the world “`ns1.yourdomain.com` is at this IP” *before* anyone has to query the domain’s own nameserver. It is the bootstrap. When you register a child nameserver at your registrar in step 1, you are creating exactly this glue.
The practical rule: register the child nameserver / glue records first, then point your domain at them. If you reverse the order — repoint the domain to nameservers that have no glue — you can take the domain offline until the glue is added and propagates. This is why so many “my site went down after setting up custom nameservers” cases trace back to missing glue, not a bad A record or a typo.
The A records you create in step 2 still matter — they keep the hostnames resolvable for general queries and within the zone — but the glue is the load-bearing piece for the delegation itself.
How long does propagation take and how do you verify it?
Glue and nameserver changes do not appear everywhere instantly. Resolvers around the world cache delegation data, and updates roll out as those caches expire. During this window, some lookups may still see the old nameservers while others see the new ones — this is normal and resolves on its own.
To verify, lean on command-line DNS tools rather than just loading a website:
- `dig NS yourdomain.com` — confirms the domain is delegated to your vanity nameservers.
- `dig ns1.yourdomain.com` and `dig ns2.yourdomain.com` — confirm each nameserver hostname resolves to the right IP.
- `dig +trace yourdomain.com` — walks the full delegation chain from the root, which surfaces glue problems clearly if the bootstrap is missing.
If `dig +trace` shows your nameserver hostnames but no IP attached at the delegation point, that is the unmistakable signature of missing or unpropagated glue.
DarazHost: hosting that supports your own branded DNS
At DarazHost, our hosting plans — including Reseller Hosting — support private/vanity nameservers, so you can brand your DNS as `ns1.yourdomain.com` and present infrastructure that looks entirely your own. We give you the dedicated setup you need to register child nameservers and assign separate IPs for `ns1` and `ns2`.
Setting up glue records trips up a lot of people, which is exactly why our team provides hands-on guidance to register child nameservers and configure the matching A records correctly the first time — no circular-dependency outages. You also get reliable, redundant DNS and 24/7 support whenever a lookup or delegation question comes up. If your goal is to resell hosting under your own brand, vanity nameservers on DarazHost are a core part of that white-label stack.
Frequently asked questions
Do I need two IP addresses for vanity nameservers? Two distinct IPs (one for `ns1`, one for `ns2`) is the recommended, redundant configuration and is expected by some registrars. In a pinch you can point both hostnames at a single IP, but you lose the resilience that separate nameserver IPs provide.
What is the difference between a glue record and an A record here? An A record lives in your domain’s DNS zone and maps a hostname to an IP for normal queries. A glue record is registered at the registry/registrar level and is attached to the domain’s delegation, so resolvers can find your nameserver *before* querying it. For vanity nameservers you need both, and the glue is what makes the delegation actually work.
Why did my site go down after I set up custom nameservers? Almost always because the domain was pointed at vanity nameservers that had no glue records, creating a circular dependency. Register the child nameservers (glue) first, confirm they propagate, and only then delegate the domain to them.
Can my clients use my vanity nameservers for their own domains? Yes. Once `ns1.yourdomain.com` and `ns2.yourdomain.com` are globally resolvable via glue, any domain you manage can be pointed at them. This is the foundation of white-label reseller setups — see our guide for the business side.
How do I verify my vanity nameservers are working? Use `dig NS yourdomain.com` to confirm delegation, `dig ns1.yourdomain.com` to confirm each hostname resolves, and `dig +trace yourdomain.com` to inspect the full chain and catch missing glue.
