<p><strong>Short answer:</strong> the fastest way to see which nameservers a domain is using is to run <code>dig NS yourdomain.com +short</code> on macOS or Linux, <code>nslookup -type=NS yourdomain.com</code> on Windows, or paste the domain into our free <a href="/nameserver-lookup">Nameserver Lookup tool</a>. If you need the answer straight from the registry (for example, right after you changed nameservers at your registrar), query the TLD servers directly or check the WHOIS/RDAP record. The four methods below cover every situation, and the section on conflicting results explains why two tools can show different nameservers for the same domain.</p>

<h2>Two places nameservers are listed (and why it matters)</h2>
<p>Nameservers for a domain are published in two places, and most confusion comes from mixing them up:</p>
<ul>
<li><strong>The delegation at the registry (parent zone).</strong> When you set nameservers at your registrar, the registrar sends them to the registry for the TLD, such as Verisign for .com. The registry's servers then tell the rest of the internet where your domain's DNS lives. This is the list that actually controls where traffic goes.</li>
<li><strong>The NS records inside your own zone (child zone).</strong> Your DNS provider also publishes NS records in the zone it hosts. Normally they match the delegation exactly, but they do not have to. RFC 1034 expects the two sets to agree, and when they drift apart you get hard-to-debug problems.</li>
</ul>
<p>A normal lookup through a public resolver usually shows you the child zone's NS records (or a cached copy). A WHOIS check or a direct query to the TLD servers shows you the delegation. When you troubleshoot, check both.</p>

