Knowing which nameservers a domain is pointing to is one of the most fundamental DNS checks you will ever perform. Whether you just transferred a domain, switched hosting providers, or are troubleshooting why a site is not loading, the nameserver records are always the first place to look. They are the authoritative source that tells the entire internet where to find the DNS records for a domain, and if they are wrong, nothing else matters. This guide covers every practical method to check nameservers for any domain, from a simple online tool to command-line queries on Windows, Mac, and Linux, along with how to interpret the results and what to do when something looks off.
What Nameservers Actually Are
A nameserver is a server that holds the DNS zone file for a domain. When someone types your domain into a browser, their resolver starts a chain of queries that eventually reaches your nameservers and asks them for the IP address tied to that hostname. Every registered domain must have at least two nameservers assigned to it, typically a primary and a secondary, though many registrars and DNS providers assign three or four for redundancy.
Nameservers are stored as NS records in the DNS hierarchy. There are two distinct layers where these records live:
- The registry (TLD) layer: The .com, .net, .org, or country-code registry stores the delegation record that says which nameservers are authoritative for your domain. This is what your registrar controls when you update nameservers in your domain account.
- The zone itself: Your nameservers also publish their own NS records inside the zone file. These should match the delegation at the registry level. When they do not match, you get a condition called a lame delegation, which causes intermittent resolution failures.
Checking Nameservers with an Online Tool
The fastest way to check nameservers without opening a terminal is to use a dedicated lookup tool. Our DNS Lookup tool lets you query NS records for any domain from multiple locations around the world simultaneously. Just enter the domain, select NS as the record type, and hit search. You will see the nameservers as returned by the authoritative source, not just what is cached locally on your machine.
Online tools are particularly useful when you need to verify that a nameserver change has propagated across different regions. A change made at the registrar updates the registry delegation, but resolvers around the world cache the old answer until the TTL on the old NS record expires. Checking from multiple geographic vantage points tells you whether the update is spreading correctly.
Checking Nameservers from the Command Line
Command-line tools give you more control and are essential when you need to bypass local caching, query a specific nameserver, or script a check for multiple domains at once. Here are the exact commands for every major platform.
Using nslookup on Windows
nslookup is built into every version of Windows and requires no installation. Open Command Prompt and run:
The output will show the non-authoritative answer (from your local resolver cache) along with the authoritative nameservers. To bypass your local DNS cache and query a public resolver directly, specify a server:
To go all the way to the root and get the authoritative delegation from the TLD registry itself, first find one of the .com root nameservers and query it directly:
This bypasses all caching layers and returns exactly what the registry has on file. If this output differs from what your hosting provider says, the registrar update has not reached the registry yet, or was entered incorrectly.
Using dig on Mac and Linux
dig is the gold standard for DNS queries. It is pre-installed on macOS and all major Linux distributions. The basic NS lookup looks like this:
The ANSWER SECTION will list the nameservers. The AUTHORITY SECTION shows where the answer came from. To get a cleaner output, use the short flag:
To query a specific public resolver like Cloudflare's 1.1.1.1 instead of your local one:
To trace the full resolution path from root servers all the way to the authoritative answer, which is invaluable for diagnosing delegation mismatches:
The +trace output walks through root servers, then TLD servers, then the authoritative nameservers. Each hop is shown with the TTL and the responding server. If the chain breaks or returns unexpected nameservers at any step, that is exactly where the problem is.
Using host on Linux and Mac
The host command is simpler than dig and works well for quick checks:
Or query against a specific nameserver:
Using whois to Cross-Check the Registry
The WHOIS record for a domain also contains the nameserver delegation as recorded at the registry level. This is the ground truth for what is delegated, independent of DNS propagation:
On Windows, you can use a web-based WHOIS tool or install Sysinternals whois from Microsoft. The nameservers listed in WHOIS output should exactly match what dig or nslookup return when you query the TLD root servers directly. Any mismatch means the registrar update has not propagated to the registry yet, or there was a typo when entering the nameservers.
Reading and Interpreting the Results
Once you have the NS record output, here is how to make sense of it.
Recognizing Common Nameserver Formats
Most DNS providers use a predictable format for their nameservers. Knowing what to expect helps you immediately spot if something is wrong:
- Cloudflare: ns1.cloudflare.com, ns2.cloudflare.com (or a custom pair like ada.ns.cloudflare.com)
- AWS Route 53: ns-XXXX.awsdns-XX.com / .net / .org / .co.uk (always four nameservers, one from each TLD)
- GoDaddy: ns1.domaincontrol.com, ns2.domaincontrol.com
- Google Domains / Squarespace: ns-cloud-aX.googledomains.com (a through d)
- Namecheap BasicDNS: dns1.registrar-servers.com, dns2.registrar-servers.com
If you see nameservers that do not match your expected provider, that is a serious problem. It could mean your domain was transferred without your knowledge, or a previous hosting setup was never cleaned up.
Checking TTL Values
The dig output includes a TTL (time to live) in seconds for each record. A TTL of 86400 means resolvers around the world can cache the answer for up to 24 hours before checking again. This is why nameserver changes can take time to propagate globally. Most registrars set a 24-to-48 hour TTL on NS delegations, and you cannot control this TTL yourself since it is set by the registry, not by your DNS provider.
Verifying Glue Records
If your nameservers are hosted on your own domain (for example, ns1.yourdomain.com for yourdomain.com), the registry must also store glue records, which are A records for those nameservers. Without them, resolution becomes circular. You can check for glue records with:
The ADDITIONAL SECTION should show the A records for your nameservers. If it is empty and your nameservers are on your own domain, you have a glue record problem that needs to be fixed at your registrar.
Common Nameserver Problems and How to Fix Them
Nameservers Not Updated After Domain Transfer
After a domain transfer between registrars, the receiving registrar sometimes resets the nameservers to their own default servers. Always verify nameservers immediately after a transfer completes. Log into the new registrar's control panel and set the nameservers back to your DNS provider's values if they were changed.
Lame Delegation
A lame delegation happens when the nameservers listed at the registry level do not actually host the DNS zone. The server answers but claims it is not authoritative. This causes intermittent resolution failures because resolvers may retry and get different answers from different nameservers. To detect this:
The response should show AA (Authoritative Answer) in the flags. If the nameserver returns a SERVFAIL or a non-authoritative response, it is not actually hosting the zone. Contact your DNS provider to confirm the zone has been created on their system, and verify that the nameservers you entered at the registrar exactly match the ones the provider gave you, including any typos.
Propagation Not Complete
If you changed nameservers and the site is still not loading for some users but works for others, propagation is still in progress. The old TTL is still being honored by resolvers that cached the previous NS record. There is nothing to do except wait. Running a propagation check from multiple geographic locations will show you which regions have the new records and which do not.
Wrong Nameservers Showing Up
If your dig query shows nameservers that are not the ones you set, the most likely causes are:
- You updated the nameservers in your hosting account but forgot to do it at the registrar. These are two different systems and both must be correct.
- The registrar change did not save properly. Log back in and confirm the nameservers are actually showing the new values in the registrar's dashboard.
- There is a registry lock on the domain that is preventing changes. Check whether your domain has a Registry Lock or Registrar Lock status in the WHOIS output.
How to Monitor Nameservers on an Ongoing Basis
For production domains, especially e-commerce sites or business-critical applications, it is worth setting up automated nameserver monitoring. A sudden nameserver change you did not make is a serious security incident. Many DNS monitoring services will alert you by email or SMS if the NS records for your domain change unexpectedly. Even a simple daily cron job using dig can catch this:
This kind of check catches domain hijacking attempts early. If an attacker gains access to your registrar account and changes your nameservers, your monitoring will flag it within 24 hours at most.
Quick Reference Summary
- Fastest online check: Use our DNS Lookup tool, select NS record type
- Windows command: nslookup -type=NS example.com 8.8.8.8
- Mac / Linux quick: dig NS example.com +short
- Full trace: dig NS example.com +trace
- Registry-level check: dig NS example.com @a.gtld-servers.net
- WHOIS cross-check: whois example.com | grep -i "name server"
Checking nameservers takes thirty seconds once you know which tool to use. Make it the first step in any DNS troubleshooting workflow and you will save yourself hours of chasing symptoms that all trace back to a single misconfigured delegation.