Nameservers in WHOIS Lookups
whois nameservers · check domain nameservers · ns delegation whois
How to read nameserver fields in WHOIS, match them to DNS NS records, fix delegation after migrations, and avoid split-brain DNS.
By DN01 Network Team
Registrar WHOIS nameserver fields show what the registry publishes at the TLD parent — they must match NS inside the zone and what recursive resolvers cache. Mismatch is the root cause of many «DNS works in panel» tickets.
Use WHOIS for registry view, DNS Checker for live answers, and DIG NS for resolver-specific traces.
Never assume the DNS panel you edited is authoritative until WHOIS nameservers list that provider — registrar glue is the parent view the world uses first.
Registrar NS vs zone NS
Update registrar glue when changing DNS provider — panel at new host alone is insufficient.
Minimum two distinct NS hostnames on different networks recommended.
Glue records required for in-bailiwick NS names (ns1.example.com for example.com).
WHOIS lists parent delegation; the zone file at your DNS host lists NS too — both must agree after migrations.
After migration checklist
Lower TTL before cutover, change registrar NS, wait propagation, populate records at new provider.
WHOIS NS updated + DNS Checker shows same NS + spot-check MX/A/TXT.
Keep old provider read-only until TTL expires globally.
Screenshot WHOIS NS immediately after registrar save — some panels delay registry publish by minutes.
Split-brain symptoms
Mail delivers but web fails (or vice versa) when MX and A records live on different NS sets — WHOIS shows one provider while stale cache serves another.
Compare WHOIS NS, DIG type NS from two resolvers, and DNS Checker NS section — all three should converge within the propagation window.
Child zones delegated via NS records on the parent need WHOIS on the child only after parent delegation publishes.
Common WHOIS NS mistakes
Updating records at the old DNS host after registrar NS already points elsewhere — WHOIS shows new NS while edits hit a dead zone.
Single NS hostname without redundancy — registries may accept it but resilience suffers.
Typos in glue hostnames at registrar — WHOIS lists broken NS that never resolve; DIG NS lookup exposes lame delegation quickly.
Frequently asked questions
- WHOIS NS updated but site down?
Zone at new NS may be empty or wrong A records — check authoritative answers, not just WHOIS.
- How long for NS changes?
Registry-side often minutes; caches honor prior TTL up to previous value — plan hours.
- Can WHOIS NS differ from DNS NS temporarily?
During propagation yes — document both timestamps when debugging.
- Should I change NS at registrar or DNS host first?
Populate records at the new DNS host, then update registrar NS — empty zones at new NS cause outages.