Every agency that hosts client websites reaches the same point eventually. A client logs into their registrar, sees ns1.somehostingcompany.co.uk in the nameserver field, and now knows exactly who actually runs their hosting.
White-label — or vanity — nameservers fix that. Instead of pointing client domains at your provider’s nameservers, you point them at ns1.youragency.com and ns2.youragency.com, which resolve to the same infrastructure. The client sees your brand at every layer.
The commercial argument is obvious. The technical argument is more interesting, and so are the ways it can go wrong.
What a nameserver record actually is
A domain’s nameservers are set by NS records held at the registry for the top-level domain, not in your own zone. When a resolver looks up clientsite.co.uk, it asks the .uk registry’s servers who is authoritative, and gets back a list of hostnames.
Hostnames, note — not addresses. So the resolver now has to look up ns1.youragency.com to find out where to send its actual query. That is a second lookup, in a different zone, and it works fine.
The complication arrives when the nameserver’s hostname sits inside the very zone it serves. If youragency.com is delegated to ns1.youragency.com, then to resolve ns1.youragency.com a resolver must ask the nameservers for youragency.com, which are… ns1.youragency.com. That is a circular dependency, and it is what glue records exist to break.
Glue records
A glue record is an A (or AAAA) record stored at the registry, alongside the delegation, giving the address of a nameserver directly. It short-circuits the loop: the registry’s response to "who serves youragency.com?" includes both the NS hostnames and their addresses, so no second lookup is needed.
Registrars call this different things — "register a nameserver", "host records", "child nameservers", "private nameservers", "glue records". They all mean the same operation, and it happens at the registrar for the domain that contains the nameserver name, not at the registrar for each client domain.
So the sequence for an agency setting this up is:
- At the registrar for
youragency.com, register the hostns1.youragency.comwith the IP address of your provider’s first nameserver, andns2.youragency.comwith the second. - In the
youragency.comzone itself, publish matching A records forns1andns2. These should agree with the glue exactly. - For each client domain, set the nameservers to
ns1.youragency.comandns2.youragency.com. - Make sure your provider’s DNS platform is configured to answer authoritatively for each client zone, and to return your nameserver names in its own NS records.
Step four is the one that gets missed, and it produces a specific, confusing symptom described below.
The lame delegation problem
A delegation is "lame" when the registry says a nameserver is authoritative for a zone and that nameserver does not agree.
In a white-label setup this happens when you point a client domain at ns1.youragency.com before the underlying platform has been told about that zone. Resolvers arrive, ask for records, and get a REFUSED or an unauthoritative response. Some will retry the second nameserver; some will treat the answer as definitive; behaviour varies by resolver, which is why the failure often looks intermittent.
Always create the zone on the platform first, verify it answers, and only then change the delegation:
dig +norecurse @ns1.youragency.com clientsite.co.uk SOA
The aa flag should be present in the response header. If it is not, the nameserver is not authoritative for that zone and the delegation is not safe to make yet.
The in-zone NS records must match
There is a second, subtler consistency requirement. Every zone contains its own NS records, and those should list the same nameservers as the delegation at the registry.
clientsite.co.uk. IN NS ns1.youragency.com.
clientsite.co.uk. IN NS ns2.youragency.com.
If the registry says ns1.youragency.com but the zone itself still says ns1.somehostingcompany.co.uk, most resolvers will work anyway — but you have a discrepancy that will show up in every DNS audit tool, may cause problems with DNSSEC validation, and makes debugging harder for whoever inherits the setup.
Any competent hosting platform lets you set the default NS records used for new zones. Set it once, at the point you introduce white-label nameservers, and check that existing zones were updated too rather than assuming they were.
Two nameservers is the minimum, and they should differ
Registries generally require at least two nameservers, and there is a real reason beyond box-ticking.
RFC 2182 makes the point plainly: secondary nameservers should be topologically and geographically separated from the primary. Two nameservers in the same rack, on the same switch, behind the same upstream, provide redundancy against a process crashing and against nothing else. The failure modes that actually take out DNS — a network outage, a routing problem, a DDoS against a subnet — take out both simultaneously.
When you set up vanity nameservers, you inherit whatever diversity your provider has. It is worth asking the question explicitly: are ns1 and ns2 on separate networks, ideally in separate facilities and separate autonomous systems? If the answer is no, the vanity names are cosmetic and your clients’ DNS has a single point of failure regardless of how it is labelled.
Anycast, where the same address is announced from multiple locations, is the stronger answer and increasingly the norm for serious DNS hosting.
What changing nameservers costs
Two things, both worth planning around.
It is slow. The delegation TTL is set by the registry, not by you, and is typically measured in days rather than hours. Unlike an A record change, you cannot shorten it in advance. Budget 48 hours before you consider the change complete.
It is all-or-nothing per domain. There is no partial state; a domain uses one set of nameservers or the other. This makes the ordering non-negotiable: zone created and verified on the platform, records confirmed identical to the current live values, then delegation changed.
The safe migration for an existing client domain is to replicate the zone byte-for-byte onto the new platform first, confirm every record answers identically, and only then move the delegation. Editing records at the same time as moving nameservers is how you end up unable to tell which change broke things.
Verifying the whole chain
Three checks, in order.
Does the registry hand out your nameservers, with glue?
dig +trace clientsite.co.uk
Read the delegation step in the output. You want your nameserver names, and — for the zone containing them — their addresses returned as additional data.
Do both nameservers answer authoritatively and identically?
dig +norecurse @ns1.youragency.com clientsite.co.uk SOA
dig +norecurse @ns2.youragency.com clientsite.co.uk SOA
The serial numbers should match. A persistent mismatch means zone transfer between your provider’s nameservers is failing, which is a real fault however well it hides.
Does the glue agree with the zone?
dig +short A ns1.youragency.com
Compare against what the registry returns in dig +trace. A mismatch here — usually left over from a server move where the glue was updated and the in-zone A record was not, or vice versa — produces resolution that works for some resolvers and not others.
When not to bother
White-label nameservers are worth it if you hold the client relationship, bill for hosting, and want the infrastructure to be invisible. They are not worth it if your clients manage their own DNS, or if you are passing through to a provider you may leave within the year — because unwinding them means touching the delegation on every client domain again.
And they are actively a bad idea if you set them up on a platform whose two nameservers share a network, and then tell clients you run your own DNS. The name on the record does not change what happens when that network goes down.
FXRM’s reseller platform supports white-label nameservers, custom branding and API-driven provisioning as standard, on UK infrastructure. See reseller hosting →
