When a client looks up who hosts their domain, the first thing they see is the nameservers. If those read ns1.somebigplatform.com, your brand ends there. Private nameservers put ns1.yourbrand.com and ns2.yourbrand.com in that position instead. The DNS service itself does not change. What changes is the name, and making a name work as a nameserver takes three pieces that must agree. This post covers each piece and how to check it with dig.
What a private nameserver actually is
A nameserver name is only a hostname with an A record. ns1.yourbrand.com pointing at 203.0.113.10 is a private nameserver the moment a DNS server at that address answers for your clients' zones. You are giving an existing DNS server a second name that belongs to you.
The complication is a circular lookup. To find client-site.com, a resolver is told to ask ns1.yourbrand.com. To find ns1.yourbrand.com, it must ask the nameservers of yourbrand.com, which are ns1.yourbrand.com. The loop is broken by glue records: the registry for .com stores the IP addresses of your nameserver names and hands them out together with the referral. How DNS works covers the root, TLD and authoritative steps this post assumes.
The three pieces
| Piece | Where it lives | Who sets it |
|---|---|---|
| Glue (nameserver host registration) | At the registrar of yourbrand.com, stored by the registry |
You |
A records for ns1 and ns2 |
In the yourbrand.com zone |
You, in DirectAdmin |
| NS records in every client zone | On the hosting server | DirectAdmin, from the reseller setting |
All three must show the same names and the same IPs. Most broken setups have two of the three.
What a reseller can and cannot do
On reseller hosting you do not run the DNS server; your host does, and your zones live on it. That decides what is in your hands:
- You can choose the names, register the glue, create the A records and set the names as the default for all your users.
- You cannot pick the IP addresses. They have to be addresses where your host's DNS service answers for your zones. Ask the host which two IPs to use. Do not guess from the address your website resolves to.
- You cannot make the two nameservers more independent than the host has built them. Two names on one machine is still one point of failure.
Registries expect at least two nameservers, and some registrars refuse two hosts with the same IP. Two different addresses from the host avoids that argument. Private nameservers are part of our reseller plans; ask by ticket which addresses to use before you register anything.
Tip: the domain you use for nameservers should be one you intend to keep for years. Every client domain will depend on it. If yourbrand.com expires, every site you host goes dark with it, so put it on auto-renew with a card that does not expire soon.
Step 1: register the nameserver hosts at the registrar
This is done where yourbrand.com is registered, not in DirectAdmin. Registrars call the feature "register nameservers", "host records", "child nameservers" or "glue records". The form is always a hostname and an IP.
ns1.yourbrand.com 203.0.113.10
ns2.yourbrand.com 203.0.113.11Add IPv6 glue as well only if your host gives you IPv6 addresses for the nameservers. Some registrars only do this by ticket, so check before you choose where to register the domain.
Step 2: add the A records in your own zone
Glue gets resolvers to your nameserver. The zone itself must then say the same thing. In DirectAdmin, log in to the account that holds yourbrand.com, open DNS Management and add:
ns1 3600 IN A 203.0.113.10
ns2 3600 IN A 203.0.113.11While you are there, change the two NS records of yourbrand.com itself to the new names, so the zone and the registry agree:
yourbrand.com. 3600 IN NS ns1.yourbrand.com.
yourbrand.com. 3600 IN NS ns2.yourbrand.com.The trailing dots matter in a zone file. Without one, the name is treated as relative and you get ns1.yourbrand.com.yourbrand.com. The record types are explained in DNS record types.
Step 3: set the names at Reseller Level
Now tell DirectAdmin to use the names for your users. At Reseller Level open the Name Servers page and set ns1.yourbrand.com and ns2.yourbrand.com as your nameservers. From then on, every new user you create gets a zone whose NS records are your names.
Two things this setting does not do:
- It does not rewrite existing zones. Users created earlier keep the old NS records. Edit those zones in DNS Management, one domain at a time, or ask your host to correct them in bulk.
- It does not update the client's registrar. Each client domain must be pointed at
ns1.yourbrand.comandns2.yourbrand.comwhere it is registered.
If you sell through WHMCS, put the same two names in the nameserver fields of the server entry so welcome emails quote them, as described in automating account setup with WHMCS and DirectAdmin.
Step 4: point your own domain at them
At the registrar, set the nameservers of yourbrand.com itself to ns1.yourbrand.com and ns2.yourbrand.com. Do this last, after the glue and the A records exist, or the domain will be unresolvable for a while.
Verify with dig
Check each piece separately, in this order.
The glue. Ask a registry server directly. For .com:
dig NS yourbrand.com @a.gtld-servers.net +norecurseThe AUTHORITY section should list your two names and the ADDITIONAL section should list their IPs. No ADDITIONAL section means the glue is missing. For .co.uk use @nsa.nic.uk.
That each nameserver answers for a client zone:
dig SOA client-site.com @ns1.yourbrand.com +norecurse
dig SOA client-site.com @ns2.yourbrand.com +norecurseLook at the flags line in the header. It must contain aa (authoritative answer). A REFUSED status, or an answer without aa, means that IP does not serve the zone and you were given, or guessed, the wrong address.
The whole chain as a resolver walks it:
dig +trace client-site.comThe last hop should be answered by one of your nameserver names.
What a public resolver sees:
dig NS client-site.com @1.1.1.1 +shortTip: compare the SOA serial on both nameservers with dig SOA client-site.com @ns1.yourbrand.com +short and the same for ns2. Different serials mean the two are not serving the same copy of the zone, and clients will see changes "sometimes".
Propagation and TTL
There is no global propagation. There are caches, and each one holds a record for the TTL it was served with. A delegation change at the registry is cached for the TLD's own TTL, which you cannot shorten; for .com that is two days. Records inside your zone are cached for the TTL you set.
So when moving existing clients to the new names, keep the old names working until the caches have expired. If both sets point at the same servers, the usual reseller case, nothing breaks during the overlap.
Tip: dig +trace bypasses caches and shows the truth at the source. If +trace is right and your browser is wrong, you are waiting on a cache, not fixing a fault.
Common mistakes
- A records without glue. Works for people whose resolver has it cached, fails for everyone else. The registry test above catches it.
- Glue without A records. The registry gives an address and the zone disagrees or has nothing.
- Glue left on an old IP after a server move. Glue does not follow your zone. When the host changes the nameserver IPs, update the registrar hosts the same day.
- A typo in one of fifty zones.
ns1.yourbrand.coinstead of.comresolves for nobody. Checkdig NSafter creating each account until you trust the default.
Once the dig checks pass, the setup needs no attention until an IP changes. Private nameservers are one part of a white-label setup; how reseller hosting works covers what else your clients will and will not see.