--- title: Did the nameserver change work? Find a domain's nameservers with the NS Lookup description: You moved DNS to Cloudflare or Route 53, changed the nameservers at the registrar, and you're not sure the world follows. To find a domain's nameservers, look up its NS records: they name the servers that answer for the domain. Here's how to check them with the free NS Lookup, how to spot a half-finished move or a lame delegation, and the dig commands that compare the registry's delegation with the zone. canonical: https://watchfor.io/blog/how-to-find-a-domains-nameservers --- # Did the nameserver change work? Find a domain's nameservers with the NS Lookup 2026-10-04 · WatchFor Team · Guides · guides, dns, networking You moved DNS to Cloudflare or Route 53, changed the nameservers at the registrar, and you're not sure the world follows. To find a domain's nameservers, look up its NS records: they name the servers that answer for the domain. Here's how to check them with the free NS Lookup, how to spot a half-finished move or a lame delegation, and the dig commands that compare the registry's delegation with the zone. To find a domain's nameservers, look up its NS records. They list the servers that hold the domain's zone and answer for it, such as `ns1.cloudflare.com` or `ns-421.awsdns-52.com`. After you change nameservers at your registrar, the NS lookup should return only the new provider's servers; any old server still in the list means the change hasn't fully taken effect, or the registrar still holds the old set. The free [NS Lookup](/ns-lookup) returns a domain's NS records as a resolver sees them, from a real WatchFor location, in under a second. No signup. ## What this tool answers *Which servers answer for this domain?* Reach for it after moving DNS to a new provider, when record edits seem to have no effect (you may be editing at a provider that no longer answers), and before debugging any other DNS problem, because the NS records tell you which server holds the truth. It also shows at a glance whether a domain relies on one DNS provider or several. ## A real example ### Finding a domain's nameservers to confirm a provider setup A question that comes up after any DNS move, and in every resilience review: which provider actually serves our zone, and is it one or two? We looked up a domain that deliberately runs on two providers at once. In the [NS Lookup](/ns-lookup) we typed `github.com`, kept the resolver on **Auto** (the location's own resolver) and pressed **Run lookup**: ![The NS Lookup for github.com from Europe / Lithuania: NOERROR, 8 records in 52 ms, four NS1 hosts dns1 to dns4.p08.nsone.net and four Amazon Route 53 hosts ns-1283.awsdns-32.org, ns-1707.awsdns-21.co.uk, ns-421.awsdns-52.com and ns-520.awsdns-01.net](/blog/how-to-find-a-domains-nameservers-result.webp) The lookup came back `NOERROR` with **8 records** in 52 ms: | Nameserver | Provider | | --- | --- | | dns1–dns4.p08.nsone.net | NS1 | | ns-421.awsdns-52.com | Amazon Route 53 | | ns-520.awsdns-01.net | Amazon Route 53 | | ns-1283.awsdns-32.org | Amazon Route 53 | | ns-1707.awsdns-21.co.uk | Amazon Route 53 | Two providers, four servers each. Resolvers pick among all eight, so if one provider has an outage, queries go to the other. That only works if both providers serve identical records, which GitHub has to keep in sync itself. Route 53's four names also span four TLDs (`.com`, `.net`, `.org`, `.co.uk`), so a problem with one TLD can't take all of them out. **The answer:** `github.com` is served by NS1 and Route 53 together, and the command-line check below shows the `.com` registry delegates to exactly these eight servers, all of which answer authoritatively. For your own domain after a move, the result you want is the new provider's servers only, and the same list at the registry. ## How to read the results | What you see | What it means | | --- | --- | | **Resolve time** | How long the query took (green under 50 ms, amber under 200 ms, red above). | | **NOERROR** (green) | The resolver answered. Amber means no usable answer: the name may not exist, or it isn't a zone (see Tips). | | **8 records** | How many nameservers the zone lists. Two is the minimum most registries require; four is common. | | **Host rows** | The nameserver names, with a trailing dot (fully qualified). Order is random and changes between lookups; it means nothing. | | **Location** | Signed out, the query runs from the WatchFor location nearest you. | The tool shows the names without TTLs. The TTL matters after a move: NS answers can be cached for a long time, so use `dig` (below) to see it. ## More ways to use it - **After moving to Cloudflare, Route 53 or another host.** Confirm the old provider's servers are gone. A mix of old and new means some resolvers still get answers from the old zone, and your edits at the new provider don't reach them. - **When edits don't take effect.** If the NS records point to your DNS host but you edited at the registrar, that's the problem. The [DNS records guide](/blog/how-to-check-dns-records) shows how to then query the authoritative server directly. - **Checking DNS redundancy.** All nameservers at one provider means one provider's outage takes your domain offline. Some teams add a second provider, as GitHub does; it needs records kept in sync. - **Before a domain transfer.** Note the nameservers so you can confirm they survive the move to the new registrar. - **Investigating a hijack.** Nameservers you don't recognise mean someone changed the delegation at the registrar. The [DNS hijacking guide](/blog/detect-dns-hijacking) covers the response. ## Tips and gotchas - **NS records live at the zone apex.** Ask for `example.com`, not `www.example.com`. A subdomain that isn't its own zone has no NS records of its own. - **Nameserver changes are slow to spread.** The `.com` registry publishes delegations with a TTL of 172,800 seconds (48 hours), and resolvers may keep the old set that long. Keep the old provider's zone running and identical until then. - **The registry and the zone can disagree.** Resolvers follow the registry's delegation first, then may use the NS records inside your zone. Update both: the nameservers at your registrar, and the NS records at the new DNS host. - **Lame delegation.** A listed nameserver that doesn't answer for the zone, or answers without authority, is "lame". Resolvers retry elsewhere, which slows lookups and hides the fault. Check each server as shown below. - **Registrar defaults sneak back.** Some registrars reset nameservers to their parking servers when a domain expires or a transfer fails; parked NS records are a sign something lapsed. ## Check it from the command line too The delegation as the `.com` registry publishes it (ask a TLD server, without recursion): ```bash dig +norecurse +noall +authority NS github.com @a.gtld-servers.net ``` ```text github.com. 172800 IN NS ns-520.awsdns-01.net. github.com. 172800 IN NS ns-421.awsdns-52.com. github.com. 172800 IN NS ns-1707.awsdns-21.co.uk. github.com. 172800 IN NS ns-1283.awsdns-32.org. github.com. 172800 IN NS dns1.p08.nsone.net. github.com. 172800 IN NS dns2.p08.nsone.net. github.com. 172800 IN NS dns3.p08.nsone.net. github.com. 172800 IN NS dns4.p08.nsone.net. ``` The same eight servers the zone lists, with the registry's 48-hour TTL. For other TLDs, find the TLD's servers with `dig +short NS org.` (or the TLD in question) and ask one of them. To catch a lame delegation, ask every listed server for the SOA without recursion and look for the `aa` (authoritative answer) flag: ```bash for ns in $(dig +short NS github.com | sort); do printf "%-28s " "$ns" dig +norecurse +noall +comments SOA github.com @"$ns" | grep -oE "flags: [a-z ]+;" done ``` ```text dns1.p08.nsone.net. flags: qr aa; dns2.p08.nsone.net. flags: qr aa; dns3.p08.nsone.net. flags: qr aa; dns4.p08.nsone.net. flags: qr aa; ns-1283.awsdns-32.org. flags: qr aa; ns-1707.awsdns-21.co.uk. flags: qr aa; ns-421.awsdns-52.com. flags: qr aa; ns-520.awsdns-01.net. flags: qr aa; ``` All eight answer with authority. A server that times out, returns `REFUSED` or lacks `aa` is lame and should be fixed or removed at the registrar. ## Keep watching it Nameservers change rarely, so an unplanned change is worth an alert. A [DNS monitor](/dns-monitoring) on the **NS** record type checks the answer from several locations on a schedule, and with the **Expected DNS Records** rule (one nameserver host per line) it opens an incident when the set stops matching, whether from a botched move, an expired domain parked by its registrar, or a hijacked delegation. ## FAQ **How do I find out what nameservers a domain uses?** Run an NS lookup on the domain (the zone apex, such as `example.com`). The result lists the nameservers; their names usually reveal the provider, such as `cloudflare.com` or `awsdns`. A [Whois lookup](/whois-lookup) shows the nameservers the registry holds as well. **How long does it take for nameserver changes to take effect?** Up to 48 hours for `.com` and many other TLDs, because the registry's delegation TTL is 172,800 seconds. Many resolvers pick up the change sooner, but plan for the full period and keep the old zone serving until then. **What happens if one nameserver goes down?** Resolvers try the next listed server, so a domain with several nameservers keeps resolving, usually a little slower. If every server sits at one provider and that provider fails, the domain stops resolving; that's the case for a second provider. More in [DNS record types explained](/blog/dns-record-types-explained). --- Canonical page: https://watchfor.io/blog/how-to-find-a-domains-nameservers · All articles: https://watchfor.io/blog/all.md · Site guide: https://watchfor.io/llms.txt