NS Lookup

Why You Are Here

Nameservers decide which servers hold the authoritative answers for a domain. Everything else in DNS, the website address, the mail routing, the verification records, is only reachable once a resolver knows where to ask.

You have changed nameservers and want to confirm it worked. Moving DNS hosting, switching registrars, or pointing a domain at a new provider all mean updating nameservers, and the change is not instant. This is how you check whether it has taken effect.

A domain is resolving inconsistently. It works for some people and not others, or it works from one network and fails from another. Mismatched or stale nameserver records are among the most common causes.

You are investigating another domain's setup. Confirming which DNS provider a company uses, checking a client's configuration before taking over their DNS, or diagnosing why a partner's domain keeps failing.

What This Tool Does

The NS Lookup tool queries the DNS records for any domain you enter and returns its nameserver configuration.

Enter a domain name and the tool returns the nameservers currently listed as authoritative for it, showing you which servers hold the domain's DNS records and answer queries about it.

The results tell you which DNS provider a domain uses, whether a nameserver change has propagated, and whether the delegation appears correctly configured.

How DNS Delegation Works

DNS is a hierarchy, and NS records are what connect each level to the next. Understanding the chain explains what a lookup is actually showing you. When a resolver needs to find www.example.com, it does not know where to ask, so it works down from the top:

The root servers are asked which servers handle .com
The .com servers are asked which servers handle example.com, and they answer with its NS records
Those nameservers are asked for www.example.com and give the authoritative answer

Each step is a delegation

A parent zone points at the child zone's nameservers, and that pattern repeats all the way down. It is what makes DNS a distributed system rather than one central database that everyone must query.

NS records do not contain IP addresses

They contain hostnames, exactly like MX records. A resolver that receives ns1.example.com still needs that name's address before it can ask anything, which is where glue records come in.

The Two Sets of NS Records

This is the single most useful thing to understand about nameservers, and it explains a whole category of confusing failures.

Every domain has NS records in two places, and both must agree

	Delegation records	Authoritative records
Location	The parent zone, usually the TLD	Your own zone file
Set at	Your domain registrar	Your DNS provider
Who returns them	The .com servers, or your TLD's	Your own nameservers
Authoritative?	No, these are a referral	Yes

When they diverge, resolution becomes unreliable rather than broken

Resolvers may receive one set or the other depending on what they have cached and which path they took, so the domain works for some people and fails for others. Because it is intermittent rather than total, it is frequently misdiagnosed as a caching problem or a local network issue.

This is most common right after a migration

Someone updates the nameservers at the registrar but the old zone file still lists the previous nameservers, or vice versa. Both need changing.

How many records to publish

At least two, for basic resilience. Four is a common de facto standard, enough to survive an outage without producing unnecessarily large DNS responses. Publishing one is fragile, and publishing eight or more mainly adds response size.

Glue Records

Glue solves a genuine chicken-and-egg problem, but it only applies in one specific situation, and this is where most explanations become muddled.

The problem it solves

If example.com is served by nameservers called ns1.example.com and ns2.example.com, a resolver hits a loop: to reach ns1.example.com it needs that host's IP address, but to look up that address it needs to ask the nameservers for example.com, which are the very servers it cannot reach yet.

Glue breaks the loop

The parent zone publishes the IP addresses alongside the delegation, so the resolver receives both the nameserver names and their addresses in one response and can proceed directly.

When glue is required and when it is not

Your nameservers	Glue needed?	Why
ns1.example.com for example.com	YES	Inside the domain they serve, so the loop exists
ns1.dnsprovider.com for example.com	NO	Different domain, resolvable independently
Vanity nameservers on your own domain	YES	Same as the first case

If you use your DNS provider's nameservers, you need no glue at all

This covers most domains. The parent zone should not publish glue for out-of-domain nameservers, and asking a registrar to add it is unnecessary.

Glue is set at the registrar, not in your zone

It lives at the parent, which means changing the IP address of a nameserver inside your own domain requires updating the glue record at the registrar as well as your zone file. Updating only the zone file leaves the parent handing out an address that no longer works.

Lame Delegation

A lame delegation is when an NS record points at a server that is not actually authoritative for the zone. The referral exists, but the destination cannot answer.

Cause	What happened
Nameserver removed but delegation left in place	The record still points at a server no longer hosting the zone
Zone never configured on the server	The delegation was set before the zone was created
Provider account closed or expired	The server no longer recognises the domain
Typo in the nameserver hostname	Points at a host that does not serve the zone

The effect is slow, intermittent failure rather than a clean error

