NS Lookup

Nameserver lookup for any domain: the NS records its registry hands out, with glue and TTL, beside what every nameserver says for itself. Lame servers, mismatches and stale glue are named, with the fix.

Sources: the registry's servers, reached from a root server · each nameserver's IPv4 addresses, asked directly · Google Public DNS · Cloudflare 1.1.1.1 · Team Cymru · RDAP

What is an NS record?

An NS record names a server that holds a zone: the place where a domain's records live. A zone lists one NS record per server, so google.com has four, ns1 to ns4.google.com (RFC 1035 §3.3.11).

The same NS records exist twice. The parent zone, here .com, keeps a copy at the cut so it can send resolvers on; that copy is not authoritative. The zone keeps its own copy at its top, and that one is (RFC 1034 §4.2.1, RFC 2181 §6.1). The two should be exactly the same.

The value is always a host name, never an address, and never an alias: the name must have A or AAAA records of its own (RFC 2181 §10.3).

An NS record, part by partgoogle.com · recorded 2026-10-23
google.com.Owner345600TTLINClassNSTypens1.google.com.Value
OwnerThe zone the record belongs to.
TTL · 4 daysHow long a resolver may keep it. The .com copy says 2 days.
NSRecord type 2: a nameserver for this zone.
ValueA host name with its own A or AAAA records.
The parent's copy · .comgoogle.com. 172800 NS ns1.google.com.ns1.google.com. 172800 A 216.239.32.10Not authoritative: a referral, with glue
The zone's own copygoogle.com. 345600 NS ns1.google.com.;; flags: qr aaAuthoritative: what resolvers keep
ns1.google.com.A host name with its own addresses
216.239.32.10An address is not a valid value
ns.example.com. → CNAMENever an alias (RFC 2181 §10.3)
Both copies recorded live: the .com registry's referral from l.gtld-servers.net and ns1.google.com's own answer.

How to check a domain's nameservers

Type the domain above and press Check nameservers: we ask the registry, then each server it names that our server can reach. From a terminal: dig NS example.com on macOS and Linux, nslookup -type=ns example.com on Windows, Resolve-DnsName -Name example.com -Type NS in PowerShell.

Those three ask your own resolver, so they show a cached copy. To see the registry's list, ask its server with recursion off: dig @a.gtld-servers.net example.com NS +norec. To test one nameserver, ask it for the SOA with +norec and look for aa in the flags. whois shows the registry's list too, not the zone's.

dig NS example.com +short

Your resolver's copy, one nameserver per line. Add @a.gtld-servers.net and +norec for the .com registry's own list.

Reading dig's two answersgoogle.com · recorded 2026-10-23
dig · macOS, Linux
$ dig @l.gtld-servers.net google.com NS +norec
;; ->>HEADER<<- opcode: QUERY, status: NOERROR
;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 91
;; AUTHORITY SECTION:
google.com.       172800  IN  NS  ns2.google.com.2
google.com.       172800  IN  NS  ns1.google.com.
…
;; ADDITIONAL SECTION:
ns1.google.com.   172800  IN  A   216.239.32.103
…

$ dig @216.239.32.10 google.com NS +norec
;; flags: qr aa; QUERY: 1, ANSWER: 4, AUTHORITY: 04
google.com.       345600  IN  NS  ns1.google.com.5
…
  1. No aa: a referral. The registry doesn't serve google.com; it says where to go.
  2. The parent's list and its TTL: 2 days, set by the .com registry.
  3. Glue: ns1.google.com is inside google.com, so .com hands out its address.
  4. aa: the zone itself. An authoritative answer from the server.
  5. The zone's own TTL: 4 days, set by Google, not by the registry.
nslookup · asking 8.8.8.8
$ nslookup -type=ns google.com 8.8.8.8
Server:   8.8.8.8
Address:  8.8.8.8#53

Non-authoritative answer:
google.com  nameserver = ns3.google.com.
google.com  nameserver = ns1.google.com.
…
PowerShell
# your resolver's copy
PS> Resolve-DnsName -Name google.com -Type NS

# one server, recursion off
PS> Resolve-DnsName -Name google.com -Type SOA -Server ns1.google.com -NoRecursion
whois
$ whois google.com
Registrar: MarkMonitor Inc.
Name Server: NS1.GOOGLE.COM
…
DNSSEC: unsigned
Recorded on 2026-10-23. "Non-authoritative answer" means a resolver's cached copy, here Google Public DNS's, which keeps NS records for at most 6 hours. whois prints the registry's list. Neither shows what each server says.