<h2>Method 1: Use an online nameserver checker</h2>
<p>If you only need a quick answer, use a web tool. Open the <a href="/nameserver-lookup">Nameserver Lookup</a> page, type the bare domain (for example <code>yourdomain.com</code>, without <code>https://</code> or <code>www</code>) and run the check. You will get the list of NS hostnames the domain currently resolves to.</p>
<p>This is the right method for support staff and site owners who are not comfortable with a terminal. Two tips:</p>
<ul>
<li>Always check the <strong>root domain</strong>. Subdomains such as <code>shop.yourdomain.com</code> usually have no NS records of their own unless they are delegated separately.</li>
<li>If the result looks wrong right after a change, it may be cached. Compare it with Method 4, which skips caches.</li>
</ul>

<h2>Method 2: Check nameservers from the command line</h2>
<h3>macOS and Linux: dig</h3>
<p><code>dig</code> is installed on macOS by default and is part of the <code>dnsutils</code> or <code>bind-utils</code> package on most Linux distributions.</p>
<pre><code>dig NS yourdomain.com +short</code></pre>
<p>The output is one nameserver per line, each ending in a dot, for example:</p>
<pre><code>ns1.exampledns.net.
ns2.exampledns.net.</code></pre>
<p>Drop <code>+short</code> to see the full answer, including the TTL (how many seconds resolvers may cache the result). To ask a specific public resolver instead of your local one, add it with <code>@</code>:</p>
<pre><code>dig NS yourdomain.com @1.1.1.1 +short
dig NS yourdomain.com @8.8.8.8 +short</code></pre>
<h3>Windows: nslookup or PowerShell</h3>
<p>In Command Prompt:</p>
<pre><code>nslookup -type=NS yourdomain.com</code></pre>
<p>Look for lines that read <code>nameserver = ...</code>. The "Non-authoritative answer" label only means the reply came from a resolver's cache rather than from the domain's own nameservers. That is normal.</p>
<p>In PowerShell, the built-in <code>Resolve-DnsName</code> cmdlet gives cleaner output:</p>
<pre><code>Resolve-DnsName -Name yourdomain.com -Type NS</code></pre>
<p>The <code>NameHost</code> column lists the nameservers.</p>

<h2>Method 3: Look up the WHOIS or RDAP record</h2>
<p>The registration record shows the nameservers your registrar has on file with the registry, which is the delegation described above. Use our <a href="/whois-lookup">WHOIS Lookup</a>, ICANN's official lookup service at lookup.icann.org (RDAP), or the terminal:</p>
<pre><code>whois yourdomain.com | grep -i "name server"</code></pre>
<p>You should see lines such as <code>Name Server: NS1.EXAMPLEDNS.NET</code>. Uppercase is normal, because DNS names are not case-sensitive. WHOIS is especially useful when the domain does not resolve at all, because it still shows which nameservers the registry has been told to use. Some country-code TLDs publish limited WHOIS data. If the nameserver lines are missing, use Method 4.</p>

<h2>Method 4: Ask the TLD servers directly (no caching)</h2>
<p>This is the method professionals use right after a nameserver change, because it reads the delegation straight from the registry instead of from any resolver cache. For .com and .net domains, Verisign's servers are named <code>a.gtld-servers.net</code> through <code>m.gtld-servers.net</code>:</p>
<pre><code>dig NS yourdomain.com @a.gtld-servers.net +norecurse</code></pre>
<p>The nameservers appear in the <strong>AUTHORITY SECTION</strong> of the output (not the ANSWER section), because the TLD server is referring you onward rather than answering for your zone. For any other TLD, first find its servers, then query one of them:</p>
<pre><code>dig NS org +short
dig NS yourdomain.org @&lt;one of the servers listed&gt; +norecurse</code></pre>
<p>Or let <code>dig</code> walk the entire chain from the root servers down, which shows every referral on the way:</p>
<pre><code>dig +trace NS yourdomain.com</code></pre>

<h2>How to read the result: which DNS provider is it?</h2>
<p>Nameserver hostnames usually reveal who hosts the DNS zone, which tells you where to edit records:</p>
<ul>
<li><strong>Cloudflare:</strong> two names in the form <code>name.ns.cloudflare.com</code></li>
<li><strong>Amazon Route 53:</strong> four names like <code>ns-123.awsdns-45.com</code> spread across .com, .net, .org and .co.uk</li>
<li><strong>Google Cloud DNS:</strong> names like <code>ns-cloud-a1.googledomains.com</code></li>
<li><strong>GoDaddy:</strong> names like <code>ns01.domaincontrol.com</code></li>
<li><strong>Namecheap (default DNS):</strong> <code>dns1.registrar-servers.com</code> and <code>dns2.registrar-servers.com</code></li>
</ul>
<p>If you see your web host's own hostnames, such as <code>ns1.yourhost.com</code>, then DNS records are managed in that host's control panel. Edits made at your registrar will have no effect until the nameservers point back there. Our <a href="/blog/how-to-change-nameservers-step-by-step">step-by-step guide to changing nameservers</a> covers the switch itself.</p>

<h2>Why different tools show different nameservers</h2>
<p>If two checks disagree, it is almost always one of these four causes:</p>
<ol>
<li><strong>A recent change is still cached.</strong> The .com registry publishes NS delegations with a TTL of 172,800 seconds (48 hours), so some resolvers can keep showing the old nameservers for up to two days. Method 4 shows the new value immediately. See <a href="/blog/dns-propagation-explained">DNS propagation explained</a> for what is happening in between.</li>
<li><strong>The registrar and the zone disagree.</strong> WHOIS shows one set and <code>dig NS</code> shows another. Fix the registrar setting if it is wrong, or update the NS records inside the zone so they match the delegation.</li>
<li><strong>One listed nameserver is not authoritative (a "lame delegation").</strong> Test each server on its own with <code>dig yourdomain.com SOA @ns1.exampledns.net</code>. A server that returns REFUSED or SERVFAIL, or does not answer, has not been set up for your zone.</li>
<li><strong>DNSSEC is broken after a move.</strong> If you changed DNS providers but left the old DS record at the registrar, validating resolvers return SERVFAIL even though the nameservers look right. Remove or update the DS record. Our <a href="/blog/dns-security-dnssec-explained">DNSSEC explainer</a> shows how the chain of trust works.</li>
</ol>

<h2>A 60-second troubleshooting checklist</h2>
<ol>
<li>Run <code>whois yourdomain.com | grep -i "name server"</code> and note the delegated nameservers.</li>
<li>Run <code>dig NS yourdomain.com @a.gtld-servers.net +norecurse</code> (or the matching TLD server) and confirm the registry list matches.</li>
<li>Run <code>dig NS yourdomain.com @1.1.1.1 +short</code> and compare it with what resolvers see.</li>
<li>Query each nameserver directly for the SOA record to confirm that it answers authoritatively.</li>
<li>Then check the records you actually care about, such as A, MX or TXT, with the <a href="/dns-lookup">DNS Lookup tool</a>. For common error messages, see <a href="/blog/common-dns-errors-and-fixes">common DNS errors and how to fix them</a>.</li>
</ol>

<h2>FAQ</h2>
<h3>Can I find a domain's nameservers without access to the account?</h3>
<p>Yes. Nameservers are public by design. Anyone can see them with any of the methods above, and no login is needed. What you cannot see publicly is which registrar account controls the domain.</p>
<h3>How many nameservers should a domain have?</h3>
<p>At least two, and ideally on separate networks, so the domain keeps resolving if one server fails. Most managed DNS providers assign two to four.</p>
<h3>Do subdomains have their own nameservers?</h3>
<p>Only if they have been delegated on purpose with NS records in the parent zone. Otherwise a subdomain uses the root domain's nameservers, and checking <code>NS</code> for it returns nothing useful. New to the basics? Start with <a href="/blog/what-are-nameservers-and-how-they-work">what nameservers are and how they work</a>.</p>

<p><em>Sources: RFC 1034 (Domain Names: Concepts and Facilities), ICANN Registration Data Lookup (lookup.icann.org), Microsoft Learn documentation for Resolve-DnsName, and the providers' own published nameserver naming. Command output above uses placeholder names. Run the commands against your own domain to see real values.</em></p>

How to check what nameservers a domain is using: dig, nslookup, PowerShell, WHOIS/RDAP and direct TLD queries, plus how to read and fix conflicting results.

How to Check What Nameservers a Domain Is Using

<p>Every time you type a website address into your browser, a remarkable process kicks off behind the scenes. That process starts with <strong>nameservers</strong> — the fundamental building blocks of the Domain Name System (DNS).</p>

<h2>What Is a Nameserver?</h2>
<p>A nameserver is a specialized server that stores DNS records for a domain and responds to queries about those records. Think of it as a phone book for the internet: when someone asks "where is example.com?", the nameserver answers with the correct IP address.</p>

<h2>How DNS Resolution Works</h2>
<p>When you visit a website, your browser doesn't immediately know where to find it. Here's the step-by-step process:</p>
<ol>
<li><strong>Browser cache check</strong> — Your browser first checks if it already knows the IP address from a recent visit.</li>
<li><strong>OS resolver</strong> — If not cached, the request goes to your operating system's DNS resolver.</li>
<li><strong>Recursive resolver</strong> — Your ISP's recursive resolver takes over. It starts the lookup process by querying the root nameservers.</li>
<li><strong>Root nameservers</strong> — These 13 root server clusters direct the query to the correct Top-Level Domain (TLD) nameserver (e.g., .com, .org).</li>
<li><strong>TLD nameservers</strong> — The TLD nameserver points to the authoritative nameserver for the specific domain.</li>
<li><strong>Authoritative nameserver</strong> — This server holds the actual DNS records and returns the IP address.</li>
</ol>

<h2>Types of Nameservers</h2>
<p>There are several types of nameservers, each playing a different role:</p>
<ul>
<li><strong>Root nameservers</strong> — The top of the DNS hierarchy. There are 13 root server addresses (labeled A through M), each operated by a different organization.</li>
<li><strong>TLD nameservers</strong> — Managed by domain registries, these handle queries for specific top-level domains like .com or .net.</li>
<li><strong>Authoritative nameservers</strong> — These are the nameservers you configure for your domain. They hold your DNS records (A, CNAME, MX, etc.).</li>
<li><strong>Recursive resolvers</strong> — Operated by ISPs or services like Google (8.8.8.8) and Cloudflare (1.1.1.1), these do the heavy lifting of querying the chain on your behalf.</li>
</ul>

<h2>Why Nameservers Matter</h2>
<p>Your choice of nameservers directly impacts your website's performance and reliability. Premium DNS providers like Cloudflare and AWS Route 53 offer faster response times, better uptime, and advanced features like DDoS protection and geographic routing.</p>

<p>When you register a domain, your registrar assigns default nameservers. You can change these to point to a different DNS provider — which is exactly what many site owners do to get better performance or more control over their DNS records.</p>

<h2>How to Find Your Nameservers</h2>
<p>You can look up nameservers for any domain using our <strong>Nameserver Lookup Tool</strong> at the top of this site. You can also use command-line tools:</p>
<pre><code>nslookup -type=NS example.com
dig NS example.com</code></pre>

<p>Understanding nameservers is the first step to taking control of your domain's DNS configuration. Whether you're setting up a new website or troubleshooting connectivity issues, knowing how nameservers work gives you the foundation to manage your online presence effectively.</p>

Learn what nameservers are, how DNS resolution works step by step, the different types of nameservers, and why they matter for your website performance.

What Are Nameservers and How Do They Work?

<p>Changing your domain's nameservers is a straightforward process, but getting it wrong can take your website offline. This guide covers exactly how to do it safely, with instructions for the most popular registrars.</p>

<h2>Why Change Nameservers?</h2>
<p>Common reasons to change nameservers include:</p>
<ul>
<li>Moving to a better DNS provider (e.g., Cloudflare, AWS Route 53)</li>
<li>Switching web hosting providers</li>
<li>Setting up CDN services that require their own nameservers</li>
<li>Improving DNS performance and reliability</li>
</ul>

<h2>Before You Start</h2>
<p>Take these precautions before making any changes:</p>
<ol>
<li><strong>Document your current DNS records</strong> — Export or screenshot all existing records (A, CNAME, MX, TXT). You'll need to recreate them at the new provider.</li>
<li><strong>Lower your TTL values</strong> — 24-48 hours before switching, lower your TTL to 300 seconds (5 minutes). This speeds up propagation when you make the change.</li>
<li><strong>Set up records at the new provider first</strong> — Create all your DNS records in the new DNS provider before pointing your nameservers there.</li>
<li><strong>Note your new nameserver addresses</strong> — Your new DNS provider will give you nameserver addresses like <code>ns1.provider.com</code> and <code>ns2.provider.com</code>.</li>
</ol>

<h2>Changing Nameservers at GoDaddy</h2>
<ol>
<li>Log in to your GoDaddy account and go to <strong>My Products</strong>.</li>
<li>Click <strong>DNS</strong> next to the domain you want to update.</li>
<li>Scroll down to <strong>Nameservers</strong> and click <strong>Change</strong>.</li>
<li>Select <strong>Custom</strong> and enter your new nameserver addresses.</li>
<li>Click <strong>Save</strong> to apply the changes.</li>
</ol>

<h2>Changing Nameservers at Namecheap</h2>
<ol>
<li>Log in to Namecheap and go to <strong>Domain List</strong>.</li>
<li>Click <strong>Manage</strong> next to your domain.</li>
<li>Under the <strong>Nameservers</strong> section, select <strong>Custom DNS</strong>.</li>
<li>Enter your new nameserver addresses and click the green checkmark.</li>
</ol>

<h2>Changing Nameservers at Google Domains / Squarespace</h2>
<ol>
<li>Sign in to your Google Domains account (now managed by Squarespace).</li>
<li>Select the domain and go to <strong>DNS</strong> settings.</li>
<li>Switch to <strong>Custom name servers</strong>.</li>
<li>Add your new nameserver addresses and save.</li>
</ol>

<h2>After Making the Change</h2>
<p>Once you've updated your nameservers:</p>
<ul>
<li><strong>Wait for propagation</strong> — DNS changes can take up to 48 hours to propagate globally, though most complete within 1-4 hours.</li>
<li><strong>Verify the change</strong> — Use our Nameserver Lookup Tool to confirm your domain is pointing to the new nameservers.</li>
<li><strong>Test your website</strong> — Check that your site, email, and other services are working correctly.</li>
<li><strong>Monitor for issues</strong> — Keep an eye on things for the first 24-48 hours.</li>
</ul>

<h2>Common Mistakes to Avoid</h2>
<ul>
<li><strong>Not recreating DNS records</strong> — If your records don't exist at the new provider, your site and email will go down.</li>
<li><strong>Typos in nameserver addresses</strong> — Double-check every character.</li>
<li><strong>Mixing nameservers from different providers</strong> — Use only nameservers from a single provider unless you know exactly what you're doing.</li>
</ul>

<p>Changing nameservers is a routine operation, but preparation is key. Follow these steps, and the transition should be seamless.</p>

Step-by-step guide to changing nameservers at GoDaddy, Namecheap, and Google Domains. Learn what to do before, during, and after the switch.

Free DNS & Network Tools

All Tools

Nameserver Lookup

DNS Lookup

WHOIS Lookup

IP Lookup

SSL Checker

HTTP Headers

Speed Test

Domain Availability

Blacklist Checker

Email Validator

Latest Posts

How to Check What Nameservers a Domain Is Using

What Are Nameservers and How Do They Work?

How to Change Nameservers: A Step-by-Step Guide

Stay in the loop