A white label nameserver is a hostname like ns1.yourbrand.com that you give a customer to enter at their registrar, in place of the hostname your DNS provider would hand out. It looks like a naming change. It is not. Four places are involved: your own zone, the registry's glue, the parent zone's delegation, and for signed zones the DS record. They do not update at the same moment, and most failures happen in the gaps.
We make CustomDomain™, a product of EverJust Company in Minneapolis: a widget that SaaS platforms embed so their customers can connect their own domains, with DNS automation, certificate issuance and a reverse proxy edge behind it. This post is on our blog, so weigh it accordingly. Running vanity nameservers yourself is a different job from what we sell, and where we could not check a point against a primary source we say so or leave it out. The wider topic lives on our white label domain pillar page; this post stays on nameservers.
What white label nameservers are
AWS documents the idea under the name white-label name servers, and notes that they are also called vanity or private name servers. A delegation is a set of NS records in the parent zone naming the hostnames that answer for a child zone. White label means those names belong to your domain, not the provider's.
The servers behind the names do not change. ns1.yourbrand.com resolves to a server that already hosts your customers' zones, so a resolver ends up where it always did. What changes is who owns the naming. If yourbrand.com expires, or its own delegation breaks, every customer zone delegated to ns1.yourbrand.com stops resolving with it. That follows from how delegation works, not from any one source. It is why the vanity domain is infrastructure, not branding.
Why glue records exist
Take yourbrand.com with the nameservers ns1.yourbrand.com and ns2.yourbrand.com. A resolver asks the .com servers where yourbrand.com lives and is told: ask ns1.yourbrand.com. To do that it needs an address for ns1.yourbrand.com, and the only servers that could tell it are the ones it is trying to reach. The lookup is circular. The ICANN glossary defines glue as a zone record that supplies a name server's IP address, and SSAC advisory SAC125 (pages 10 to 11) says in-domain nameservers need glue to break exactly this dependency.
; what the .com servers hold for yourbrand.com
yourbrand.com. NS ns1.yourbrand.com.
yourbrand.com. NS ns2.yourbrand.com.
ns1.yourbrand.com. A 192.0.2.10 ; glue
ns2.yourbrand.com. A 192.0.2.11 ; glueThe rules for sending that glue were tightened recently. RFC 9471, a Standards Track document from September 2023 that updates RFC 1034, says in section 3.1 that a referral must include all available in-domain glue, or else set the truncation flag (TC=1) so the resolver retries. Section 3.2 is weaker for sibling glue: only a SHOULD, with TC optional.
Which domains actually need glue
This is the part people get wrong. Your customer's customer.com delegates to ns1.yourbrand.com. That hostname is not inside customer.com, so the customer's delegation does not need glue of its own. The glue lives with yourbrand.com, the domain that owns the nameserver names. That is our reading of the in-domain rule, not a quotation from the sources above.
One wrinkle: if customer.com and yourbrand.com both sit under .com, your registered glue is sibling glue from the customer's side. RFC 9471 asks for it only as a SHOULD, so a resolver may sometimes look the address up itself. We have not measured how often, and claim no breakage.
What the registrar step really does
The registrar form that asks you to "register a nameserver" or "add a glue record" is not editing your zone. RFC 5732, the EPP host mapping, describes host objects as Internet host names stored in the registry's shared repository. In its example, ns1.example1.com is subordinate to example1.com (section 1.1). Section 3.2.1 says IP addresses are "REQUIRED only as needed to produce DNS glue records." So the registrar is asking the registry to create a host object with addresses, and the registry publishes those addresses in the parent zone.
Registrars label this differently and we have not surveyed them, so no button names here. What matters is that the glue addresses and the A records for ns1 and ns2 in your own zone agree, and that you do things in sequence. The AWS guide follows the same sequence: create the A records first, add the glue second, and only then change the nameserver list on the domain.
How many nameservers
RFC 2182 (BCP 16, July 1997) gives the floor and the usual recommendation in section 5: two servers is the minimum, and three is recommended for most organisation zones. Section 3.1 adds that secondaries should be dispersed topologically and geographically.
The AWS design uses a set of four. Four is not mandatory, and nothing we verified says more is better. The RFC cares that servers fail independently. Four names pointing at one rack meet a count and miss the intent, so check where the glue addresses actually live.
Why a switch takes up to two days to settle
The delegation lives in the parent zone and the parent decides how long it may be cached. We checked on 8 October 2026 with this command:
dig @a.gtld-servers.net example.com NS +norecurseThe NS records came back with a TTL of 172800 seconds, which is 48 hours. The glue for ns1.google.com was also 172800; the child-side NS record in Google's own zone was 86400. A resolver that cached the old delegation just before you changed it can keep using it for up to two days. That is one TLD's servers on one day, not a rule for every registry. Our own advice, not a sourced rule: keep the old servers running and answering correctly for at least that long.
| Piece | Where it lives | What you control |
|---|---|---|
A records for ns1 and ns2 | Your own zone | Value and TTL, immediately |
| Host objects (glue) | The registry, through your registrar | Addresses; the registry sets publication timing |
| NS delegation | The parent zone, for example .com | The names; the parent sets the TTL (172800 s when we measured) |
| DS record, if signed | The parent zone only | Key tag, algorithm and digest, through the registrar |
The reusable delegation set, and its limits
Route 53 is the one worked example we could check. Its white-label name servers guide builds the feature on a reusable delegation set of four servers. The sequence is: create the set through the API, CLI or an SDK; create hosted zones with that set; set the NS and SOA TTL in those zones to 60 seconds or less; add A or AAAA records for ns1 to ns4; add the glue at the registrar; then switch the domain to the new nameservers.
The limits matter more than the steps. They are on the CreateReusableDelegationSet reference page. A set can be attached only when a zone is created, so an existing zone cannot be moved onto it. It works only within the same AWS account. It does not apply to private hosted zones. If your customers' zones already exist, you are recreating them, not relabeling them.
The 60 second guidance applies to records inside the zones you host. It does not shorten the parent's cache of the delegation, which is the 172800 second figure above. Two clocks, and low TTLs in your zone do not speed up the registry side. We have not verified how other DNS providers implement vanity names, so we do not describe them.
Before you switch, check DNSSEC
If the domain is signed, the DS record is the thing to look at. RFC 4034, section 5, defines it as holding a key tag, an algorithm and a digest, and it sits only at the parent. Our inference, not the RFC's wording: the DS tracks keys, not NS hostnames. Renaming the nameservers alone would not change it. Moving the zone to servers that sign with different keys would leave the old DS pointing at keys that are no longer served, and a validating resolver would reject the answers.
RFC 8078, section 1.2, says that moving between DNS operators sometimes requires DNSSEC to be turned off. Before a switch:
- Find out whether the domain has a DS record at the parent, and whether the new servers will serve a zone signed with the same keys.
- If the keys will change, plan the DS update with the registrar before the nameserver change, not after.
- Confirm the A records and host objects agree.
- Leave the old servers answering for at least the parent TTL you measured.
- Afterward, check the delegation, the glue and the answers from outside your own network.
Our free Domain Health Check is read only, so you can run it before and after. If a switch has already gone wrong, our notes on when a white label domain is not working start from the symptom.
Where this sits next to connecting a customer's domain
Vanity nameservers mean you host the customer's whole zone and answer for everything in it, the apex included. The widget approach we sell works differently in general terms: the customer keeps their DNS where it is, and the platform adds the few records needed for their hostname, through automation where the provider allows it. That describes the approach, not every setup, and it is no argument against nameservers. If you already host customer zones, as a reseller or agency platform might, vanity names fit. The reseller and agencies pages cover those cases, how it works covers the connection path, and the white label custom domain page covers the customer-facing side.
Decide who should hold the DNS before you decide what to call the servers. If the customer keeps their DNS, the next decision is the name they type, which our post on subdomain, www or apex works through. If you host the zone, the customer's mail records are yours to publish too; the sending domain post covers SPF, DKIM and DMARC alignment. The white label domain pillar covers the other inputs.
Frequently asked questions
What are white label nameservers?
They are nameserver hostnames on your own domain, such as ns1.yourbrand.com, used in place of your DNS provider's hostnames. AWS calls them white-label name servers and also uses the terms vanity and private name servers.
Do I need glue records for white label nameservers?
You need them for the domain that owns the nameserver names, because in-domain nameservers cannot be found without glue (SAC125). Your customers' domains point at a name outside themselves, so by our reading they do not need glue of their own. You create the glue at your registrar as host objects with IP addresses.
How many nameservers should I have?
RFC 2182 sets two as the minimum and recommends three for most organisation zones. AWS uses four; we found no source saying four is required.
How long does a nameserver change take?
Up to about two days for old answers to age out. When we queried a .com server on 8 October 2026, the delegation TTL was 172800 seconds (48 hours). Lowering TTLs inside your own zone does not shorten that parent cache.
Can I move an existing zone onto a reusable delegation set?
Not in Route 53. The API reference says a set can be associated only when the zone is created, only within one AWS account, and not with private hosted zones. Existing zones must be recreated.
Will changing nameservers break DNSSEC?
It can, if the zone moves to servers using different keys while the old DS record stays at the parent. The DS holds a key tag, algorithm and digest and exists only at the parent (RFC 4034). RFC 8078 notes that changing DNS operators sometimes means turning DNSSEC off. That the DS ignores NS hostnames is our inference.