Nameserver Checker

Run an NS lookup on the root domain. The tool queries the parent zone (the TLD's nameservers) and returns the delegated nameserver hostnames — usually two to four entries like ns1.cloudflare.com, ns2.cloudflare.com. Compare these against what your registrar dashboard shows. If they don't match, delegation is broken or in transition. I always check both the parent-zone answer and the authoritative answer because a mismatch between them is a classic source of intermittent DNS failures clients can't explain.

Authoritative nameservers are the DNS servers that hold the actual zone file for a domain — they are the source of truth. When any resolver in the world wants to know "what's the A record for example.com ", the chain eventually leads back to these servers. They answer with original data, not cached copies. Every domain needs at least two authoritative nameservers (for redundancy) and they're declared via NS records at both the parent zone and inside the zone itself.

Check three places. First, the registrar dashboard — it should show the new NS values. Second, run a parent-zone NS lookup — the registry should reflect the new delegation. Third, query the new nameservers directly to confirm they're answering authoritatively for your zone. If all three agree, you're done. After that, propagation across recursive resolvers happens based on TTL — usually a few hours, sometimes up to 48. Use a global propagation checker to monitor multiple regions while it spreads.

Caching. Recursive resolvers (like Google DNS, ISP resolvers, OpenDNS) cache NS records for the TTL duration set at the parent zone — often 24 or 48 hours. Until that cache expires, they'll keep returning the old values even though the registry has the new ones. Parent-zone updates themselves can also lag by a few minutes to an hour after you save changes at the registrar. Patience is the answer — unless TTL was set very high, in which case you wait longer.

Log into the registrar account, find the domain in your dashboard, and look for "DNS settings ","Nameservers ", or "Delegation " — every registrar names it slightly differently. GoDaddy puts it under Domain Settings, Namecheap under Domain List, BigRock under Manage Orders. Once there, you'll see either the registrar's default nameservers or your custom ones (Cloudflare, AWS Route 53, etc.). Always cross-check what's saved here against an external NS lookup — sometimes saved settings don't match what's actually delegated at the registry.

Nameservers are the servers that host your zone — they're the location. DNS records (A, MX, TXT, CNAME, etc.) are the individual entries inside that zone — they're the contents. Think of nameservers as the building and DNS records as the rooms inside. You can move to a different building (change nameservers) and the rooms have to be set up there fresh. That's why moving DNS hosts requires recreating all your records on the new platform before flipping the NS settings.

At least two — that's the practical minimum and most TLDs require it. Standard practice is 2 to 4 nameservers from your DNS provider, ideally spread across different geographic regions and network paths for redundancy. Cloudflare, Route 53, and Google Cloud DNS all give you multiple NS entries by default. More than 4 is usually unnecessary and adds management overhead without real benefit. The point is: if one nameserver fails, others must keep answering. Single-NS setups are a known fragility waiting to happen.

Absolutely, and quickly. Wrong NS delegation means resolvers can't find your zone, so the website won't load, email stops, SSL renewals fail, and any third-party services using DNS verification (Google Search Console, Workspace, CDN setups) break too. It's one of the fastest ways to take an entire brand offline by mistake. Whenever you change nameservers, double-check the spelling — a single typo like ns1.cloudflrae.com instead of ns1.cloudflare.com will silently kill resolution for everyone.

Most subdomains use the parent's nameservers — they don't have their own NS records. So a query for NS records on `blog.example.com` usually returns nothing or refers up to the parent. But subdomains can be delegated separately if you've added NS records pointing them elsewhere — for example, delegating `app.example.com` to AWS Route 53 while the apex stays on Cloudflare. Run an NS lookup on the exact subdomain to confirm whether it's delegated independently or just inheriting from the parent zone.

Different tools query different sources — some hit the parent zone, others ask recursive resolvers, and some go directly to the authoritative servers. During delegation changes, these layers get out of sync until caches expire. A tool checking the parent zone will see new values quickly; a tool relying on a slow-refreshing resolver might still show the old ones. Also, tools with stale cached data of their own can mislead. If results disagree, trust the parent-zone query and the authoritative answer over cached recursive resolver data.