Vanity Nameservers and Glue Records Explained

Vanity nameservers are custom nameserver names that use your domain:

ns1.example.com
ns2.example.com

instead of provider-owned names:

ns1.dnscale.eu
ns2.dnscale.eu

They are useful for branding, reseller setups, and some enterprise procurement rules. They do not make DNS faster by themselves.

What a Nameserver Hostname Does

A delegation says which authoritative nameservers serve a zone:

example.com.  NS  ns1.dnscale.eu.
example.com.  NS  ns2.dnscale.eu.

With vanity nameservers, the delegation might become:

example.com.  NS  ns1.example.com.
example.com.  NS  ns2.example.com.

Those hostnames still need to resolve to real authoritative DNS infrastructure.

The Circular Lookup Problem

Here is the problem:

example.com is served by ns1.example.com
but ns1.example.com is inside example.com
so how does a resolver find ns1.example.com before it can query example.com?

That is what glue records solve.

The parent zone publishes the IP address alongside the delegation:

example.com.      NS  ns1.example.com.
ns1.example.com.  A   203.0.113.53   ; glue at the parent

Now a resolver can reach the nameserver and ask it for the zone.

In-Bailiwick vs Out-of-Bailiwick

Two terms matter:

If the nameserver lives inside the zone it serves, glue is needed at the parent.

If the nameserver lives under a different domain, the resolver can resolve that nameserver through the normal DNS hierarchy.

Where Glue Records Are Managed

Glue records are managed at the registrar or registry interface, not inside your normal DNS zone editor.

For example.com, the .com parent needs to know:

ns1.example.com -> 203.0.113.53
ns2.example.com -> 203.0.113.54

You may also publish matching A/AAAA records inside the child zone:

ns1 300 IN A 203.0.113.53
ns2 300 IN A 203.0.113.54

But those child-zone records do not replace parent-side glue. They are used after delegation works.

Setup Pattern

A safe vanity nameserver setup usually looks like this:

1. Ask your DNS provider for the target IPs and supported hostnames.
2. Create host objects or glue records at the registrar.
3. Add matching A/AAAA records in the DNS zone.
4. Change the domain's NS delegation to the vanity nameservers.
5. Verify from the parent:

dig NS example.com @a.gtld-servers.net
dig A ns1.example.com @a.gtld-servers.net

6. Verify the authoritative answer:

dig SOA example.com @ns1.example.com

Do not skip parent-side checks. Your dashboard can look correct while the registry delegation is still wrong.

DNSSEC Considerations

Vanity nameservers and DNSSEC can coexist, but migrations need care.

The two dangerous mistakes:

• changing nameservers while the parent still has a DS record for the old signing keys
• changing DNSSEC keys while resolvers still cache old delegation data

If you are migrating signed DNS:

1. Lower TTLs before the migration.
2. Confirm the new provider signs the zone correctly.
3. Publish the correct DS record at the registrar.
4. Verify with multiple validating resolvers.
5. Remove old DS data only when it is safe.

For a full walkthrough, see DNS migration guide and DNSSEC setup for DNScale.

When Vanity Nameservers Are Worth It

They make sense for:

• agencies and resellers
• platforms that want customer-facing branded DNS
• enterprise policy requiring branded infrastructure names
• white-label hosting

They are usually not worth it for:

• ordinary SaaS domains
• small business websites
• teams without a specific branding or reseller requirement
• anyone trying to improve performance

Provider-owned nameservers are simpler, easier to migrate, and less likely to create glue-record mistakes.

Common Mistakes

Creating records only in the child zone

This is not enough:

ns1 300 IN A 203.0.113.53

If ns1.example.com is used as a nameserver for example.com, the parent still needs glue.

Forgetting IPv6 glue

If the nameserver has IPv6, add AAAA glue too:

ns1.example.com -> 2001:db8::53

Assuming vanity nameservers hide the provider

They hide the provider name from the NS hostname. They do not hide routing, ASN, IP ownership, SOA values, or operational fingerprints.