How to Look Up DNS Servers: Checking Domain NS Records and Resolving Servers

When you migrate a website, switch DNS providers, or modify domain resolution, one of the most common problems you'll run into is this: the backend looks like it's been updated, but the actual access results haven't changed. Some people still see the old IP, and in some regions, resolution fails outright. At this point, we need to first confirm which set of DNS servers is actually responsible for resolving this domain right now.

The most direct way to determine this is to query the domain's NS records. Through NS records, you can confirm the authoritative DNS servers currently used by the domain, and then continue troubleshooting by combining A, AAAA, CNAME, and other resolution results. This article will walk you through how to query DNS servers, how to read NS records, and where to start checking when you encounter resolution anomalies after changing DNS.

1. What Does DNS Server Lookup Mean?

When people talk about "looking up DNS servers," simply put, it means confirming which set of Name Servers (i.e., authoritative DNS servers) a domain is currently entrusted to for hosting and resolution.

For example, when you query a domain's NS records and get:

• ns1.example-dns.com

• ns2.example-dns.com

This means that all resolution rules for this domain are now determined by these two servers.

This step is crucial in day-to-day website maintenance. Suppose you've just moved your domain from an old DNS platform to a new one. If the NS records still show the old provider's addresses, then no matter how many A records, AAAA records, or CNAMEs you configure on the new platform, they're effectively useless to visitors.

So when troubleshooting a website that won't open or resolution that hasn't taken effect, the first step is always to check NS. It helps us confirm the most fundamental layer:

This domain → Who's actually managing it? → The corresponding NS servers

Only after confirming this layer does it make sense to check specific resolution IPs and troubleshoot node responses.

2. How to Query the DNS Servers Currently Used by a Domain

Querying NS isn't complicated. Online tools, Windows' built-in nslookup, and dig commonly used on Linux or macOS can all get the job done.

1. Use an Online DNS Lookup Tool

If you're just doing a quick check on a domain, online lookup is usually the easiest.

Simply open Chahu's DNS lookup page, enter the domain, select NS records, and you can directly view the Name Servers corresponding to the current domain.

This method also lets you observe resolution results from different regions. If you've just changed DNS, besides checking whether the NS has changed, you can also see if there are obvious differences in resolution results across different nodes.

For example:

NS lookup results

ns1.provider.com
ns2.provider.com

If this is indeed your current DNS provider, then at least the domain's DNS delegation direction is basically correct.

Online lookup is well-suited for webmasters, ops engineers, or temporary troubleshooting—no need to memorize commands, just look at the results.

2. Use nslookup to Query NS

On Windows, you can open CMD or PowerShell and run:

nslookup -type=NS example.com

Normally it returns something like:

example.com nameserver = ns1.provider.com
example.com nameserver = ns2.provider.com

Here, ns1.provider.com and ns2.provider.com are the DNS servers currently used by the domain.

If you've just switched DNS providers, you can compare the results here with the NS settings in your domain registrar's backend.

If both match, it means the new NS is already queryable.

If it still shows the old servers, you need to continue verifying whether the Name Server settings in your domain registrar's backend were modified correctly.

3. Use dig to Query NS

In Linux and macOS environments, I prefer using dig.

Simply run:

dig example.com NS

If you only want to see the final result, add:

dig example.com NS +short

The output will be more concise:

ns1.provider.com.
ns2.provider.com.

Compared to full DNS query results, this method is especially suitable for quickly confirming NS.

If you're doing server migration, DNS switching, or batch domain checks, dig is much more convenient.

3. How to Read DNS Server Lookup Results

After querying NS, you don't actually need to analyze much—just focus on a few key points.

1. Is the Current NS Your Active DNS Provider?

This is the most important point.

Suppose you've migrated your domain to a new DNS platform, but the query result is still:

ns1.old-dns.com
ns2.old-dns.com

That means the original DNS is still in effect.

In this case, modifying resolution records on the new platform is pointless, because the old provider is still the one receiving DNS query requests.

So after DNS migration is complete, the first step isn't to repeatedly change A records—it's to confirm whether the NS has actually switched over.

2. NS Is Correct, but the IP Is Still Old

In this situation, you can't just focus on NS anymore.

Because correct NS only means the domain has been handed over to the new DNS servers for management—it doesn't mean all recursive DNS servers have immediately updated their resolution results.

For example:

NS
→ Already the new DNS provider

A record
→ Some regions still show the old IP

This situation is more commonly caused by caching.

Local computers, routers, ISP DNS, or public DNS may all temporarily retain old records. As long as the cache hasn't expired, it's not uncommon to see different results across regions in a short period.

At this point, what's more worth looking at is the TTL and whether resolution results across different regions are gradually updating—rather than immediately modifying DNS configuration again.

3. Different IPs Queried from Different Regions

Different IPs returned from different regions don't necessarily mean there's a DNS problem.

If the website uses a CDN, intelligent DNS, or region-based scheduling, different users may naturally be assigned to different nodes.