Reading the result

The verdict names the DNS host and the registrar; the Delegation view sets the registry's list beside the zone's, server by server, with each one's answer and its time over TCP (the connection's setup included, so about two round trips).

The navy column is the path a resolver takes: the root, the registry with its TTL and DS, then each nameserver. A server that doesn't serve the zone is broken off.

NS lookup of github.com: eight nameservers at NS1 and Route 53, each server's answer and the delegation from .comNS lookup of github.com: eight nameservers at NS1 and Route 53, each server's answer and the delegation from .comThe verdictWho serves the zone, who registered it, and whether the registry and the zone agree.The registry beside the zoneEach name in the registry's list and the zone's own, with glue and the answer.Each server's answerAA and its time over TCP, the code a refusing server sent, or via 1.1.1.1 where our server can't connect.The delegationRoot, registry, then each server's own answer, as a resolver walks it.
An NS lookup of github.com: the verdict, the registry's eight nameservers beside the zone's own list, each server's answer and the delegation from the .com registry. Select a number to see what each part shows.

Parent vs child nameservers: why they differ

Two different parties keep the two lists. The registry publishes the parent's list when your registrar tells it to; your DNS host serves the zone's own list. Change one without the other and they drift apart.

Resolvers trust the zone's own answer more than the referral (RFC 2181 §5.4.1), so once they have asked the zone they keep its list and its TTL. On 2026-10-23 Cloudflare's resolver held google.com's NS set with 340,859 s left: more than .com's 172,800, so the copy came from the zone's 4-day TTL.

A name only in the registry's list still gets traffic from resolvers that start fresh. A name only in the zone is invisible to them. Both are worth fixing; neither is an outage on its own.

The registry's list beside the zone'srecorded 2026-10-23
xserver.ne.jp5 vs 3

Registry .jp1 day

  • ns1.xserver.jp
  • ns2.xserver.jp
  • ns3.xserver.jp
  • ns4.xserver.jpregistry only
  • ns5.xserver.jpregistry only

Zone1 hr

  • ns1.xserver.jp
  • ns2.xserver.jp
  • ns3.xserver.jp

ns4.xserver.jp and ns5.xserver.jp are at the registry only. Both answer with authority, so nothing breaks; the lists still differ.

github.comthe same 8

Registry .com2 days

  • dns1.p08.nsone.net
  • dns2.p08.nsone.net
  • dns3.p08.nsone.net
  • dns4.p08.nsone.net
  • ns-1283.awsdns-32.org
  • ns-1707.awsdns-21.co.uk
  • ns-421.awsdns-52.com
  • ns-520.awsdns-01.net

Zone15 min · 1 hr

  • dns1.p08.nsone.net
  • dns2.p08.nsone.net
  • dns3.p08.nsone.net
  • dns4.p08.nsone.net
  • ns-1283.awsdns-32.org
  • ns-1707.awsdns-21.co.uk
  • ns-421.awsdns-52.com
  • ns-520.awsdns-01.net

Same names, different clocks: the registry's copy lasts 2 days, Route 53's 15 minutes, NS1's 1 hour.

A .net domain(name withheld)no name in common

Registry .net2 days

  • ns1.domaindirect.comregistry only
  • ns2.domaindirect.comREFUSED
  • ns3.domaindirect.comregistry only

Zone15 min

  • ns1.hover.comzone only
  • ns2.hover.comzone only

The registry still lists the old names. Two of them share addresses with Hover's servers and answer; the third refuses.

Lines join the names both lists share; a dashed line joins two names on one address. The third case is a real registration found in a random scan; its name is withheld.

What are glue records?

Glue is an address the parent hands out with its referral, so a resolver can reach a nameserver whose name sits inside the zone it serves. Without it, finding ns1.google.com would mean asking google.com's servers, which is the question you started with (RFC 1034 §4.2.1).

RFC 9471 makes it a rule: a referral MUST carry the glue of every in-domain server (ns1.google.com for google.com), and SHOULD carry it for sibling servers under the same parent (ns-421.awsdns-52.com for github.com). An unrelated name such as ns-520.awsdns-01.net is looked up on its own.

