Vanity Nameservers (White-Label DNS) in 2026

When you buy a domain name, your registrar will typically offer to provide you with a collection of DNS nameservers. For most people, most of the time, that’s plenty sufficient.

A trip back to 2006

Terminal in which 'dig danq.dev @`dig NS dev +short | head -n1`' has been run, outputting NS responses representing three Gandi nameservers. — My secondary domain `danq.dev` has three nameservers, operated by its registrar Gandi.

This wasn’t always the case. In the long-distant past, I’ve registered domains for which I’ve had to run my own nameservers. Or else, where I’ve chosen to run my own nameservers in order to gain more control, or power, or just to ~~play about with the technology~~ inevitably break things.

When I transitioned to using third-party DNS around 2006, I used to be a big fan of vanity nameservers. “Vanity nameservers” (or “white-label DNS”) is where your nameservers are hosted at subdomains of the domain for which they’re the nameserver.

So instead of the nameservers for danq.me being, say, looking like ns-48-a.gandi.net and ns-228-b.gandi.net, they might look like, say, ns1.danq.me and ns2.danq.me. They might still be provided by the same third-party (or might not!), but you don’t get to see that. DNS protocol doesn’t care about the hostname it’s connecting to, it just needs the right A/AAAA records and it’s good to go!

Well, once you solve the bootstrapping problem, anyway!

If the nameservers for a domain are at a subdomain of that domain, you’ve got a circular dependency. To solve that, you have the servers one level higher provide “glue records” in addition to the list of nameservers. The glue records, which are shown in the “additional section:” of dig‘s output, above, solve the circular dependency. Now, the nameservers can be found without first having to… find the nameservers!

Terminal in which 'dig danq.me @`dig NS me +short | head -n1`' has been run, outputting NS responses ns1.danq.me through ns4.danq.me, with additional section records for A and AAAA records for each. — Tada! For the first time in about 20 years I’ve configured “vanity DNS”: `danq.me`‘s nameservers are now called `ns1.danq.me`, `ns2.danq.me`, `ns3.danq.me` and `ns4.danq.me`.

Vanity nameservers in 2026

The essential steps for setting up vanity nameservers are fundamentally the same as they always were. Propagation times are much shorter now and I was able to have the whole thing done and dusted within a couple of hours. In case you’re looking to follow-along, here’s the broad steps (the specifics depends on your registrar, DNS provider, etc.):

Set up A (and AAAA, it’s 2026 you know!) records pointing ns1.example.com (or whatever your domain is) to their IP addresses.¹
Change the NS records for your domain to point to your new vanity nameservers.
Change the SOA record for your domain to point to the first vanity nameserver². Bump your serial.
Have your registrar create glue records mirroring those you created in step 1.
Have your registrar change the authoritative nameservers for your domain to those you created in step 1.
(Optional) 😰 Frantically and repeatedly poke the registry’s DNS servers with dig until you’re confident that you didn’t just make a hideous typo and broke your domain in a way that would have been a pain in the arse to unpick when you last did this, in 2006. Calm down when you remember that it’s 2026 and nowadays it’s gonna be easy to fix via some API or web portal of your registrar!

That’s all there is to it.

But… why would anybody do this?

For most folks, this is pointless. Larger companies, especially in tech fields, sometimes do it as a branding exercise, especially if they’re re-selling services atop somebody else’s infrastructure and don’t want to so-clearly lampshade that³. But I took a look and… I don’t think people bother any more.

Hit up a handful of corporate domains you know and, with the exception of the few that run their own DNS, you’ll see the same big providers keep cropping up: Cloudflare, Amazon, Google, Microsoft… I experimentally probed a hundred or so domains that I thought might use “vanity DNS” in front of a third-party DNS service… and found… none⁴.

Nobody cares any more. You’re either running your own, or you tell the world who’s running it for you, with no in-between.

Bringing back an old tradition

Vanity DNS is a dying art.

Soo… I’m now doing vanity DNS on danq.me; it’s the first time I’ve run vanity DNS on a personal domain since… I want to say 2010‽ The journey started when Jacob asked me about my DNS setup, and it made me nostalgic for a time when nerdy techies whose nameservers were provided by a third party would just “do” vanity DNS as a matter of course.

Vanity DNS felt nerdy and fun back in 2006. And I guess that nowadays… it still feels nerdy and fun. It’s still as pointless as it ever was, but I don’t care. I’m doing something that I thought was cool when I first learned about it in 2001, just for the fun of it.

Type dig NS danq.me in your terminal to see the result: four nameservers, all with a .danq.me suffix⁵. Cute!

Footnotes

¹ There’s a convention of naming nameservers ns1, ns2, ns3 etc., but if you want “fun” names then that’s fine too. Cloudflare’s nameservers have cute names, if you haven’t seen already!

² Check your dotted-notation hostmaster email while you’re there; everybody forgets to look at these and so they’re often outdated.

³ Using vanity nameservers to conceal an underlying DNS provider does not conceal the third-party’s identity because you can always use the IP address of those nameservers to work out who’s behind them. For example, if you’re interested in seeing who’s really providing the DNS for danq.me, you might run NS_NAME=`dig NS danq.me +short | head -n1` to get the name of a random one of my nameservers, then NS_IP=`dig ${NS_NAME} +short | head -n1` to get its IP address, and finally do an reverse DNS lookup on that with e.g. dig -x $NS_IP. Often, this canonical name will be a giveaway and you won’t even have to look at the lists of who owns which blocks of IP addresses. It’s not a secret. (Gotta admit, though I’m not entirely happy with my provider… maybe it’s time to switch… or even go back to selfhosting DNS once more!)

⁴ whatsapp.com appears to have its own nameservers a.ns.whatsapp.com through d.ns.whatsapp.com, but their A records point to IP addresses whose reverse DNS names are a.ns.facebook.com through d.ns.facebook.com. Not terribly exciting, nor surprising, that Meta are running their own DNS services for their various properties (the same thing happens with instagram.com). paypal.com seems to have both its own DNS servers and some replicas provided by Digicert UltraDNS, which for a moment excited me when I thought that they might be part-way through a white-labelling exercise, but no: they’re two different services. I thought I’d find something interesting via one of the big blog, eccomerce, or VPS providers that offer free subdomains: folks like Bearblog, Dreamwidth, Substack or Medium. But nope; some seem to run their own DNS, and others just sit on top of a big third-party. Sigh.

⁵ Want to see the glue records? Run dig NS me +short to get the names of the authoritative nameservers for the .me TLD, e.g. a0.nic.me, and then query it directly with e.g. dig NS danq.me @a0.nic.me: you’ll see not just that I have four nameservers under .danq.me but also their IP addresses (in the “additional section”) – that’s the glue doing its thing!