If you resell hosting, run an agency, or just want your nameservers to say ns1.yourdomain.com instead of some generic hosting-provider name, you need what's called a private (or vanity) nameserver. It sounds like a small cosmetic thing, but it's one of the more common support tickets we see — usually because a customer set the DNS records at their registrar but skipped the one step that actually makes them work: glue records. Get this wrong and your domain either won't resolve at all, or it'll go into a resolution loop that looks like nothing is broken until you try to actually load the site.
What a Private Nameserver Actually Is
A "regular" nameserver looks like ns1.skyserver.in — it belongs to your hosting provider's domain, and the provider's registrar already has the glue records set up for it. A private nameserver is the same idea, but hosted under your own domain: ns1.yourbrand.com and ns2.yourbrand.com. You still point to the same underlying WHM/DNS server IPs — you're just relabeling them under your own name for branding, or because you're reselling hosting and don't want your customers' registrars pointing at a competitor's domain.
The catch: to use ns1.yourbrand.com as a nameserver, the DNS system needs to know its IP address before it can look up anything else on yourbrand.com — including the A record that would normally answer that question. That's a chicken-and-egg problem, and glue records are the fix.
Symptom: "My Domain Won't Resolve" or "It Works Sometimes"
The usual complaint looks like one of these:
- The domain returns
SERVFAILor times out entirely from some networks but not others. - WHM shows the nameserver as configured, but
dig NS yourdomain.comfrom an external resolver returns nothing, or returns the nameservers with no matching IP. - Email sent from the domain bounces intermittently — because the receiving server also has to resolve your nameservers to verify SPF/DKIM.
- The site loads for the customer at home (their ISP cached an old record) but not for anyone else.
All of these point to the same root cause: the glue record is either missing, wrong, or was never registered at the parent registrar in the first place.
Cause: Glue Records Live at the Registrar, Not in Your DNS Zone
This is the part people miss. You can add an A record for ns1.yourbrand.com inside your own DNS zone all day long — it won't matter. Glue records aren't part of your zone file at all. They're a special entry stored at the registry level (for .com, that's Verisign; for .in, it's the NIXI registry), tied to the domain's registrar account. They exist specifically so a resolver can find the nameserver's IP without needing to already know how to resolve the domain the nameserver lives under.
So if you registered yourbrand.com with one registrar but your hosting is with SkyServer, you have to go into that registrar's control panel — not WHM, not cPanel — and add the glue record (sometimes called "child nameserver," "host record," or "register nameserver" depending on the registrar's UI wording).
Fix: Set It Up in the Right Order
Do these steps in this exact order. Doing them out of order is the single most common reason this breaks.
| Step | Where | What to do |
|---|---|---|
| 1 | WHM > Basic WebHost Manager Setup | Set the hostname and add the nameserver entries (e.g. ns1.yourbrand.com / ns2.yourbrand.com) with the server's public IP addresses. |
| 2 | WHM > Nameserver IPs | Confirm both nameserver names resolve to real, reachable IPs — usually your main server IP and a secondary IP if you have one. |
| 3 | Your domain registrar (for yourbrand.com itself) | Add a "Register Nameserver" / "Child Nameserver" / "Host Record" for ns1 and ns2, pointing to the same IPs as step 2. This creates the glue record at the registry. |
| 4 | WHM > Edit DNS Zone (for yourbrand.com) | Make sure the zone itself also has A records for ns1 and ns2 matching the same IPs — belt and suspenders, since some resolvers check both. |
| 5 | At each customer's registrar | Set their domain's nameservers to ns1.yourbrand.com and ns2.yourbrand.com. |
Step 3 is the one people skip because it's not obvious it exists — it's usually buried under a menu called "Nameserver Management" or "Host Records," separate from the normal DNS/A-record settings for the domain.
Once glue is registered, verify it directly against the registry, not just your own resolver:
dig NS yourbrand.com
dig A ns1.yourbrand.com
whois yourbrand.com | grep -i "name server"
If whois shows your nameservers but dig A ns1.yourbrand.com comes back empty from an external DNS checker (try a few from different regions), the glue record hasn't propagated or wasn't saved correctly at the registrar.
A Common Trap: Using the Domain's Own Nameservers to Resolve Itself
If yourbrand.com's nameservers are ns1.yourbrand.com and ns2.yourbrand.com — i.e., the domain is using itself as its own nameserver — you must have glue records. There's no way around it; a resolver literally cannot ask ns1.yourbrand.com where ns1.yourbrand.com is without already knowing. This is different from a customer domain pointing to your private nameservers, where the customer's domain doesn't need glue (only yourbrand.com does, since that's where the nameservers actually live).
Prevention: Check These Before You Advertise Private Nameservers
- Propagation takes longer for glue changes than regular DNS. Registry-level glue can take anywhere from a few hours to 24-48 hours depending on the TLD and registrar. Don't panic if it's not instant.
- Keep both nameserver IPs stable. If you ever migrate the server behind
ns1.yourbrand.com, you have to update the glue record at the registrar too, not just WHM — otherwise every domain using your private nameservers goes dark. - Always run two nameservers on separate IPs (ideally separate networks). If both glue records point to IPs on the same subnet or the same physical host, one outage takes down DNS resolution for every domain relying on them.
- Register glue with the same registrar as the parent domain. If
yourbrand.comis with Registrar A, you generally can't add glue for it through Registrar B — the glue has to be added at the registry account tied to that specific domain. - Test from outside your own network. Your local ISP or office router may cache stale answers. Use an external tool or ask someone on a different connection to run
digbefore declaring it fixed.
Private nameservers are worth the extra setup step if you're reselling hosting or want a cleaner brand story for customers — just remember the glue record lives with the registrar, not with WHM, and skipping it is what turns a five-minute task into a multi-day resolution headache.
Frequently Asked Questions
Do I need glue records if I'm just using SkyServer's nameservers directly?
No. Glue records are only needed when your nameserver's hostname is a subdomain of the same domain it's serving DNS for (like ns1.yourbrand.com resolving yourbrand.com). If you use SkyServer's own nameservers (e.g. ns1.skyserver.in), the glue already exists on our end — you just point your domain to them.
Can I use private nameservers under a domain that isn't hosted with SkyServer?
Technically yes, as long as you control DNS for that domain and can add A records matching the server IPs. But it's cleaner to use a domain that lives on the same account, so you're not juggling glue records across two different providers.
Why does WHOIS show my nameservers correctly but the site still won't load?
WHOIS reflects what's registered at the registry — that part can be correct while the actual DNS zone or the glue A record is still wrong or unpropagated. Check dig NS and dig A separately; WHOIS alone doesn't prove resolution works.
How many private nameservers should I set up?
At least two, on different IP addresses. A single nameserver is a single point of failure — if it goes down or becomes unreachable, every domain using it stops resolving.
I changed my server's IP address. What do I need to update?
Three places: the A record in WHM's DNS zone for the nameserver hostname, the "Nameserver IPs" setting in WHM itself, and — the one people forget — the glue record at the registrar where the parent domain is registered. Missing that last one is the most common cause of "it worked yesterday" tickets after a server migration.