Glue is set at the registrar, as host records, child nameservers or personal DNS servers. When a server moves, the glue must move too: stale glue sends resolvers to an address that no longer answers.

Glue, and when it's neededrecorded at .com, 2026-10-23

In-domain · google.com

  1. .com: ask ns1.google.com
  2. Its address lives in google.com itself
  3. without glue, the lookup loops
  4. So .com adds ns1.google.com A 216.239.32.10 · MUST: required

Sibling and unrelated · github.com

  1. .com: ask ns-421.awsdns-52.com, ns-520.awsdns-01.net, …
  2. awsdns-52.com is also under .com: glue 205.251.193.165 · SHOULD: included
  3. awsdns-01.net is elsewhere: the resolver looks it up in .net · no glue
Stale glue · live64.69.208.141.com's glue for ns1.register.com · no answer, asked twice162.214.41.25its A record today · answers with authority
ns1.register.com's host object at .com, read through rdap.verisign.com on 2026-10-23: the registry still holds an address the server left, and hands it out as glue.

What is a lame delegation, and how to fix it

A delegation is lame when the parent sends resolvers to a server that doesn't serve the zone: it refuses, says nothing, or answers without authority. If every listed server is lame, the domain stops resolving; if one of several is, lookups get slower while resolvers retry.

RFC 9499 notes that "lame delegation" has come to cover several faults, so the tool names each one: refuses the zone (REFUSED), no answer (asked twice), answers without authority (no aa), server error (SERVFAIL). Silence over TCP alone isn't called lame while Google and Cloudflare still resolve the domain: it is named no TCP answer, as that server may answer over UDP.

The fix is always on one of two sides: add the zone at the DNS host the registry points to, or point the registry at the host that has the zone. Resolvers may remember the failure for up to 5 minutes after the fix (RFC 9520).

Three lame servers, recorded2026-10-23 · domains withheld

Refuses the zone

ns63 · ns64.domaincontrol.com

Both GoDaddy servers named by .com answer REFUSED: the zone isn't set up there.

bash
$ dig @ns63.domaincontrol.com \
    example.com SOA +norec
;; … status: REFUSED
;; flags: qr; … ANSWER: 0

A timeout, then REFUSED

ns1 · ns2.eftydns.com

One server timed out once, then answered REFUSED when asked again. One timeout is not a verdict: the tool asks again before it names a state.

bash
$ dig @ns1.eftydns.com \
    example.com SOA +norec
;; connection timed out
# asked again
;; … status: REFUSED

One of three

ns1 · ns2 · ns3.domaindirect.com

Two servers answer with authority; the third refuses. The domain works, more slowly.

bash
$ dig @ns2.domaindirect.com \
    example.net SOA +norec
;; … status: REFUSED
# ns1, ns3: NOERROR, flags qr aa
  1. See where the registry pointsThe Delegation view lists the registry's servers and each one's answer.
  2. Fix one sideAdd the zone at that host, or change the nameservers at the registrar.
  3. Check againAnswers return at once; a cached failure lasts up to 5 minutes.

What visitors get when every server is lame:Google SERVFAILCloudflare SERVFAIL

Recorded from registrations found in a random scan; their names are withheld and shown as example.com and example.net.

How many nameservers do you need?

At least two: "The DNS specification and domain name registration rules require at least two servers for every zone" (RFC 2182 §5, BCP 16). The same section recommends three for most organisations, with one well removed from the others, and four or five where reliability matters more.

Count networks, not names. Servers should sit where one failure can't reach them all (RFC 2182 §3.1): six servers in one /22 share one routing fate. Anycast spreads one address over many sites and is the usual answer, but it is still one operator; a second provider survives that operator's outage (RFC 8901).

More is fine. RFC 1912's old limit of seven came from 512-byte UDP answers; big zones run eight today (github.com, bbc.co.uk).

Servers, grouped by networkrecorded 2026-10-23
DomainServers by networkNSNetworksReading
google.comGoogle · AS15169 · anycast41Anycast, one operator
github.comNS1 · AS62597Route 53 · AS16509 · anycast82Two providers
bbc.co.ukNetActuate · AS63911NS1 · AS6259782Two networks
xserver.ne.jpXserver · AS131965Amazon · AS1650952Two networks
craigslist.orgcraigslist · AS2241461One /22

