White Label DNS: What It Means, and What Still Leaks
White label DNS means one of three different things: vanity nameservers like ns1.yourbrand.com that front somebody else's anycast network, reselling a DNS filtering product under your own name, or serving customer domains over a CNAME so your vendor never appears in the URL. They solve different problems, and only one of them is what most SaaS platforms actually want.
I spent 2 September 2026 measuring live white-label DNS setups at hosting companies that sell the thing, because the marketing pages all describe the same product and the wire tells a different story. Three of the four surfaces a curious customer can inspect leak the provider underneath, and the fix for two of them costs something nobody mentions.
Three products, one name
| What it means | Who sells it | What the customer changes | What it hides |
|---|---|---|---|
| Vanity nameservers | ClouDNS, Route 53, hosting resellers | Their whole zone delegation, at the registrar | The DNS provider's brand, partly |
| White-label DNS filtering | TitanHQ, Comodo, MSP tooling | Their resolver settings | The filtering vendor's brand |
| CNAME-based custom domains | Custom domain APIs, SaaS platforms | One record in their own zone | The platform's brand at the URL, cert and headers |
The first two are DNS businesses. The third is a product feature. If you are a SaaS platform reading up on white label DNS because customers want their own domain on your app, the third row is your row, and most of what has been written about the term is about the first.
How vanity nameservers actually work
A vanity nameserver is a name you own that points at DNS infrastructure you probably don't. You register a host record at the registrar of your own domain, mapping ns1.yourbrand.com to an IP address. The registry then publishes that mapping as a glue record in the TLD zone, so a resolver that has never heard of your domain can still find its nameservers without a circular lookup.
Ask the .com servers directly and the glue is right there in the additional section:
dig +norecurse @a.gtld-servers.net siteground.com NS
;; AUTHORITY SECTION:
siteground.com. 172800 IN NS ns1.siteground.com.
siteground.com. 172800 IN NS ns2.siteground.com.
siteground.com. 172800 IN NS ns3.siteground.com.
siteground.com. 172800 IN NS ns4.siteground.com.
;; ADDITIONAL SECTION:
ns1.siteground.com. 172800 IN A 216.239.32.106
ns2.siteground.com. 172800 IN A 216.239.34.106
ns3.siteground.com. 172800 IN A 216.239.36.106
ns4.siteground.com. 172800 IN A 216.239.38.106
Four branded NS records, four glue addresses. The white label is working exactly as advertised at this layer. Then you look up who owns those addresses.
Three of four surfaces leak
216.239.32.0/19 is registered to Google LLC. Run the reverse lookups and the label comes off completely:
| Vanity name | Glue IP | PTR record says |
|---|---|---|
ns1.siteground.com | 216.239.32.106 | ns-cloud-a1.googledomains.com |
ns2.siteground.com | 216.239.34.106 | ns-cloud-a2.googledomains.com |
ns3.siteground.com | 216.239.36.106 | ns-cloud-a3.googledomains.com |
ns4.siteground.com | 216.239.38.106 | ns-cloud-a4.googledomains.com |
All four map cleanly onto Google Cloud DNS nodes a1 through a4. SiteGround's nameservers are Google Cloud DNS with a nameplate on the front, which is a perfectly reasonable engineering decision and not a secret, but it is one dig -x away from anybody who wonders.
The SOA record gives it away faster, because you do not even need the reverse lookup:
dig +short SOA siteground.com
ns-cloud-a1.googledomains.com. sysadmin.siteground.com. 2012102024 60 60 360 360
The MNAME field of a zone's SOA names the primary nameserver, and here it names Google's, on the domain of a company selling white-labeled hosting. So of the four surfaces worth checking, the NS records hide the provider and the glue IP, the PTR and the SOA both give it up.
None of this is a security problem. It matters because the whole point of a vanity nameserver is that your customer sees your brand. And the customers most likely to run dig are exactly the enterprise buyers you bought the white label for.
The clean version, and what it still shows
DreamHost is the counterexample. Same trick, tidier execution:
dig +short SOA dreamhost.com
ns1.dreamhost.com. hostmaster.dreamhost.com. 2026090200 1457 1800 1209600 300
dig +short -x 162.159.26.14
ns1.dreamhost.com.
SOA clean, PTR clean. But 162.158.0.0/15 is CLOUDFLARENET, registered to Cloudflare, and asking the server for its own identity confirms it:
dig +short @ns1.dreamhost.com CH TXT id.server
"tlv04"
A three-letter airport-style node identifier is Cloudflare's anycast fleet answering. So a careful white label can fix the PTR and the SOA, and it cannot fix the routing table. The provider is always discoverable from the network layer if somebody cares enough to run whois on an IP.
Worth stating plainly, because both examples are hosting companies rather than SaaS platforms: neither is doing anything wrong. They are running anycast DNS they did not build, which is the right call. The point is that white labeling DNS is a partial disguise, and it is useful to know which parts.
The vanity name loses IPv6
This one is a real operational cost and I have not seen it written up. Google's actual nameserver has an AAAA record. The vanity name in front of it does not:
dig +short AAAA ns-cloud-a1.googledomains.com
2001:4860:4802:32::6a
dig +short AAAA ns1.siteground.com
(no answer)
dig +short AAAA ns1.dreamhost.com
(no answer)
dig +short AAAA cody.ns.cloudflare.com
2606:4700:58::adf5:3b6b
Both underlying networks publish IPv6 nameserver addresses. Both white-labeled fronts publish IPv4 only. The branding step dropped a capability the infrastructure already had, because adding IPv6 glue means registering a second host record per nameserver at the registrar, and it is easy to skip.
The effect is small but not zero. An IPv6-only resolver has to reach your zone through a translation layer instead of natively, and DNSSEC-validating resolvers on IPv6-only networks are the ones most likely to notice. It costs nothing to get right at setup and is annoying to retrofit.
One delegation hands over the whole zone
Here is the part that decides the question for SaaS platforms. Nameserver delegation is not per record type. If a customer points their NS records at you, you are serving their entire zone, and that includes everything their business depends on that has nothing to do with your product:
dig +norecurse @ns1.siteground.com siteground.com MX
10 mx10.antispam.mailspamprotection.com.
20 mx20.antispam.mailspamprotection.com.
30 mx30.antispam.mailspamprotection.com.
dig +norecurse @ns1.siteground.com siteground.com TXT
"_globalsign-domain-verification=u53IVPzwq3sVZGZmcS7n7V4uRo4O266M55PygUGxcf"
"google-site-verification=eq5Y2zXODoC3uls0LpprPQfdZvRrkvG2q_InXwDAtVE"
"google-site-verification=BjuYkX1OJlxPZBk4oEAJUdpanbPtTF6qQaaGAhtWIVA"
One delegation, and the same servers are now authoritative for the customer's MX records, their SPF policy, their DKIM keys and every domain-verification token they hold with third parties. If your control plane drops a record during a migration, you did not break their custom domain. You broke their email, and their Google Workspace verification, and their certificate issuance.
That is a DNS hosting business with a DNS hosting business's incident surface. Taking it on to put your name on four hostnames is a bad trade unless DNS hosting is the product you are selling.
There is a second cost with a number on it. The glue in the TLD zone carries a 172800 second TTL, two days, set by the registry rather than by you. Well-behaved resolvers refresh nameserver addresses from the zone itself, where SiteGround publishes a 300 second TTL, so the median case is fine. The tail is not: a cold resolver bootstraps from glue, and if you need to move a vanity nameserver's IP address you are committed to a window measured in days that you cannot shorten. Compare that to a vendor-controlled CNAME target, where the vendor sets the TTL and can rotate an address in a minute.
The CNAME model, and the leak it has instead
The alternative is to take one label instead of the whole zone. The customer adds a single CNAME record in DNS they continue to control, pointing one hostname at your edge, and everything else in their zone is untouched. This is what nearly every SaaS platform doing custom domains actually runs.
You can see it on live products. status.figma.com is a CNAME to rxpksf93ynw6.stspg-customer.com while figma.com itself stays delegated to Route 53 nameservers. status.openai.com is a CNAME to cname.vercel-dns.com while openai.com stays on Azure DNS. In both cases the platform got the one hostname it needed and the customer kept authority over their own zone, their mail and their verification records.
But look at what those CNAME targets say. stspg-customer.com is Statuspage. vercel-dns.com is Vercel. The CNAME model does not eliminate the leak, it relocates it: from the SOA and the PTR, which almost nobody looks at, to the customer's DNS panel, which the one person doing the setup looks at exactly once.
That is the honest comparison. Vanity nameservers hide your vendor from a curious end user and expose it to dig. A CNAME hides your vendor from dig and shows it to the administrator during setup. Neither hides it from someone determined.
There is a third option that beats both, and it is worth knowing it exists: a vendor CNAME alias on your own domain. If your platform serves edge.yoursaas.com as an alias for the vendor edge, the customer's DNS panel shows your brand, the certificate names the customer's domain, and no lookup at any layer names the vendor. It requires the vendor to support it, and it is usually a paid tier.
Which one you need
| If you are | You want | Because |
|---|---|---|
| A hosting company or agency reselling DNS | Vanity nameservers | DNS hosting is the product, so the zone is yours by design |
| An MSP selling network security | White-label DNS filtering | It is a resolver product, not an authoritative one |
| A SaaS platform giving customers their own domain | CNAME-based custom domains | You need one hostname, not a DNS business |
A SaaS platform whose customers need customer.com | Custom domains with apex support | A CNAME cannot live at a zone apex |
That last row is the one that trips people up. A CNAME cannot exist at the apex of a zone, because RFC 1034 forbids other data at a name holding a CNAME and the apex is required to carry SOA and NS records. It is a structural rule, not a provider limitation, which is why every platform that supports apex domains solves it with an address record and some form of flattening rather than by allowing the CNAME.
One more thing to check before you delegate anything: whatever model you pick, records that outlive the service behind them become dangling DNS and open the door to subdomain takeover. The vanity nameserver version of this is worse than the CNAME version, because a stale delegation hands over an entire zone rather than one hostname.
Where Domainee fits
Domainee is a custom domains API for SaaS with a native MCP server, 50 domains and 100 GB free. I build it, so weigh this section accordingly.
Domainee is the third row of that table and not the first. It does not run authoritative DNS and does not sell vanity nameservers, which is a deliberate limitation rather than a roadmap gap: taking NS delegation for your customers means owning their mail routing, and that is a different company. What it does is take one hostname, issue and renew the certificate, and serve it from a latency-routed edge, including at the apex.
On the leak question, the white label page has the full surface-by-surface audit, and it is honest about the one row that is visible: the default CNAME target is edge.domainee.dev, so the administrator doing the one-time setup sees the name. CNAME aliasing on the Enterprise tier moves that to your own domain. Nothing else, not the URL, not the certificate subject, not the response headers, names us.
If you are working out which model your product needs, the custom domains as a service entry covers the category, the customdomain.ai breakdown covers what it costs to have a vendor write those records for you over OAuth, best custom domain APIs compares what is available, and the white-label SaaS use case has the shape of the integration. For the certificate side, how SSL works for custom domains walks through issuance and renewal. If you also want customers buying domains inside your product under your brand, that is a registrar API question rather than a DNS one.
FAQ
What is white label DNS?
White label DNS most commonly means vanity nameservers: DNS servers presented under your own domain, like ns1.yourbrand.com, that actually run on a provider's infrastructure. The term is also used for reselling DNS filtering products under your own brand, and loosely for serving customer domains over a CNAME so your vendor never appears in the URL. They are three different products.
Are vanity nameservers really white label?
Partly. The NS records and the glue addresses show your brand, but the PTR record and the SOA record frequently name the underlying provider. We measured this on 2 September 2026: all four of ns1 through ns4.siteground.com reverse-resolve to ns-cloud-a1 through a4.googledomains.com, and the SOA for siteground.com names Google's nameserver directly. A careful setup can fix both, but the IP address still belongs to the provider's netblock.
Should my SaaS take NS delegation from customers?
Almost certainly not. Nameserver delegation is not per record type, so accepting it makes you authoritative for the customer's mail routing, SPF and DKIM records and every third-party verification token in their zone. A single CNAME gets you the one hostname you need and leaves the rest of their zone with them.
What is the difference between white label DNS and a custom domain?
White label DNS is about who appears to be hosting the zone. A custom domain is about whose brand is in the URL. A SaaS platform can give every customer a fully branded custom domain, with a certificate naming the customer's domain, without hosting any DNS at all.
Do I need vanity nameservers to support apex domains?
No. Apex support is a question of serving address records rather than a CNAME at the zone root, and platforms solve it with anycast addresses or CNAME flattening. Running your own branded nameservers is neither necessary nor sufficient for it.
How can I tell which DNS provider is really behind a set of nameservers?
Four checks, weakest to strongest. Run dig +short SOA domain.com and read the first field. Reverse-resolve the nameserver addresses with dig -x. Run whois on one of those addresses and read the netname. Ask the server for id.server in the CHAOS class. The last two are difficult to disguise, because they describe the network rather than the records.