A nameserver lookup asks DNS for the NS records of a domain. Each NS record names one nameserver: a DNS server that holds the domain's zone, the set of its DNS records, and answers for it with authority. So the nameservers tell you who hosts the domain's DNS. That is where its A, MX and TXT records live, and where a new record has to be added to have any effect.

Every zone has to be served by at least two nameservers (RFC 1034 §4.1), so a domain normally lists two or more. Their names are ordinary host names and need not be under the domain itself (RFC 1034 §4.2.2): example.com uses hera.ns.cloudflare.com and elliott.ns.cloudflare.com, two of Cloudflare's.

This tool asks our own recursive resolver, which runs on the same server as this site, for the NS records at exactly the name you enter, in one query. The answer is the resolver's copy of those records, with the time it may still keep them (the TTL). NS records exist only at the top of a zone: RFC 1034 §4.2.1 says they are “only found at nodes which are the top node of some zone”. So enter the domain itself, such as example.com; a name inside it, such as www.example.com, has none.

The lookup takes domain names only. An IP address is not a domain name; to find the name of an address, use the reverse DNS lookup. A top-level domain on its own, such as com, is not accepted either; the questions below show how to see its nameservers.

Who runs these nameservers?

The name of a nameserver can show who runs it, because only the owner of a domain can create names under it. These providers document the names of their nameservers, and the result names the provider when a nameserver matches:

The company that runs the nameservers is not always the one where you edit your records. Squarespace, for example, says its default nameservers may end in .googledomains.com or .nsone.net, and Netlify gives its customers nameservers like dns1.p01.nsone.net, so such a domain can show Google Cloud DNS or IBM NS1 Connect here while its records are edited at Squarespace or Netlify. A name that matches none of the names in the table says nothing about who runs it. Many DNS hosts are not in this list, and a domain can use nameservers under its own name, such as ns1.example.com, run by any provider; Cloudflare, for one, offers such custom nameservers. gmail.com uses Google's own names, ns1.google.com to ns4.google.com, which are not in the list. The addresses of a nameserver are its A and AAAA records: the A record lookup shows them.

1. Enter the domain in the form at the top of this page, such as example.com. A pasted web address or email address works too: we take the host name out of it. For a web address that is often www.example.com, which usually has no NS records of its own; the result then links to the lookup of example.com.
2. Select Check. The result lists the nameservers sorted by name, each with its TTL and, where the name shows it, the provider that runs it.
3. Compare the list with the nameservers your DNS host told you to use: each of them should be there, and no other.

From the command line

On macOS and Linux, dig asks for one record type; +short prints only the names:

dig example.com NS +short

On September 26, 2026 it printed:

elliott.ns.cloudflare.com.
hera.ns.cloudflare.com.

The dot at the end of a name is the root of DNS. nslookup takes the type as an option and a resolver address as its second parameter; on macOS the first command below printed one line per nameserver, such as example.com nameserver = hera.ns.cloudflare.com. In Windows PowerShell, Resolve-DnsName takes the type NS:

nslookup -type=NS example.com
nslookup -type=NS example.com 1.1.1.1
Resolve-DnsName -Name example.com -Type NS

These commands, like this page, ask a resolver, which should answer with the NS records in the domain's own zone. To see the list your registrar sent to the registry, ask the registry. whois prints it as Name Server lines, and dig at a server of the top-level domain shows the delegation that resolvers follow. For a .com domain:

whois -h whois.verisign-grs.com example.com
dig @a.gtld-servers.net example.com NS +norecurse

On September 26, 2026, whois listed Name Server: ELLIOTT.NS.CLOUDFLARE.COM and Name Server: HERA.NS.CLOUDFLARE.COM, and the .com server answered with the same two names. The two lists can differ, and why nameservers matter when you move a domain explains when. dig +trace example.com NS shows the whole path: a root server names the servers of .com, a .com server names Cloudflare's, and one of those answers.

