What Are Vanity Name Servers, and Should You Use Them?

Look up the nameservers for a domain hosted on Cloudflare and you'll see something like amy.ns.cloudflare.com. Look up a domain managed by a hosting company or digital agency, though, and you might see ns1.agencyname.com instead, even though the actual DNS service underneath is the same big provider. Those branded hostnames are vanity name servers, also called white-label or custom nameservers.

They're a small cosmetic change with surprisingly real operational consequences. This article explains what vanity name servers are, how they work at the DNS level, exactly how to set them up (with BIND and Route 53 examples), and the honest trade-offs that decide whether you should bother. If you're not yet clear on which company does what for your domain, read the difference between a domain registrar and a DNS host first, because vanity nameservers touch both.

What Is a Vanity Name Server?

A vanity name server is a nameserver hostname under your own domain, such as ns1.example.com and ns2.example.com, that resolves to the IP addresses of your DNS provider's real nameservers. Resolvers end up talking to exactly the same machines as before; only the names in the delegation change.

Compare a standard delegation with a vanity one:

; Standard delegation, as published in the .com zone
example.com.      172800  IN  NS  ns-512.awsdns-00.net.
example.com.      172800  IN  NS  ns-1024.awsdns-00.org.

; Vanity delegation for the same zone
example.com.      172800  IN  NS  ns1.example.com.
example.com.      172800  IN  NS  ns2.example.com.
ns1.example.com.  172800  IN  A   198.51.100.53
ns2.example.com.  172800  IN  A   203.0.113.53

In the vanity version, the nameserver names live inside the domain they serve. That's why the extra A records appear alongside the delegation: those are glue records, and without them a resolver could never find ns1.example.com, since finding it would require asking ns1.example.com.

Vanity nameservers come in two flavors:

1. In-domain vanity nameservers. The nameservers are inside the domain being served, like ns1.example.com for example.com. Glue is mandatory.
2. Shared branded nameservers. A host uses ns1.hostingbrand.com for thousands of customer domains. Glue is needed only for hostingbrand.com itself; every customer domain just delegates to those names.

How Vanity Name Servers Work Under the Hood

When a resolver looks up www.example.com with a vanity delegation, the flow is:

1. The resolver asks a .com TLD server about www.example.com.
2. The TLD server returns a referral: the NS records ns1.example.com and ns2.example.com in the authority section, plus their glue A/AAAA records in the additional section.
3. The resolver sends the query to 198.51.100.53 (the glue address for ns1), which is actually the DNS provider's server.
4. That server answers authoritatively from your zone.

You can watch step 2 happen by querying a TLD server directly:

dig @a.gtld-servers.net example.com NS +norecurse

With a vanity setup, the ADDITIONAL SECTION of the response contains the glue A and AAAA records for your nameserver hostnames. If that section is empty while the NS names are inside your domain, the glue is missing and resolution will fail or be flaky.

For this to work, the provider's nameservers must be willing to answer for your zone on those IPs. Most managed providers' nameservers will answer for any zone hosted in your account regardless of which hostname the delegation uses, which is what makes white-labeling possible at all.

The Records You Need

A correct vanity nameserver setup involves records in three places:

Where	What	Why
Registrar (host objects)	ns1.example.com → IPv4/IPv6	Creates the glue in the TLD zone
Registrar (delegation)	Domain NS set to ns1/ns2.example.com	Points the TLD at your vanity names
Your zone at the DNS host	A/AAAA for ns1, ns2; matching NS records; SOA MNAME	Keeps the zone consistent with the delegation

Here is what the relevant part of the zone looks like at the DNS host:

$ORIGIN example.com.
$TTL 3600
@    IN  SOA  ns1.example.com. hostmaster.example.com. (
         2026100101 ; serial
         7200       ; refresh
         3600       ; retry
         1209600    ; expire
         3600 )     ; negative caching TTL

@    IN  NS    ns1.example.com.
@    IN  NS    ns2.example.com.

ns1  IN  A     198.51.100.53
ns1  IN  AAAA  2001:db8:53::1
ns2  IN  A     203.0.113.53
ns2  IN  AAAA  2001:db8:54::1

