How Do You Test Website DNS Resolution Speed? DNS Response Time Testing and Troubleshooting

When a website feels slow, many people first check the server—CPU, bandwidth, or CDN. But when someone actually visits a site, the browser doesn't connect straight to the server. It first has to resolve DNS, turning the domain name into an IP address. If that step takes only a dozen milliseconds or so, users usually won't notice. But if a DNS query takes one or two hundred milliseconds, or occasionally times out, even a fast server can still make the first visit feel noticeably slow.

The trickier part is that slow DNS doesn't necessarily mean slow everywhere. For the same domain, Beijing Telecom might return a result in a few dozen milliseconds, while Guangzhou Mobile or some overseas network takes much longer. So when troubleshooting DNS speed, don't just run one query from your own computer. What matters more is how long resolution takes, whether there are clear differences between regions, and whether certain ISPs consistently show problems.

1. What is website DNS resolution speed testing?

A user types a website address into the browser, for example:

www.example.com

The browser first needs to know which server this domain maps to before it can establish a connection. A simplified website visit looks roughly like this:

Enter domain
↓
DNS query
↓
Get server IP
↓
Establish TCP connection
↓
TLS handshake
↓
Send HTTP request
↓
Server returns page

The DNS resolution speed discussed here is mainly the time from starting a DNS query to getting a usable resolution result.

For example, a website speed test might show:

DNS: 18 ms
TCP: 32 ms
TLS: 45 ms
TTFB: 96 ms

The 18 ms here is the time spent in the DNS stage. Note that DNS resolution time and server response time are not the same metric.

DNS happens before the browser actually connects to the server, while TTFB mainly reflects the time from sending the request to the server starting to return the first byte. If DNS is slow, simply upgrading server specs usually won't help much. Conversely, if DNS takes only a dozen milliseconds but TTFB is several hundred milliseconds, the focus should shift to the server, database, CDN origin pull, or application.

2. How do you test website DNS resolution speed?

In practice, I usually don't rely on just one method. Chahu's online multi-node tool is good for getting a first look at regional differences, nslookup is good for quickly confirming resolution results, and dig is better for digging into query time and DNS servers.

1. Use Chahu's online DNS speed test tool

If you don't want to use the command line, the easiest way is to use an online DNS lookup or DNS speed test tool.

Open Chahu's DNS check directly:

https://www.chahu.com/dns

Enter the domain you want to test and you can see the current DNS resolution status. Chahu also offers DNS speed testing and checks under different ISP network environments, making it better suited for problems like "it's fine where I am, but users in some regions report issues."

For example, a website test might show:

Beijing Telecom 18 ms
Shanghai Unicom 24 ms
Zhejiang Telecom 21 ms
Guangzhou Mobile 96 ms
Shenzhen Mobile 112 ms

This kind of result is more useful than just seeing an "average 38ms."

The overall average may not look especially slow, but Guangzhou and Shenzhen Mobile are clearly higher than other regions. That narrows the focus to specific ISP routes, recursive DNS, or authoritative DNS network coverage.

If DNS checks look normal but the site is still slow, you can continue with Ping, website speed tests, or TCPing to look at the rest of the network path. That helps separate the problem into:

Slow DNS resolution
Slow network connection
Slow server response
Slow page resource loading

Instead of just seeing "the website is slow."

2. Use nslookup to check DNS

Windows users can open CMD or PowerShell:

nslookup example.com

Normally it returns the IP address corresponding to the domain.

If you want to specify a DNS server, you can test like this:

nslookup example.com 8.8.8.8

Then switch to another DNS:

nslookup example.com 1.1.1.1

You can also test other public DNS servers based on your actual environment.

This method is good for checking whether different DNS resolvers return consistent results.

For example:

DNS A → 203.0.113.10
DNS B → 203.0.113.10
DNS C → 203.0.113.80

If the site recently changed its DNS records and different DNS servers return different IPs, it's likely related to DNS caching, TTL, or record synchronization.

That said, nslookup is better for checking "where it resolves to." If your main goal is to observe precise DNS query time, dig is usually more direct.

3. Use dig to check DNS query time

On Linux and macOS, you can use:

dig example.com

In the output, pay attention to:

;; Query time: 23 msec

The 23 msec here means this DNS query took about 23 milliseconds.

If you want to test different DNS servers separately, use:

dig @8.8.8.8 example.com

and:

dig @1.1.1.1 example.com

Suppose you get:

DNS A: 18 ms
DNS B: 25 ms
DNS C: 126 ms

At least you can confirm that the difference in resolution speed isn't caused by the website server. It's related to the DNS resolver you're using, the network route, or the upstream DNS query process.

Keep in mind that a single result still doesn't represent long-term performance. DNS itself has caching, and the first query for a domain may not take the same amount of time as later queries. So it's best to test several times before drawing conclusions.