The result opens with the verdict, a colored icon and a short label, together with the data that decided it. A nameserver lookup ends in Pass, Warning or Could not check. There is no Fail: the lookup reports what DNS publishes. It does not ask each nameserver whether it answers, and it does not compare the list with the one at your registrar; the commands in how to check a domain's nameservers show that list.

Pass: nameservers found

The resolver answered with NS records, no query failed, and none of the warnings below applies. Each nameserver is one row, sorted by name, because DNS servers do not list them in one fixed order: on September 26, 2026, 1.1.1.1 listed hera.ns.cloudflare.com first, and Cloudflare's own server listed elliott.ns.cloudflare.com first. The TTL is how long the resolver we asked may still keep the record; the DNS lookup explains TTLs. Our resolver keeps no record longer than one day, so the TTL here is at most 86,400 seconds, even when the zone sets more. Where a nameserver's name shows who runs it, the provider is in its own column (see who runs these nameservers).

Several nameservers, and several DNS hosts

Two is the minimum (RFC 1034 §4.1). RFC 2182, a best current practice, recommends three for most organizations' zones, and RFC 1912 gives seven as the recommended maximum. Nameservers of two DNS hosts can be listed together when both serve the same zone: github.com lists eight, four of IBM NS1 Connect and four of Amazon Route 53. On September 26, 2026, a server of each gave the same eight names, with different TTLs: 900 seconds at Route 53 and 3,600 at NS1. This lookup does not grade the count: one nameserver gets a Pass too, so count them yourself.

When the name is an alias (CNAME)

If the name you enter has a CNAME record, the resolver follows it and answers for the name at the end of the alias chain (RFC 1034 §3.6.2). The NS records shown are then those of that name, and the result says so: www.github.com is an alias for github.com, so its lookup shows the eight nameservers of github.com, with a Pass. When the alias leads to a name that is not the top of a zone, there are no NS records there, and you get the warning below: www.microsoft.com leads to e13678.dscb.akamaiedge.net, which had none on September 26, 2026. The alias itself usually lives in the zone of its domain; when the records shown are not that domain's, the result links to its lookup.

Warning: no nameservers at this name

The resolver answered, and there were no NS records. The result says which answer came back:

• NODATA (NOERROR with an empty answer) is what a name inside a zone gets, such as www.example.com, mail.example.com or _dmarc.example.com: NS records are only at the top of a zone. The result then links to the lookup of the registered domain the name belongs to, which is usually that top. Not always: the owner of example.com can hand blog.example.com to other nameservers, and then blog.example.com has NS records of its own. NODATA does not prove that the name exists, because some DNSSEC-signed zones give this answer for names that do not exist (RFC 9824). On September 26, 2026, a made-up name under example.com got NODATA when we asked 1.1.1.1.
• NXDOMAIN: the name does not exist. For a domain you registered, that means the registry of its top-level domain does not publish it. ICANN's list of domain status codes names statuses that do this: no nameservers are set (status inactive), or the registrar or the registry put the domain on hold (clientHold, serverHold); either way the domain “is not activated in the DNS”. A typo, or a domain nobody registered, gets the same answer. Your registrar shows the status, and whois prints it too.

An empty answer is cached as well: the result shows how much longer the resolver we asked may keep it.

Warning: the alias leads to a name that does not exist

The name is a CNAME, and the name at the end of its chain does not exist (NXDOMAIN). After an alias chain the error is about the last name of the chain, not the one you typed (RFC 6604 §3), so the fix belongs to whoever owns the last CNAME: point it at a name that exists, or delete it. The CNAME lookup follows a chain one step at a time.

Warning: a CNAME at the top of the zone

The domain itself, such as example.com, has a CNAME record. The top of a zone must hold its NS and SOA records (RFC 1034 §4.2.1), and a name with a CNAME may hold no other data (RFC 2181 §10.1); RFC 1912 §2.4 warns against exactly this mix. The NS records the resolver returns then come from wherever the alias leads, not from your zone. The DNS lookup explains the fix: address records at the top of the zone, or your DNS host's apex alias feature.

