Planning nameservers for a multi domain estate

Pick one of three schemes for the whole estate before you delegate the first domain: every domain carries its own nameserver hostnames, groups of domains share a pair, or everything points at the set your provider already runs. The decision is not really about DNS. It sets what an address change costs you in registry work, and which public string every one of your domains ends up stamped with.

The three schemes side by side

The assumption most buyers get backwards

Private nameservers feel like separation, so people buy them for that. Read the middle row again. A pair such as ns1.hubdomain.tld across forty sites is a unique string appearing on all forty and on nothing else in the world, whereas being one of thousands on a provider hostname reveals far less. Per-domain pairs do avoid that string, but only until somebody resolves them: if ns1.siteone.tld and ns1.sitetwo.tld answer from the same address, the pairing survives the effort spent hiding it. Separation lives in the addresses, which is why address diversity is what to buy when the requirement is real. Naming sits on top of that, and none of it is a positive ranking input.

The maintenance bill nobody plans

Estates rarely stay put. A machine gets replaced, an account moves, a range is renumbered. Count the edits for forty domains on a single address change:

• Provider set: zero. The change happens inside infrastructure you do not administer.
• Five pools of eight: ten glue entries plus ten zone records, so twenty edits.
• Private pair per domain: eighty glue entries plus eighty zone records, so a hundred and sixty edits, each one a separate trip through a registrar interface.

Volume is not the real cost. A wrong glue entry does not degrade a site, it removes the domain from resolution entirely, and registry glue is cached on timers the registry sets rather than timers you shorten. Multiply a small error rate by a hundred and sixty manual edits and budget for at least one domain going dark for a day. Schedule it as a maintenance window with a verification pass, alongside the rest of running your estate.

The failure a pool quietly creates

Pooled hostnames live under one hub domain, so that domain becomes load bearing for every site delegating to it. If it lapses, gets locked in a dispute, or sits on a registrar account whose recovery mailbox nobody can still reach, the whole group stops resolving at once and no zone edit saves it. Treat the hub as infrastructure: long registration, registrar lock on, renewal notices going somewhere that outlives one employee, contacts reviewed with the rest of your domain list. The same reasoning argues against putting both members of a pair in one failure domain, which RFC 2182 spelled out decades ago.

The decision rule

1. Default to the provider set. It costs nothing to run and survives renumbering without your involvement.
2. Move to pooled pairs only when the pool boundary matches a grouping you already decided for other reasons. One pool per group, never one per site.
3. Choose per-domain pairs only under an external requirement you can write down: a client contract, a resale arrangement where the host must not be visible, or a compliance line. Preference is not a requirement.
4. Keep the number of distinct pairs low relative to the number of people who can fix them. Two pairs and one administrator is workable. Twelve pairs and one administrator is an outage waiting for a holiday.

Estates rarely suffer from too few nameserver pairs. They suffer from a scheme picked for how it looks, then inherited by a hundred domains whose renumbering nobody costed.