For example:

Beijing
→ 203.0.113.10

Guangzhou
→ 203.0.113.20

Singapore
→ 203.0.113.30

As long as these addresses all belong to normal business nodes, this difference is reasonable.

What's truly worth noting is:

Resolution failure in some regions

Some nodes consistently returning old IPs

SERVFAIL appearing

Unable to get resolution results for an extended period

These situations are more worth further investigation.

4. Why Haven't Query Results Changed After Switching DNS Servers?

DNS switching doesn't mean everything updates simultaneously after the change. Often, the domain registrar's backend has already been switched to new NS, but some regions can still see old results when querying.

This is usually related to DNS caching.

You can simply understand it as:

Old DNS results
   ↓
Cache still valid
   ↓
Some users continue using old records
   ↓
Cache expires
   ↓
Re-query the new DNS

So after just changing DNS, if you see:

Some nodes → New results
Some nodes → Old results

It doesn't necessarily mean the operation failed. At this point, you can check three things first: First, whether the NS configured in the registrar's backend is correct; second, whether online lookup or nslookup can already find the new NS; third, whether resolution results across different regions are gradually updating over time.

If the NS is already correct and only a few regions are still returning old IPs, it's usually better to continue observing cache updates rather than repeatedly modifying resolution; if after a longer period the query results still show old NS, then you should re-check the domain registrar's Name Server settings rather than continue waiting.

5. What to Do When DNS Servers Are Fine but the Website Still Won't Open

This is an easily confused point in DNS troubleshooting.

Normal NS doesn't guarantee a normal website.

NS only indicates which set of DNS servers is currently responsible for resolving the domain.

Actually accessing the website still goes through:

NS → A / AAAA / CNAME → Target IP → Network connection → Port 80 / 443 → Web service

For example, NS may be completely correct, but if the A record still points to the old server, the website may still not open.

Or the IPv4 A record is fine, but the AAAA configuration is wrong, so some IPv6-capable users may experience anomalies when accessing.

Another example: the IP returned by DNS is fine, but port 443 on the server isn't open—continuing to check DNS won't solve the problem.

So after confirming NS is normal, I typically continue checking:

Is the A record correct

Is the AAAA record correct

Does the CNAME point to the expected target

Are abnormal IPs returned from different regions

Can the target IP be connected normally

If you need to observe DNS results from different regions, you can continue using Chahu's DNS lookup for multi-node comparison; if resolution is already normal, then use Ping, TCPing, or website speed test to continue troubleshooting further. This makes it easier to find the real problem than staying stuck at the DNS layer.

Conclusion

The most direct way to query DNS servers is to check the domain's NS records. Online DNS lookup, nslookup, and dig can all quickly confirm which set of DNS servers a domain currently uses. If you've just switched DNS providers, first check whether the NS has switched; if the NS is normal but resolution results are still inconsistent, then continue looking at TTL, A, AAAA, CNAME, and caching situations across different regions.

The most important thing in DNS troubleshooting isn't actually querying all records at once—it's first figuring out which layer the problem is at. Confirm NS first, then look at resolution results, and finally check server connectivity. This is usually more effective than repeatedly modifying DNS configuration.

Related Q&A

1. How many NS records should generally be configured? Is one enough?

Technically one can work, but nobody actually does that. Usually at least two, preferably spread across different networks or different top-level domains. RFC requires at least two, but many registrars allow you to enter just one. With only one, if that machine goes down, the entire domain goes down. Don't use the same IP range for two—otherwise a data center power outage takes them both out. I usually configure two to four, depending on how many the DNS provider offers.

2. How do I check if NS records are misconfigured? For example, pointing to a non-existent host.

After getting the NS hostname, directly run dig ns1.provider.com A to see if it resolves to an IP. If resolution fails, that NS is dead, and domain resolution will definitely have problems. Then run dig @ns1.provider.com yourdomain A to see if it responds normally. If it can't connect or returns REFUSED, the NS configuration has issues. When entering NS in the registrar's backend, don't include spaces and don't miss the trailing dot.

3. How do I use dig +trace? Can it trace the entire DNS resolution process?

Yes. dig +trace example.com starts from the root servers, queries all the way through top-level domains and authoritative NS, and finally gets the A record. It's especially useful for troubleshooting NS delegation issues. If a step in the middle breaks, you can see which part wasn't configured properly. The output is fairly long; adding +short makes it more concise. Note that local recursive DNS isn't involved—it directly simulates iterative queries.

4. Can subdomains be delegated separately to other DNS servers? How do I check their NS?

Yes, this is called subdomain delegation. For example, sub.example.com can have its own NS. The query method is the same: dig sub.example.com NS. If NS is returned, the subdomain has been delegated; if not, it may inherit the parent domain's NS. Note that some recursive DNS servers cache parent domain results, so not finding it doesn't mean it's not configured. Using dig @parentNS sub.example.com NS is more accurate.