Could not check

The query got no usable answer: it timed out or a network error stopped it, the resolver reported a server failure (SERVFAIL), refused the query or returned another error, or the answer could not be decoded safely. That says nothing about whether the domain has nameservers, and we never count it as a pass or a warning. SERVFAIL and REFUSED cover many errors; RFC 8914 §1 names a failed DNSSEC validation and a lame delegation among them. The delegation does not depend on the domain's own nameservers, so a dig at a server of the top-level domain, as in how to check, still shows which nameservers resolvers are sent to. The DNS propagation checker asks several public resolvers, which shows whether the failure is everywhere.

Could not check: a fault on our side

Rarely, the result says the check could not be completed because of an internal error. That is a fault in our software, not a finding about your domain and not a network problem, so trying again will most likely give the same result. Please write to support@mxverdict.com with the address of the result page, and we will fix it.

Nameservers are set at your registrar, the company you registered the domain with. RFC 9499 defines a registrar as “a service provider that acts as a go-between for registrants and registries”: it sends your list to the registry of the top-level domain, which publishes it as the delegation. Your DNS host, where you edit records, can be the same company or another one. The order of the steps matters:

1. Set up the zone at the new DNS host first and copy every record to it. Records do not move by themselves; Namecheap, for one, warns that after a switch “the host records will not be added to the new nameservers automatically”.
2. Copy the nameserver names exactly as the new host gives them. Cloudflare warns that if they are not copied exactly, your DNS will not resolve correctly. Enter names only: Namecheap asks for the names and not the IP addresses, even when a host gives you both.
3. If DNSSEC is on, turn it off at the registrar first, and wait before you switch. Cloudflare: “Changing nameservers while DNSSEC is active can cause your domain to become unreachable.” Turning it off removes the DS record from the zone above yours, but resolvers that cached the DS record keep it until its TTL runs out; on September 26, 2026, the .com zone gave the DS record of example.com a TTL of 86,400 seconds, one day. Cloudflare's rule of thumb is to “wait at least one full DS TTL and preferably up to 1.5 times the TTL before changing nameservers.” Turn DNSSEC on again at the new host once the domain is served there.
4. Replace the list at the registrar: remove the old nameservers and add all of the new ones, as Cloudflare's steps put it.
5. Keep the old zone unchanged for a while. Resolvers that cached the old NS records may keep asking the old nameservers until their copy runs out; the DNS propagation checker shows how long that can be, with the TTLs we measured for .com.
6. Check. A dig at a server of the top-level domain, as in how to check, shows what the registry publishes, with no cache in between. This page shows what a resolver hands out; it reuses a result for 60 seconds, so wait that long before you look up the same domain again.

GoDaddy

1. Sign in to your GoDaddy Domain Portfolio and select the domain to open its Domain Settings page.
2. Select DNS, then Nameservers.
3. Choose GoDaddy Nameservers (recommended) to manage DNS in your GoDaddy account, or I'll use my own nameservers and enter the names your DNS host gave you.
4. Select Save, then Continue. A domain with Domain Protection also asks for a verification code.

Namecheap

1. Sign in, select Domain List in the left sidebar and Manage next to your domain.
2. In the Nameservers section, choose from the drop-down menu: Namecheap BasicDNS (its nameservers are dns1.registrar-servers.com and dns2.registrar-servers.com), Namecheap Web Hosting DNS, CustomDNS for the nameservers of another host, or Namecheap PremiumDNS.
3. For CustomDNS, enter each nameserver as a name, such as ns1.example.tld, and click the green checkmark to save.

Cloudflare and Cloudflare Registrar

As a DNS host, Cloudflare assigns two nameservers to your domain when you add it, shows them on the zone's Overview page, and says their names “cannot be changed”. You then enter them at your registrar.

