NS Record Lookup
Find the authoritative nameservers for any domain. Enter a domain and this tool queries its NS records live and lists every nameserver responsible for the zone, with TTLs. This is the online equivalent of nslookup -type=ns or dig NS — the quickest way to confirm where a domain's DNS is actually hosted and whether a registrar change has taken effect.
Runs in your browser over DNS-over-HTTPS (Google / Cloudflare). Nothing is sent to our server and nothing is stored.
How to use the NS Record Lookup
Enter the registered domain (the apex, like example.com, not a subdomain) and press Look up nameservers. The tool reports:
- Every NS record the zone publishes — the hostnames of its authoritative nameservers.
- The TTL on the records.
- A clear status (NOERROR, NXDOMAIN) so you know whether the name is delegated at all.
Query the apex domain rather than a subdomain: authoritative NS records normally live at the zone apex. If you paste a full URL or a subdomain, the tool strips it down, but for a delegated subzone you may need to query that exact name.
What NS records and nameservers do
NS (NameServer) records name the servers that hold the authoritative DNS data for a domain. They are the answer to "who is in charge of this domain's DNS?". When a resolver needs any record for example.com — its A record, MX, TXT, anything — it first finds the domain's nameservers from the NS records, then asks one of them for the actual answer. The nameservers are where every other record physically lives.
There are really two copies of a domain's NS set, and they should match:
- The delegation at the parent (the TLD's registry, set through your registrar). This is what the rest of the internet follows.
- The in-zone NS records published by the nameservers themselves.
This tool shows the NS records as a public resolver sees them. Most domains list two to four nameservers, deliberately spread across different networks so DNS keeps working if one provider has an outage. The hostnames usually reveal the DNS host — ns1.cloudflare.com, ns-123.awsdns-45.com, dns1.registrar-servers.com and so on — which makes NS lookup a fast way to identify who runs a domain's DNS.
NS records matter most during a migration. When you move DNS from one provider to another, or transfer a domain, you change the nameservers at the registrar. Until that change propagates (governed by the parent delegation's TTL, often a day or two) some resolvers still send queries to the old nameservers, which can serve stale records. Checking the live NS set is how you confirm a delegation change has actually gone through before you rely on it.
Common use cases
- Confirming a DNS migration — verify the nameservers now point at the new provider after changing them at the registrar.
- Identifying a domain's DNS host — the nameserver hostnames usually reveal who runs the DNS (Cloudflare, Route 53, the registrar).
- Debugging resolution problems — a missing or wrong NS set at the apex means the domain is not properly delegated.
- Checking redundancy — confirm a domain lists more than one nameserver, ideally on independent networks.
- Auditing before a transfer — see the current delegation so you know what to replicate on the new host.
NS lookup vs the classic nslookup command
The desktop nslookup and dig commands query DNS over UDP port 53, which a browser cannot do. This tool gets the same NS data over DNS-over-HTTPS instead, so it works from any browser with no install. The equivalents are:
nslookup -type=ns example.comdig NS example.com +shorthost -t ns example.com
One difference worth knowing: a command-line dig +trace can show the delegation as the parent TLD reports it, which is the authoritative source of truth. A DoH lookup shows what a recursive resolver returns, which is what virtually all real traffic follows. For confirming "have my new nameservers gone live for users", the resolver view here is exactly what you want. To then inspect the records those nameservers serve, use the general DNS lookup for any record type.