---
title: Free NS Lookup
description: Find the authoritative nameservers for a domain — the NS records the world delegates to. Confirm a nameserver change at the registrar has taken effect, catch a lame delegation, and know which servers to query for the truth about a record.
canonical: https://watchfor.io/ns-lookup
---

[Back to all free tools](/free-tools)

# NS Lookup

Find the authoritative nameservers for a domain — the NS records the world delegates to. Confirm a nameserver change at the registrar has taken effect, catch a lame delegation, and know which servers to query for the truth about a record.

[How to use this tool](/blog/how-to-find-a-domains-nameservers)

Result

No result yet

Fill in the form above and run it — the result appears here.

Monitor this 24/7 — get alerted when a failure is confirmed.

[Start free](/auth/sign-up)

Only run these tools against systems you own or are authorized to test. Using them to scan or probe systems without permission violates our [Terms](/legal/terms).

## What is NS Lookup ?

NS records name the authoritative nameservers for a zone — the servers that hold the real answers for example.com . Everything else in DNS is a cache of what those servers say. When you move DNS hosting (from a registrar's default servers to Cloudflare, Route 53, NS1…), the NS records at the registrar are what actually performs the move; until they change, nobody asks your new provider anything.

This tool returns a domain's NS records as a resolver sees them, or as one specific nameserver answers if you put its IP in the Custom IP field. Use it to confirm a nameserver change went through, to find the authoritative servers before querying them directly for an uncached answer, and to catch a lame delegation where the parent points at a server that doesn't answer for the zone.

## How it works

NS lookups have two sources of truth, and comparing them is the point:

- 1 Ask the resolver for QTYPE=NS — A recursive resolver answers from cache or by walking the hierarchy. The answer is normally the NS set published inside the zone itself (the child's view).
- 2 Ask the parent zone — The delegation records the parent (the TLD) holds — the ones the registrar set — come back as a referral, which this tool doesn't display. The dig … @a.gtld-servers.net line below shows them. If child and parent disagree, resolvers can flap between two providers.
- 3 Verify each server answers — Put each NS host's IP in the Custom IP resolver field in turn and query any record: a server that errors or times out for the zone is a lame delegation.

Registrar changes to NS records propagate on the parent zone's TTL — typically 24–48 hours for TLDs — which is the origin of the folk wisdom that DNS "takes two days".

## When you'd use it

### After changing DNS providers

You updated the nameservers at the registrar. Look up the NS records: when the new provider's servers appear in the answer, the delegation has moved. Until then, edits in the new provider's dashboard change nothing anyone sees.

### Getting an uncached answer

Any resolver may be serving a stale record. Find the authoritative servers with an NS lookup, then query them directly for the record you care about — that's the ground truth, TTL-free.

### Diagnosing intermittent resolution failures

Some queries work, some fail. One of the four nameservers is down or was never configured for the zone; resolvers that happen to pick it get SERVFAIL . Test each server individually.

### Domain audits and takeover checks

A domain delegated to nameservers at a provider where the zone was deleted is claimable by anyone who creates that zone at the provider. An NS lookup plus a test query to each server exposes it.

## Reading the result

### The NS set

Usually two to four hostnames, ideally on different networks. All must be authoritative for the zone and all must answer — resolvers pick among them and don't retry forever.

### Child vs parent

The zone's own NS records and the parent's delegation should match exactly. A mismatch after a provider change means the registrar side (parent) or the zone file (child) was updated but not the other.

### Glue records

When a nameserver's name is inside the zone it serves ( ns1.example.com for example.com ), the parent must also hold its IP address — the glue. Missing or stale glue is a common cause of a zone that mysteriously stops resolving after a nameserver IP change.

### TTL

NS records typically carry long TTLs (hours to two days). A change is not "done" until that time has passed everywhere. The tool doesn't show NS TTLs; dig does.

## Check it yourself

dig NS example.com @1.1.1.1 +noall +answer dig NS example.com @a.gtld-servers.net asks the .com parent for the delegation; dig +trace example.com shows the whole path from the root.

## Common pitfalls

### Changing NS at the registrar before the zone exists at the new provider

Resolvers start asking servers that answer REFUSED . Build the zone at the new provider first, verify it answers, then switch the delegation.

### Forgetting records during the move

The new provider only knows what you entered. MX, TXT for SPF/DKIM/DMARC, the _acme-challenge and verification records — export everything from the old zone before the switch.

### Mixing providers' nameservers

Two of the NS records at provider A and two at provider B is not redundancy; it's two zones with different content answered at random. All servers in the set must serve the same zone.

## Run NS Lookup on every change, not just once.

Get alerted when an outage is confirmed — across HTTP, DNS, SSL, RDAP, ping, blacklist and more. Free forever for 15 monitors. No card.

[Start free](/auth/sign-up)

## Frequently asked questions

What is the difference between NS records and nameservers set at the registrar? The registrar pushes what you enter into the parent zone (the TLD) as the delegation. Your zone also lists its own NS records. Both should match; the parent's copy is what resolvers use to find you, the child's copy is what they trust once they get there.

How long does an NS record change take? Up to the parent's TTL — 48 hours for .com , less for many other TLDs — plus the old NS records' own TTL in resolver caches. Most of the internet sees it within a few hours.

What is a lame delegation? An NS record naming a server that isn't authoritative for the zone — it answers with REFUSED , SERVFAIL , or a referral back up. Resolvers that pick that server fail; ones that pick another succeed, so the failure looks random.

How many nameservers should a domain have? At least two on separate networks (RFC 2182). Managed DNS providers give you four or more anycast names, which is plenty.

Why is NS lookup called nslookup? nslookup is the name of the classic command-line DNS tool, which queries any record type. This page looks up NS records specifically; the DNS Lookup tool covers the rest.

## Related dns tools

- [DNS LookupResolve A, AAAA, MX, TXT, NS, SOA, CNAME, PTR, CAA, SRV records for any domain.](/dns-checker)
- [DNS PropagationCheck how a DNS record looks from every prober region simultaneously — spot stale anycast nodes and propagation gaps on a world map — plus an A+ to F DNS health grade for the zone: nameservers, delegation, DNSSEC and CAA.](/dns-propagation-checker)
- [Whois LookupModern RDAP-based domain registration lookup: registrar, expiry, nameservers, status flags.](/whois-lookup)
- [DNS Health CheckerGrade a domain's DNS A+ to F: how many nameservers it has and on which networks, lame delegation, whether the registry and the zone agree, SOA serials, DNSSEC and CAA, with the fix for every problem. Then see what every probe location answers, on a map.](/dns-health-checker)

---

Canonical page: https://watchfor.io/ns-lookup · Site guide: https://watchfor.io/llms.txt