A domain registered with Cloudflare Registrar already uses Cloudflare's nameservers and cannot use others: “No, all domains on Cloudflare Registrar use Cloudflare nameservers”. To use another DNS host, you have to move the domain to another registrar. To give only a subdomain to another provider, delegate it, as below.

Porkbun

1. Log in; you arrive at the Domain Management screen.
2. Open the Details drop-down next to the domain, find the Nameservers field and click its edit icon.
3. Remove all of the existing entries, add the new nameservers one per line, and click Save Nameservers; if asked to confirm, click Submit.

For nameservers under your own domain, such as ns1.yourdomain.com, Porkbun asks you to create a glue record first: the address of that nameserver, kept in the zone above yours, so resolvers can reach it before they can ask your zone (RFC 1034 §4.2.1).

Nameservers for a subdomain

To hand one subdomain, such as blog.example.com, to other nameservers, add NS records for it in your zone. At Cloudflare, on the DNS Records page, create one NS record per nameserver, with the subdomain as the name and the nameserver as the content, as in Cloudflare's example:

These records mark the cut between your zone and the subdomain's, and RFC 1034 §4.2.1 says they “should be exactly the same” as the NS records at the top of the subdomain's own zone, at the other host. Address records are needed only as glue, when the nameservers are themselves inside the subdomain.

Your nameservers are written down in two places, and each copy has its own job:

• The delegation, in the zone above yours: for example.com, the .com zone. Your registrar sends it to the registry, which publishes it there, and it is how resolvers find your nameservers at all. RFC 9499: “Delegation happens when an NS RRset is added in the parent zone for the child origin.”
• The NS records in your own zone, at your DNS host. RFC 2181 §6.1 calls the NS records at a zone cut “the property of the child zone”, and they are what a nameserver lookup should return.

We asked both on September 26, 2026. A .com server answered for example.com with a referral: no answer section, the two Cloudflare names in the authority section with a TTL of 172,800 seconds, and no aa (authoritative answer) flag: RFC 2181 §6.1 says a server of the zone above should not answer with authority for the NS records at a cut. Cloudflare's hera.ns.cloudflare.com answered with the same two names, the aa flag set, and a TTL of 86,400 seconds.

A resolver follows the delegation to your nameservers, then asks them. What it should hand out as an answer is their copy: RFC 2181 §5.4.1 ranks the answer of an authoritative server above a referral, and says that data from the authority section of a non-authoritative answer, where a referral carries it, “should not be cached in such a way that they would ever be returned as answers”. That day 1.1.1.1 did so: it answered our lookup of gmail.com with 342,400 seconds left on the NS records, more than the 172,800 of the .com copy and close to the 345,600 that Google's own servers give. Our own resolver keeps no record longer than one day, so for gmail.com it cannot show that difference. For github.com it can: its own servers set 900 and 3,600 seconds, while the 172,800 of the .com copy would start at 86,400 here. On September 27, 2026, our resolver gave the NS records of github.com a TTL of 295 seconds, which points to the zone's copy. A nameserver lookup like this one should therefore show the NS records in your zone, and the list at your registrar is what the whois and dig @a.gtld-servers.net commands in how to check show.

The two copies should match. RFC 1034 §4.2.2 asks the administrators of both zones to keep the NS records on both sides of the cut “consistent”, and RFC 1912 §2.8 says: “Make sure your parent domain has the same NS records for your zone as you do.” During a move they drift apart for a while: the registry already points to the new host, while resolvers that cached the old NS records may still ask the old one. A nameserver that is listed but does not serve the zone is a “lame delegation”, and RFC 1912 §2.8 warns that at worst “you can get unresolved hosts and bounced e-mail”. Hence the order in how to change nameservers: the new zone first, and the old zone kept until the old records have run out. The DNS propagation checker explains how long that can take.

Moving the registration to another registrar is a separate step from moving DNS, and registrars set their own rules for it. Cloudflare Registrar, for one, takes a transfer only for a domain that already uses Cloudflare's DNS: it “only supports transfers of domains that are active on a Cloudflare full setup”.