Nameserver (NS) Check
Look up a domain's nameservers and check their consistency.
NS Check looks up which authoritative nameservers a domain is delegated to, in real time. Every DNS record for a domain (A, MX, TXT and so on) is ultimately answered by these nameservers, so knowing what the NS records are is the starting point for troubleshooting DNS. Check individual record values with DNS Record Lookup and registrar metadata with WHOIS / Domain Lookup.
It is especially useful when moving a domain or switching DNS hosting: confirm that the NS records registered at your registrar match the nameservers actually answering on the internet. Just enter a domain — no protocol or path needed.
NS records and delegation
NS records tell you which nameservers the parent zone (e.g. .com) has delegated the domain to. There are usually two or more for redundancy, so that one nameserver going down does not take the domain offline. The values shown here are the delegation seen by a public resolver, and they should match what is configured at your registrar.
Changing nameservers — run both during propagation
When you switch nameservers, resolvers worldwide keep querying the old ones for as long as the delegation was cached (typically 24–48 hours). Until propagation finishes you must keep the same records (A, MX, TXT, etc.) on both the old and new nameservers, or some users will see the site or mail go dark. Configuring only one side causes intermittent outages. Track how far the delegation has spread with DNS Propagation Check.
- Confirm the NS at your registrar matches the NS at your DNS host
- Keep identical records on the old and new nameservers during propagation
- Zero nameservers means the domain is undelegated or does not exist
Common nameserver problems → symptom → fix
Nameserver faults fall into a handful of recognizable categories. Use the symptom column to narrow down the cause, then apply the fix. A domain can be delegated correctly and still lose points on answer consistency and redundancy.
| Problem | Symptom | Fix |
|---|---|---|
| Parent/child NS mismatch | The NS the registrar (parent zone) hands out differs from the zone's own NS records. Different resolvers return different answers | Align both NS sets. Set the registrar NS to the zone's real authoritative nameservers and update glue |
| Lame delegation | A server listed as an NS does not answer authoritatively (no AA flag) for the zone. Timeouts, REFUSED, or non-authoritative replies | Actually host the zone on that NS, or remove/replace the nameserver that does not answer |
| Single NS | Only one NS, so there is no redundancy. If that server dies the whole domain stops resolving | Add at least two nameservers (RFC recommendation), ideally on separate paths and locations |
| All NS in one subnet/provider | Multiple NS, but all in the same subnet/AS/provider. A single failure can take them all down at once | Diversify across networks, regions, and providers. Consider adding a secondary DNS provider |
A worked mismatch diagnosis
Suppose querying the parent zone at the registrar (dig NS example.com @a.gtld-servers.net) returns ns1.oldhost.com and ns2.oldhost.com, but querying an authoritative nameserver directly (dig NS example.com @ns1.newhost.com) returns ns1.newhost.com and ns2.newhost.com. The two sets differ, so this is a textbook parent/child NS mismatch. The cause: you migrated DNS hosting and put the new NS in the zone, but the registrar still lists the old NS. The fix is to change the NS in the registrar's control panel to ns1.newhost.com and ns2.newhost.com, updating glue records too if they are required. After the change, track how the new delegation spreads with DNS Propagation Check.