"It is recommended that three servers be provided for most organisation level zones, with at least one which must be well removed from the others."

RFC 2182 §5 · BCP 16, July 1997 · two required, three recommended
A box is one network (AS); a tinted box is an anycast provider: many sites, one operator. xserver.ne.jp's second network is ns2.xserver.jp on Amazon's; craigslist.org's six servers share one /22.

How to change nameservers, and how long it takes

Change them where the domain is registered, not at the DNS host: the registrar sends the new list to the registry, and the registry publishes it. Add the zone at the new host first, with every record, so the new servers answer the moment they are named.

Then two clocks run. Resolvers that cached the registry's referral keep the old list for up to the parent TTL: 2 days at .com, 1 day at .de and .jp, 1 hour at .org. Resolvers that already asked the zone keep the old zone's own NS set for its TTL, which can be longer: google.com's is 4 days. Google Public DNS keeps NS at most 6 hours.

So it is never a flat "24–48 hours". Keep the old DNS host answering the same records until the longer clock has run out, and on a signed domain remove the DS before the move (RFC 6781).

Where to change them, and the clocksTTLs measured 2026-10-23

At the registrar: each one's own guide

How long the registry's copy lasts (parent NS TTL)

  • .ru4 days345,600 s
  • .com2 days172,800 s
  • .uk2 days172,800 s
  • .de1 day86,400 s
  • .jp1 day86,400 s
  • .tr12 hours43,200 s
  • .dev3 hours10,800 s
  • .org1 hour3,600 s
  • .io1 hour3,600 s
  • .in15 minutes900 s

The clocks after a change

  • Old referral in cachesthe parent TTL.com: up to 2 days
  • Old zone NS set in cachesthe old zone's TTLgoogle.com: up to 4 days
  • Google Public DNSits cap on NSat most 6 hours
Parent TTLs from each registry's own servers (dig +norec); .io answered 3,600 s, not the 300 s often quoted. Registrars still quote flat times: GoDaddy "up to 48 hours", Namecheap "up to 24 hours".

NS vs SOA vs glue records

Three records meet at a delegation. NS names the servers: the parent's copy points the way, the zone's copy is the authority. Glue is an A or AAAA record the parent keeps only for servers named inside the zone. SOA exists once per zone, at its top: the primary server, a contact address, the serial and the timers.

A server that answers the SOA with the aa flag holds the zone, which is why the tool asks every server for it. The serial tells you whether the servers have the same version; Route 53 starts at 1 and never changes it on its own, and a zone at two providers carries two serials, both normal.

Two zones, one cutgoogle.com · recorded 2026-10-23

The .com zonerun by Verisign

  • NSgoogle.com. 172800 NS ns1.google.com.Delegation: where to go next · not authoritative
  • Ans1.google.com. 172800 A 216.239.32.10Glue: the server's address, so it can be reached
  • DSno DS: google.com is unsignedDS: points to the child's signing key; signed zones only (cloudflare.com DS 2371 13 2)

zone cut · google.com

The google.com zonerun by Google

  • NSgoogle.com. 345600 NS ns1.google.com.The zone's own list · authoritative
  • SOAns1.google.com. dns-admin.google.com. 1003797344 900 900 1800 60One per zone: primary, contact, serial, timers
  • Ans1.google.com. 345600 A 216.239.32.10The server's own address: the glue should match it
Glue and the server's own A record are two copies of one fact; when they disagree, the glue is stale.

NS lookup vs the nslookup command

People search "ns lookup" for two things: the nameservers of a domain, and the nslookup command that ships with Windows, macOS and Linux. nslookup asks your resolver and prints what it has cached; with -type=ns it lists the zone's NS set as your resolver holds it.

That copy can be hours old, and it never shows the registry's list, the glue, or whether each server holds the zone. This page asks each of them it can reach directly.

Three ways to look up nameservers
This NS Lookupdnsrobot.netnslookup-type=nsdigNS · +norec
Asksthe registry, then every serveryour resolverany one server you name
Registry vs zoneboth, name by namethe cached copyone list per command
Each server's aaeach IPv4 address (A and glue)Noone server per command
Glue and TTLsboth TTLswith -debugin the output
Diagnosisnamed, with the fixNoNo
Runs onany browserWindowsmacOSLinuxmacOSLinux