The NS records here must match the delegation at the registrar, and the A/AAAA records must match the glue. The SOA's primary nameserver field (MNAME) is updated too, which isn't strictly required for resolution but keeps the zone tidy; see the SOA record post for what each field means.

How to Set Up Vanity Name Servers

The exact screens differ by provider, but the sequence is the same everywhere.

Step 1: Get your provider's nameserver IPs

Find the IPv4 and IPv6 addresses of the provider nameservers assigned to your zone:

for ns in $(dig example.com NS +short); do
  echo "$ns $(dig +short "$ns" A | tr '\n' ' ') $(dig +short "$ns" AAAA | tr '\n' ' ')"
done

This loops over the current NS records and prints each nameserver's A and AAAA addresses on one line. Write these down; they become your glue.

Be aware that some providers assign different nameserver sets to different zones, or recommend a specific vanity configuration through their dashboard. Use the IPs your provider documents for vanity use if they publish them.

Step 2: Create the host records in your zone

At the DNS host, add ns1 and ns2 A and AAAA records pointing to those IPs, as in the zone example above. Verify them directly against the provider's server before going further:

dig @198.51.100.53 ns1.example.com A +norecurse +short

Step 3: Register host objects (glue) at the registrar

At your registrar, look for a section named "Register nameservers," "Host records," "Child nameservers," or "Glue records." Create ns1.example.com and ns2.example.com with the same IPv4 and IPv6 addresses. The registrar submits these to the registry as host objects.

Step 4: Switch the delegation

Change the domain's nameservers at the registrar to ns1.example.com and ns2.example.com. The process is the same as any nameserver change; see how to update nameservers for a domain for registrar-specific notes.

Step 5: Update the NS records inside the zone

Replace the provider's default NS records at the zone apex with your vanity names so the parent and child agree. Some providers manage apex NS records for you and won't let you edit them unless vanity nameservers are enabled on your plan.

Step 6: Verify

dig example.com NS +trace | tail -n 20
dig @ns1.example.com example.com SOA +norecurse

The trace confirms the TLD servers now hand out your vanity names, and the direct query confirms ns1.example.com answers authoritatively for the zone (look for the aa flag).

Example: White-Label Nameservers in AWS Route 53

Route 53 supports vanity nameservers through reusable delegation sets: a fixed group of four Route 53 nameservers that you can attach to many hosted zones. Because the set is stable, you can safely glue your vanity names to its IPs.

Create a delegation set:

aws route53 create-reusable-delegation-set \
  --caller-reference "vanity-$(date +%s)"

The response includes an Id (like /delegationset/N1PA6795SAMPLE) and four NameServers. Then create the hosted zone using that set:

aws route53 create-hosted-zone \
  --name example.com \
  --caller-reference "zone-$(date +%s)" \
  --delegation-set-id N1PA6795SAMPLE

Resolve the four Route 53 nameservers to get their IPs, then add the vanity host records to the zone with a change batch:

{
  "Comment": "Vanity nameserver host records",
  "Changes": [
    {
      "Action": "UPSERT",
      "ResourceRecordSet": {
        "Name": "ns1.example.com",
        "Type": "A",
        "TTL": 172800,
        "ResourceRecords": [{ "Value": "198.51.100.53" }]
      }
    },
    {
      "Action": "UPSERT",
      "ResourceRecordSet": {
        "Name": "ns2.example.com",
        "Type": "A",
        "TTL": 172800,
        "ResourceRecords": [{ "Value": "203.0.113.53" }]
      }
    }
  ]
}

aws route53 change-resource-record-sets \
  --hosted-zone-id Z0123456789EXAMPLE \
  --change-batch file://vanity-ns.json

Repeat for ns3, ns4, and the AAAA records, update the zone's NS and SOA records to use the vanity names, and finish by registering glue and switching delegation at the registrar. For more on working with hosted zones from the CLI, see how to manage DNS records in AWS Route 53.

Benefits of Vanity Name Servers

1. Branding and white-labeling. Hosting companies, resellers, and agencies can present DNS as their own service. Customers see ns1.yourbrand.com, not the upstream vendor.
2. Provider abstraction for customers. If you manage hundreds of client domains, those clients configure your nameserver names once. If you later change upstream providers, you update glue and your own zone rather than asking every client to change their delegation.
3. Professional appearance. Some organizations simply prefer their nameservers to match their brand in RDAP output and audits.
4. Hiding the vendor. Not a security control, since IP ownership is easy to look up, but it does keep the provider out of casual view.

