When you look up who serves a domain's DNS, you usually see your provider's generic names, something like ns1.bigdnsco.net. Vanity nameservers let you replace those with names on your own domain, such as ns1.yourdomain.com and ns2.yourdomain.com, while the actual DNS service still runs on your provider's infrastructure. For agencies, resellers, and anyone who wants a consistent brand, it is a clean touch. It also requires glue records to work, and it adds a little maintenance. This guide covers what vanity nameservers are, how the glue makes them resolvable, how to set them up, and when they are worth it.
What vanity nameservers actually are
A vanity nameserver, also called a private or white-label nameserver, is a nameserver hostname that lives under your own domain but points to a DNS platform you do not have to operate. The records, the servers, and the anycast network all belong to your provider; only the names shown in the delegation are yours. Anyone running a dig NS on your domain, or on domains you manage, sees your brand rather than the provider's.
The key point is that this is cosmetic at the DNS-service level but real at the naming level. You are not running BIND in a closet. You are creating hostnames in your zone and glue at your registrar so that ns1.yourdomain.com resolves to the provider's server address, and then telling the world your domain is served by those names.
Why glue records are required
Glue records are the part people miss, and without them the whole thing fails to resolve. The problem is circular. To look up yourdomain.com, a resolver must ask its nameservers. But you just told the world those nameservers are ns1.yourdomain.com and ns2.yourdomain.com, which are themselves inside yourdomain.com. To find their addresses, the resolver would need to query yourdomain.com, which it cannot reach without first knowing those addresses. A nameserver inside the very zone it serves is called in-bailiwick, and this loop is exactly what glue breaks.
Glue records are A and AAAA records for your nameserver hostnames, stored at the parent zone (the TLD, through your registrar) rather than only in your own zone. When the .com servers refer a resolver to ns1.yourdomain.com, they also hand over its IP address in the same response, so the resolver can proceed without a second lookup.
; Conceptually, the .com servers return a referral WITH glue:
yourdomain.com. NS ns1.yourdomain.com.
yourdomain.com. NS ns2.yourdomain.com.
; glue (additional section) breaks the loop:
ns1.yourdomain.com. A 198.51.100.10
ns2.yourdomain.com. A 198.51.100.11Setting up vanity nameservers
The setup is a two-place operation: your registrar for the glue and delegation, and your DNS provider so it answers for your branded names.
| Step | Where | What you do |
|---|---|---|
| 1. Get the provider IPs | DNS provider | Find the addresses (and vanity feature) your provider assigns for white-label NS |
| 2. Register host objects / glue | Registrar | Create ns1 and ns2 under your domain, each with the provider's IP |
| 3. Point the domain at them | Registrar | Set the domain's NS records to ns1/ns2.yourdomain.com |
| 4. Enable vanity on the provider | DNS provider | Tell the provider to answer authoritatively for your branded names |
The first step your registrar calls registering a host object or a child nameserver, and it is where the glue is created. You enter the hostname and the IP your provider gave you. Only after those host objects exist can you select them as the domain's nameservers.
# After setup, the delegation shows your names
$ dig NS yourdomain.com +short
ns1.yourdomain.com.
ns2.yourdomain.com.
# And those names resolve, thanks to glue
$ dig A ns1.yourdomain.com +short
198.51.100.10To use the same vanity nameservers for client domains you manage, you point each client domain's NS records at ns1.yourdomain.com and ns2.yourdomain.com. Those client domains do not need their own glue, because the nameserver names live under yourdomain.com, which resolves independently. Only your own domain, where the names actually reside, needs the glue.
When vanity nameservers are worth it
Vanity nameservers buy you brand consistency and a measure of portability, at the cost of a setup step and an ongoing dependency. They make the most sense in a few situations:
- Agencies and resellers. Every client domain shows your nameservers, reinforcing your brand and hiding which provider you resell.
- Provider portability. If you ever change DNS platforms, you can update the glue IPs behind your vanity names rather than re-delegating every client domain. The names stay the same; only the addresses behind them move.
- A polished, professional look. For some businesses, generic third-party nameservers in a WHOIS or
digoutput simply look less finished.
They are not worth it when you run a single domain and nobody inspects your nameservers, or when your provider does not support white-label service, in which case you would have to actually run nameservers yourself. There is also a real maintenance note: if your provider changes the IPs behind your vanity names, you must update the glue at your registrar, or resolution breaks.
Common pitfalls
- Missing or wrong glue. The most common failure. If the registrar has no glue for your in-bailiwick names, resolvers cannot find them and the domain goes dark.
- Provider not configured. Creating the names at the registrar is not enough; the DNS platform must also be told to answer for them, or it will not serve your zone under those names.
- Glue drifting from reality. If the provider's assigned IPs change and your glue does not, the names resolve to dead addresses.
- Only one working nameserver. Register both ns1 and ns2 with correct glue; a single nameserver is fragile and some registries reject it.
Verify the delegation and the glue
Because vanity nameservers hinge on the parent handing out correct glue, trace the whole chain after setup rather than trusting the registrar screen. Run your domain and your nameserver hostnames through the Valla DNS nameserver and propagation tools to confirm the NS records show your branded names, the glue resolves to the right addresses everywhere, and the zone answers authoritatively. Pair this with our guides on glue records and on delegating a subdomain with NS records so every hop in the chain checks out before you rely on it for client domains.