--- title: Free NS Lookup description: Find the authoritative nameservers for a domain — the NS records the world delegates to, with TTLs. 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, with TTLs. 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. Result No result yet Enter the inputs above and press Run. Results appear here in a moment. Monitor this 24/7 — get alerts on the first failure. [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 the world sees them — and, if you point it at the parent zone's servers or use the resolver field to ask a specific nameserver, as the delegation says they are. 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 — Put the TLD's nameserver in the resolver field (find it with an NS lookup of com ) to see the delegation records the parent holds — the ones the registrar set. If child and parent disagree, resolvers can flap between two providers. - 3 Verify each server answers — Point the resolver field at each NS host in turn and query any record: a server that returns REFUSED or SERVFAIL 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. ## 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 alerts the moment something breaks — across HTTP, DNS, SSL, RDAP, ping, blacklist and more. Free forever for 10 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.](/dns-propagation-checker) - [Whois LookupModern RDAP-based domain registration lookup: registrar, expiry, nameservers, status flags.](/whois-lookup) - [A Record LookupFind the IPv4 address a domain resolves to — every A record with its TTL, from the resolver of your choice. Spot a stale IP after a migration, a missing record behind a 'site can't be reached', or a round-robin set that is one address short.](/a-record-lookup) --- Canonical page: https://watchfor.io/ns-lookup · Site guide: https://watchfor.io/llms.txt