NS lookup: frequently asked questions

What is an NS lookup?

An NS lookup asks DNS which nameservers hold a domain's zone. This tool asks the registry first, for the parent's list with its glue and TTL, then each nameserver's IPv4 addresses directly over TCP for the zone's SOA and its own NS set, and compares the two. You see who hosts the DNS, which servers answer with authority, and anything that would make resolvers fail or slow down.

How do I find out who my DNS provider is?

Look at the nameserver names: ns1.google.com is Google, *.ns.cloudflare.com is Cloudflare, ns-*.awsdns-* is Amazon Route 53, 01.dnsv.jp is Onamae.com. This lookup names the DNS host from each provider's documented name pattern and shows the network behind each address separately, because some hosts run on another company's network: Porkbun and Hostinger on Cloudflare's, Vercel on NS1's.

Why do the registry and the zone list different nameservers?

The registry's list, set at your registrar, and the zone's own NS records, set at your DNS host, are two separate copies, and RFC 1034 says they should be exactly the same. They drift apart when someone changes one and not the other, often after a move between DNS hosts. Resolvers that start at the registry use its list, while those that asked the zone keep the zone's.

What is a lame delegation?

A lame delegation is a nameserver the registry lists that doesn't serve the zone: it answers REFUSED or SERVFAIL, answers without authority, or doesn't answer at all. If every listed server is lame, the domain stops resolving and Google and Cloudflare answer SERVFAIL. Fix it by adding the zone at that DNS host, or by changing the nameservers at the registrar to the host that has the zone.

How long do nameserver changes take to propagate?

Up to the longer of two clocks: the registry's NS TTL (2 days for .com and .net, 4 days for .ru, 1 day for .de and .jp, 1 hour for .org and .io, 15 minutes for .in) and the old zone's own NS TTL, which resolvers that already asked the old host keep. Google Public DNS caps it at about 6 hours. A flat "24–48 hours" is wrong both ways.

How many nameservers should a domain have?

At least two: RFC 2182 requires two, recommends three for most organisations with at least one well removed from the others, and four or five for higher reliability. What matters more than the number is that one failure can't reach them all: different networks or providers. Anycast servers run by one operator, such as Cloudflare or Route 53, are many sites, but still one operator.

What are glue records, and when do I need them?

Glue is the address the registry hands out with its referral for a nameserver named inside the zone, like ns1.example.com for example.com: without it, a resolver would need the server's address to find the server. RFC 9471 makes glue required for such in-domain names. Set it at your registrar, where it is called host records, child nameservers or personal DNS servers.

Why do different tools show different nameservers?

Most nameserver checkers ask a resolver, which shows a cached copy that can be days old after a change, while the registry and the zone answer for themselves. Some tools show only the zone's own list. This lookup shows the registry's list, every server's own answer, and Google's and Cloudflare's cached copies side by side, with the time each copy has left.

What does "not probed directly" mean?

Our server runs on Cloudflare's network, and a Cloudflare Worker can't open a connection to an address on that network. Nameservers there, Cloudflare's own and those of hosts that run on it such as Porkbun, Hostinger and DigitalOcean, are read through Cloudflare's resolver 1.1.1.1 instead: the NS set and its TTL, but not each server's AA bit, serial or response time.

Is an NS lookup the same as nslookup?

No. nslookup is a command-line tool on Windows, macOS and Linux that asks a resolver for any record type, NS included (nslookup -type=ns example.com). An NS lookup is the question itself: which nameservers serve a domain. Like dig NS, nslookup shows your resolver's cached copy; asking the registry and each server directly, as this tool does, shows whether they agree.

Why doesn't my nameserver change show yet?

Check three places: whether the registry lists the new servers (if not, the change hasn't left your registrar yet), whether the new zone answers with authority, and how long the old copies last in resolvers. The "I changed my nameservers" mode takes your new servers, compares each copy with them and counts down to when every resolver has them.

Should I remove DNSSEC before changing nameservers?

Yes, unless the old and new DNS hosts cooperate. If the registry keeps a DS record that the new host's keys don't match, validating resolvers such as Google and Cloudflare answer SERVFAIL and the domain goes dark for their users. Remove the DS at the registrar, wait out its TTL, change the nameservers, then publish the new host's DS.

Missing something?Suggest a feature or a new tool