3. What is a normal DNS resolution speed?

There's no absolute standard that applies to every website, because resolution speed is affected by user region, ISP, local recursive DNS, cache status, and the location of authoritative DNS nodes. For everyday website performance troubleshooting, you can roughly use this range:

This table is better as a troubleshooting reference than a hard standard. For example, a site mainly serving North American users getting 80 ms DNS in Asia doesn't automatically mean DNS is a problem. But if it mainly serves users in China and Beijing, Shanghai, and Guangzhou networks consistently exceed 150 ms, it's worth investigating further. In real operations, stability and regional consistency matter more than simply chasing the lowest DNS latency. An average of 20 ms with an 800 ms spike or timeout every so often isn't necessarily better than a DNS that stays steady at 35 ms.

4. What causes slow website DNS resolution?

Abnormal DNS resolution speed usually isn't caused by the website application itself. In that case, start by checking the DNS network and configuration.

1. DNS nodes are far from users

If the authoritative DNS network coverage doesn't match where the website's main users are, queries may have to travel a longer network path.

For example, if a website's users are mainly in Asia but the DNS service lacks good nodes or network peering in Asia, the result is higher DNS query time in some regions.

2. Clear differences between ISPs

This is common in multi-ISP network environments.

For example:

China Telecom: 22 ms
China Unicom: 31 ms
China Mobile: 118 ms

If repeated tests show similar results, you can't simply call it "DNS is slow overall." It's more likely a problem with the route, scheduling, or recursive query between a specific ISP and the DNS node.

That's why website DNS speed tests shouldn't rely on just one node.

3. DNS cache misses

DNS queries don't always start completely from scratch every time.

If the local or recursive DNS already has the result cached, the query is usually fast. If it's a cache miss, it may need to continue querying authoritative DNS, which naturally takes longer.

So it's not surprising to see some variation in timing when testing the same domain several times in a row.

4. CNAME chains are too long

After connecting to a CDN, cloud service, or third-party platform, some domains end up with multiple layers of CNAME.

For example:

www.example.com
↓
CNAME
↓
cdn.example.net
↓
CNAME
↓
edge.example.net
↓
A / AAAA

CNAME isn't something you can't use—it's very common in CDN scenarios.

What really matters is not stacking unnecessary CNAME layers. Each additional layer can make the DNS query process more complex.

5. Occasional DNS timeouts

Some problems are hard to see in average data.

For example, test ten times:

18 ms
21 ms
19 ms
23 ms
Timeout
20 ms
18 ms
450 ms
22 ms
19 ms

If you only calculate the average at the end, the problem may not look obvious, but real users have already hit two anomalies.

In this case, pay attention to P95, P99, or at least look at multiple test results instead of staring at the single fastest value.

6. A and AAAA resolution issues

Many websites now configure both IPv4 A records and IPv6 AAAA records. If one DNS resolution path or the subsequent IPv6 network has problems, some devices may experience waiting, fallback, or abnormal connection speed.

So if some users suddenly experience slow first visits after enabling IPv6, test A, AAAA, and the actual IPv4/IPv6 paths separately.

5. How do you tell whether DNS is actually causing the website to be slow?

This is a key step in website speed troubleshooting. Many people see a page take two or three seconds and immediately assume the server is slow. What's actually valuable is breaking down the whole visit.

For example:

DNS 185 ms
TCP 32 ms
TLS 41 ms
TTFB 88 ms
Download 126 ms

This case is obvious.

The server started responding in only 88 ms, TCP and TLS look normal, but DNS alone took 185 ms. Continuing to optimize PHP, the database, or server CPU probably won't noticeably improve first-visit speed.

DNS is what should be addressed first.

Now look at another case:

DNS 17 ms
TCP 29 ms
TLS 43 ms
TTFB 680 ms
Download 115 ms

Here DNS is already fast. What's slowing the site down is TTFB.

In this case, switching DNS providers won't help much. You need to look further into server processing time, dynamic pages, database queries, or CDN origin pulls.

Another case:

DNS 20 ms
TCP 260 ms
TLS 310 ms
TTFB 390 ms

Here DNS isn't the main issue either. It's more worth checking server distance, cross-border routes, CDN scheduling, or TCP/TLS network connections.

So a website speed test shouldn't just give you:

Total load time: 1.8 seconds

Instead, break the path down as much as possible:

DNS → TCP → TLS → TTFB → Download

Only when you know which step is eating the time do you have a direction for optimization.

6. How do you optimize slow DNS resolution?

If you've confirmed the problem is concentrated in the DNS stage, the first step isn't to switch servers immediately. Recheck whether your current DNS architecture fits your website's user distribution.

For websites with many users in China, focus on whether there are consistent differences between China Telecom, China Unicom, and China Mobile. For global businesses, check whether DNS latency is balanced across major user regions like Asia, Europe, and North America.