Resolvers try the lame server, wait for a timeout, and only then try another. If some of your nameservers are lame and others work, the domain resolves eventually but slowly and unpredictably.

This is a common leftover from migrations

Nameservers get added at the new provider and the old ones are never removed, leaving delegations pointing at servers that stopped serving the zone months ago.

Reading Your Results

What you see	What it indicates
Nameservers on a provider's domain	The domain uses that provider's DNS
Nameservers on the domain's own name	Self-hosted or vanity nameservers, glue required
Only one nameserver	Fragile, no redundancy
Four or more, consistent naming	Standard, well-configured delegation
Nameservers from two different providers	Either a migration in progress or a deliberate multi-provider setup
Old and new providers both listed	Almost always an incomplete migration
No nameservers returned	Domain is unregistered, expired, or delegation is missing

Two different providers is not automatically wrong. Some organisations deliberately run multiple DNS providers for resilience. But if you did not set that up intentionally, it is a migration that was never finished.

Common Mistakes to Avoid

Changing Nameservers at the Registrar Without Updating the Zone

A nameserver change involves two places: the delegation records at your registrar and the authoritative records in your zone file. Updating only one leaves the two sets disagreeing, which produces intermittent resolution failures that vary by resolver and are frequently misdiagnosed as caching problems. Check both after any migration and confirm they match.

Forgetting Glue Records When Changing a Nameserver's IP Address

If your nameservers sit inside your own domain, their IP addresses are published as glue at the parent zone, set through your registrar. Changing the address in your zone file alone leaves the parent handing out the old address, and resolvers that rely on glue will keep trying a server that is no longer there. Update the glue at the registrar at the same time.

Pointing an NS Record at a CNAME

NS records must reference a hostname that resolves through an A or AAAA record. Pointing one at a CNAME is invalid, and the resulting behaviour varies by resolver, producing failures that appear inconsistent and depend on who is asking. This is the same restriction that applies to MX records, and it catches people for the same reason.

Quick Reference

Item	Detail
NS record	Which servers are authoritative
Contents	A hostname, never an IP
Minimum	Two nameservers, four is common
Two record sets	Registrar and zone file
Both sets	Must match
Mismatch	Causes intermittent failures
Glue	Nameserver IPs at the parent zone
Glue needed	Only for in-domain nameservers
Glue location	Set at the registrar
Changing a nameserver IP	Means updating glue too
Lame delegation	Points at a non-authoritative server
CNAME	Never point an NS record at one

Frequently Asked Questions

What is an NS lookup?

An NS lookup queries a domain's DNS to find its nameserver records, which identify the servers authoritative for that domain. This NS Lookup tool returns the nameservers currently listed for any domain you enter, showing which DNS provider holds its records and answers queries about it.

What is a nameserver?

A nameserver is a server that holds the DNS records for a domain and answers queries about it. When any resolver needs to find a domain's website address, mail servers, or other records, it asks that domain's authoritative nameservers. Which servers those are is exactly what an NS lookup reveals.

How many nameservers should a domain have?

At least two, so a single server failure does not make the domain unreachable. Four is a common standard, providing solid redundancy without making DNS responses unnecessarily large. A single nameserver is a fragile configuration, and going well beyond four mainly increases response size for little practical gain.

Why does my domain resolve for some people but not others?

Most often because the two sets of NS records disagree. The delegation records at your registrar and the authoritative records in your zone file must match, and after a migration they frequently do not. Resolvers may get one set or the other depending on their cache and path, so the domain works inconsistently rather than failing outright.

What is a glue record?

A glue record is the IP address of a nameserver, published at the parent zone alongside the delegation. It is needed when a domain's nameservers sit inside that same domain, since a resolver would otherwise need to reach those nameservers to find their addresses. Glue breaks that circular dependency and is configured at your registrar.

Do I need glue records?

Only if your nameservers are hostnames within the domain they serve, such as using ns1.example.com for example.com. If you use your DNS provider's nameservers on their own domain, no glue is required and the parent zone should not publish any. Most domains fall into this second category.

How long does a nameserver change take?

Nameserver delegations are cached according to their TTL, and TLD-level records commonly carry longer TTLs than ordinary records, so a change can take considerably longer to propagate fully than a routine DNS update. Keep the old DNS records live at the previous provider throughout, since resolvers holding cached delegations will continue querying the old nameservers.

Can I check the nameservers of any domain?

Yes. Nameserver records are public DNS information, published so that any resolver on the internet can find out where to send queries for a domain. Use this NS Lookup tool with any domain name to see its authoritative nameservers, whether or not the domain belongs to you.

Search

Nameserver Records