Drawbacks and Risks

1. You now own the glue. If your provider renumbers its nameservers, your glue points at the wrong IPs and resolution degrades. Standard delegations follow the provider automatically; vanity ones don't. Providers that offer vanity nameservers usually commit to stable IPs, but it's still your job to monitor them.
2. A self-referential dependency. With in-domain vanity names, the domain depends on its own glue. If example.com expires, is suspended, or gets hijacked at the registrar, every domain delegated to ns1.example.com breaks with it. For a host serving thousands of customers, that one domain becomes critical infrastructure.
3. Fewer nameservers, less diversity. Providers often assign four or more nameservers on different TLDs (Route 53 spreads them across .com, .net, .org, and .co.uk). A vanity setup frequently collapses this to two names under a single TLD, which removes protection against a TLD-level problem.
4. Plan restrictions. Many managed DNS providers only offer custom nameservers on higher-tier or enterprise plans.
5. IPv6 and anycast details. You must register both A and AAAA glue to keep IPv6-only resolvers happy. The underlying anycast network still works, since the IPs are the same, but only if you copy every address.
6. Multi-provider complexity. If you also want to spread a zone across two DNS vendors, vanity names add another layer of mapping to keep in sync. See using multiple DNS providers for redundancy before combining the two.

Should You Use Them?

Use vanity nameservers if you are:

• A hosting company, reseller, MSP, or agency managing DNS for many client domains under your brand.
• Planning to change upstream DNS vendors in the future and want to avoid touching every client's delegation.
• Required by a contract or compliance policy to present branded infrastructure.

Skip them if you are:

• Running your own site or a handful of company domains. Nobody looks at your nameserver names, and the default delegation is more resilient and needs zero maintenance.
• On a plan where the provider doesn't officially support them. An unsupported vanity setup can silently break when the provider changes IPs.

If you do adopt them, put the nameserver hostnames in a dedicated domain used only for DNS (for example ns1.exampledns.net), lock that domain at the registrar, set it to auto-renew for multiple years, and monitor its glue.

Monitoring Your Glue

A simple scheduled check catches the main failure mode: glue drifting from the provider's actual IPs.

#!/usr/bin/env bash
# Compare glue at the .com TLD with the A records in your own zone
for ns in ns1.example.com ns2.example.com; do
  glue=$(dig @a.gtld-servers.net "$ns" A +norecurse | awk '/^'"$ns"'\.[[:space:]]/ && $4=="A" {print $5}' | sort)
  zone=$(dig @"$ns" "$ns" A +norecurse +short | sort)
  if [ "$glue" != "$zone" ]; then
    echo "MISMATCH for $ns: glue=[$glue] zone=[$zone]"
  else
    echo "OK $ns -> $glue"
  fi
done

The script asks a .com TLD server for the glue (which appears in the additional section of the referral) and compares it with the A record your own nameserver publishes. Run it from cron and alert on any MISMATCH line.

---

Vanity Name Servers FAQ

Conclusion

Vanity name servers are a thin layer of branding on top of someone else's DNS infrastructure. Technically, they amount to a few host records at the registrar, a matching set of A/AAAA and NS records in your zone, and a delegation change. The setup takes an hour; the responsibility lasts as long as you use them, because you now own the glue that the provider used to manage for you.

For hosts, resellers, and agencies serving many clients, that responsibility is worth it: branded nameservers decouple customers from your upstream vendor and keep your service looking like your own. For everyone else, the provider's default nameservers are more diverse, need no maintenance, and resolve just as fast. Choose vanity nameservers deliberately, keep the nameserver domain locked down, and monitor the glue.

These references cover the mechanics behind vanity nameservers in more depth:

1. RFC 1034: Domain Names - Concepts and Facilities — explains delegation and why glue is required for in-zone nameservers.
2. RFC 9471: DNS Glue Requirements in Referral Responses — clarifies when authoritative servers must include glue.
3. AWS Documentation: Amazon Route 53 Developer Guide — includes the guide to configuring white-label name servers with reusable delegation sets.
4. Cloudflare Learning Center: What is a DNS NS record? — background on nameserver records and delegation.