The DNS service's own global network coverage is also important. A DNS that performs well in one region doesn't mean it performs the same everywhere. When choosing one, consider actual user locations rather than just the lowest latency from a single test point.

Also check the CNAME chain.

If it has become:

Business domain
↓
CNAME A
↓
CNAME B
↓
CNAME C
↓
Final IP

then confirm whether all those hops serve a real purpose.

TTL also needs to be set reasonably. A TTL that's too short increases DNS query frequency and authoritative DNS load. But if the TTL is too long, once you change servers, modify CDN, or adjust DNS records, old caches may stick around for a long time.

So there's no simple conclusion like "lower TTL is always better" or "higher TTL is faster." A more reasonable approach is to set it based on how often the website changes and how stable the business is.

Finally, after DNS optimization, run multi-node tests again instead of just clearing cache once on your own computer and refreshing the browser. What really needs verifying is whether users in different regions are getting normal resolution results and query times again.

7. What's the difference between DNS lookup and DNS speed testing?

These two concepts are easy to confuse, but they solve different problems.

A regular DNS lookup focuses more on:

Which IP does the domain resolve to?
Is the A record correct?
Does AAAA exist?
Where does the CNAME point?
What is the TTL?

For example, if a website just changed servers, the most important question might simply be:

example.com

Does it still point to the old server, or has it resolved to the new one? That's DNS lookup.

DNS speed testing focuses more on:

How long did resolution take?
How much does it differ between regions?
Are there anomalies with different ISPs?
Are there timeouts?
Is DNS slowing down website access?

So if you just want to confirm whether a CDN CNAME is configured correctly, do a DNS lookup. If users report "the first visit to the site is especially slow," look further into DNS response time. These two checks don't conflict—they just solve different problems.

Conclusion

Website DNS resolution speed isn't something to chase lower and lower for its own sake. What really matters is whether resolution is stable and whether there are obvious differences between regions and ISPs. If DNS queries take only 20–30 ms but the site still opens slowly, keep checking TCP connection, TLS handshake, TTFB, and page resources. If DNS itself is already taking 100–200 ms, or some regions are starting to see timeouts, then no amount of server parameter tuning will solve the wait before users even connect to the website.

In practice, start with Chahu's online multi-node DNS check to see resolution across regions, then use nslookup or dig to further verify DNS results and query time. Once DNS looks normal, move on to TCP, TLS, TTFB, and page load stages. Breaking down the entire access path is usually more effective than staring at a single "website took X seconds to load" number.

Related Q&A

1. Why do too many CNAMEs in DNS resolution cause severe first-load delays?

When a domain is configured with a multi-level CNAME chain (such as a.com -> b.net -> c.org -> IP), the client's recursive DNS must issue multiple iterative queries in sequence. If the TTL is set improperly or an intermediate node misses cache, each CNAME hop adds another RTT of authoritative DNS query overhead. This introduces hundreds of milliseconds of unnecessary delay before the user even establishes a TCP connection, and the impact is especially obvious on mobile networks with high RTT.

2. How should you set DNS TTL to balance resolution performance and failover speed?

TTL determines how long recursive DNS servers cache the resolution result. Setting it too high (such as 86400 seconds) greatly improves cache hit rate and reduces resolution time, but when IPs change, servers go down, or you switch CDNs, users worldwide may lag behind in getting updates. Setting it too low (such as 60 seconds) causes recursive caches to expire frequently, increasing authoritative DNS load and slowing user access. In production, stable services usually use a TTL of 300 to 3600 seconds (5 minutes to 1 hour), and lower it temporarily to 60 seconds 24 hours before a planned migration or release.

3. Why does Query time drop sharply on the second consecutive dig test?

dig sends a query directly to the specified resolver. On the first query, if the resolver's local cache doesn't have the record (cache miss), it must perform a full iterative query from the root and TLD all the way to the authoritative DNS, which takes longer. After the first successful query, the resolver stores the result in memory cache (cache hit) for the TTL period. On the second run of the same command, the resolver reads from memory and returns immediately, so Query time usually drops to 0–2 ms. When testing cold-start speed, use a brand-new uncached subdomain or add a random prefix.

4. How does EDNS Client Subnet (ECS) affect intelligent DNS routing and speed test accuracy?

In traditional DNS queries, authoritative DNS can only see the IP of the recursive DNS server (such as 8.8.8.8). That can cause intelligent DNS routing (such as Telecom/Unicom/Mobile split, or continental routing) to send users to the wrong CDN node. When ECS is enabled, the recursive DNS attaches the user client's IP subnet information to the query. The authoritative DNS can then return the IP that best matches the user's actual location. When running multi-node speed tests, if the public DNS used by the test tool doesn't support ECS, the resolved IP may not be the optimal node, creating the illusion that DNS resolution and actual network connection speed don't match.