Can Slow DNS Resolution Slow Down a CDN? How to Troubleshoot Domain Resolution Delays

The site is already behind a CDN, and node latency doesn't look high, yet the first time users open it, the browser still sits idle for a while. After a refresh, it's fast again.

In this case, the problem may not be CDN delivery, but an earlier step: DNS resolution.

Slow DNS resolution can indeed delay the first connection to a website and CDN.The browser must first resolve the domain name to an IP address before it can establish a TCP or QUIC connection to a CDN node, then perform a TLS handshake and send HTTP requests. If DNS doesn't return a result, the acceleration capabilities downstream can't help yet.

But let's be clear about the boundaries:

• DNS mainly affects the wait before a connection is established;

• Once DNS is cached, repeat visits may show almost no resolution time;

• High TTFB, slow downloads, or slow page rendering are not necessarily related to DNS;

• Switching to a public DNS resolver and seeing faster results does not necessarily mean the authoritative DNS is at fault;

• When a CDN uses DNS-based scheduling, different resolvers may return different nodes, so you can't compare only millisecond values.

Start by breaking the problem down with a table:

Where does DNS sit in the CDN access path?

After a user enters a URL, the typical process can be simplified as:

输入域名
   ↓
浏览器、系统或递归DNS查找IP
   ↓
得到CDN入口地址
   ↓
建立TCP或QUIC连接
   ↓
完成TLS握手
   ↓
CDN缓存命中或向源站取内容
   ↓
返回网页和静态资源

DNS happens before connecting to the CDN.

Suppose the DNS phase waits an extra 800 ms. Even if the CDN then returns content in only 100 ms, the user has still already lost 800 ms upfront.

However, browsers, operating systems, and recursive resolvers all cache DNS answers. On repeat visits to the same domain, cached answers may be used directly, or an established network connection may even be reused.

This is why DNS issues often show up as “slow the first time, normal after refresh.”

The CDN already has nodes, so why is DNS still needed?

No matter how many CDN nodes there are, users must first know which IP to connect to.

Many CDNs use CNAME or authoritative DNS scheduling to return a suitable entry address based on the user's region, ISP, network conditions, and service configuration. For example:

www.example.com
        ↓ CNAME
www.example.com.cdn-provider.example
        ↓ A / AAAA
203.0.113.20

This resolution process is responsible both for “finding the address” and potentially for “selecting the node.” Therefore, in a CDN, DNS is not just a phone book; it is part of the traffic scheduling path.

If DNS responds slowly, the connection starts later; if it returns an unsuitable address, DNS itself may be fast, but the subsequent TCP, TLS, and TTFB will still be slow.

So when testing, record all of the following:

1. How long DNS took;

2. What CNAME and IP were returned;

3. Whether different regions and resolvers receive different answers;

4. Whether the CDN node ultimately connected to matches expectations.

You can start withCdnChart CDN Checkto view the domain's CNAME, A/AAAA, response IPs, ASN, and CDN vendor clues, then use multi-region speed tests to assess scheduling results.

First distinguish the three cache layers in DNS

Before troubleshooting, you need to know that “DNS cache” is not stored in only one place.

Browser cache

The browser may store recent resolution results and may also reuse an established connection. In this case, no new DNS query may appear in developer tools.

Operating system cache

Windows, macOS, Linux, or a local caching service may store DNS answers.

Closing a browser tab does not necessarily clear the system cache.

Recursive resolver cache

Home routers, ISP DNS, or public DNS look up results with authoritative DNS on behalf of users and cache answers according to TTL.

Even if you clear your own computer's cache, the upstream recursive resolver may still return an already cached result directly.

This means:

A fast DNS query may simply be a cache hit; a slower query may mean the recursive resolver happened to need to query the authoritative chain again.

Both results are real, but they represent different access scenarios.

Step 1: Confirm in the browser how much time DNS actually takes

Open Chrome DevTools:

1. PressF12or right-click and select “Inspect”;

2. Open the Network panel;

3. Reload the page;

4. Select the main document or a request;

5. Open the Timing tab;

6. Check phases such as DNS Lookup, Initial connection, and Waiting (TTFB).

In Chrome's official Network Timing documentation, DNS Lookup is defined as the phase in which the browser resolves the request's IP address; Initial connection includes TCP connection and SSL negotiation, while Waiting (TTFB) includes the network round trip and the time the server takes to prepare a response.

Therefore:

• DNS Lookup is high while connection and TTFB are normal: investigate DNS first;

• DNS is low but TTFB is high: focus on cache, origin fetch, and the server;

• DNS and TTFB are normal but Content Download is high: focus on bandwidth, file size, and packet loss.

Note that DNS showing zero does not necessarily mean authoritative DNS is extremely fast. The browser may have used a cache or simply reused an existing connection. Incognito mode also does not guarantee bypassing OS and recursive DNS caches.

A full page may also access a dozen or even dozens of hostnames. A fast DNS for the main domain does not mean ad, font, analytics, image, or API domains are also fast.

When viewing the waterfall chart, watch for any third-party domain that is stuck in the DNS Lookup phase for a long time.

Step 2: Use dig to test current DNS resolution time

On Linux, macOS, or an environment with BIND tools installed, you can run:

dig www.example.com A +stats

At the end of the output, you will usually see:

;; Query time: 26 msec
;; SERVER: 192.0.2.53#53(192.0.2.53)
;; WHEN: ...
;; MSG SIZE  rcvd: ...

Focus on recording:

• status: whether it isNOERROR;

• ANSWER SECTION: the returned CNAME or IP;

• Query time: the time for this query to the specified recursive DNS;

• SERVER: which DNS server was actually used;

• TTL: how long the answer can remain in cache.

Running it twice consecutively may produce different results:

dig www.example.com A +stats
dig www.example.com A +stats

If the first run is slower and the second is noticeably faster, it usually means the recursive resolver had to look up or refresh data the first time, then hit the cache afterward.

This is not necessarily a fault, but if cold queries frequently time out or take abnormally long, further investigation is needed.

Step 3: Compare ISP DNS and public DNS

First test the resolver currently used by the system, then test public resolvers separately:

dig www.example.com A +stats

dig @1.1.1.1 www.example.com A +stats

dig @8.8.8.8 www.example.com A +stats

Don't just copy down threeQuery time, and also compare the answers:

dig @1.1.1.1 www.example.com A +noall +answer
dig @8.8.8.8 www.example.com A +noall +answer

It is recommended to record them as follows:

The contents in the table are only format examples and do not represent the real performance of any resolver or CDN.

Why must answers be recorded? Because a CDN may return region-specific results based on the recursive DNS location or EDNS Client Subnet information.

Google Public DNS'sECS documentationstates that ECS can let recursive resolvers provide client subnet information to authoritative DNS, thereby obtaining responses tailored to the client's location.

This also means that after switching to a public DNS, the site becoming faster may have two causes:

1. The new resolver itself responds faster;

2. The new resolver causes the CDN to return a different entry address.

Without recording the resolved IP and the final connected IP, you cannot distinguish between these two cases.

Public DNS uses Anycast, so the same address may correspond to different service nodes in different regions. The result you get in Beijing cannot directly represent users in Guangzhou or overseas.

Step 4: Check whether the CNAME chain is too long

View the full answer:

dig www.example.com A +noall +answer

You may see:

www.example.com.                  300 IN CNAME site.cdn.example.
site.cdn.example.                 120 IN CNAME route.provider.example.
route.provider.example.           60 IN A     203.0.113.20

The more CNAME levels there are, the more work the recursive resolver usually has to complete, and the more points of failure there can be.

But you cannot simply say that “each additional CNAME adds one fixed full network round trip.” The resolver may already have a cache, or it may optimize. The actual impact should be based on cold-cache, multi-region tests.

Focus on checking:

• Whether there are unnecessary multi-layer CDN or traffic scheduling domains;

• Whether a CNAME target occasionally times out during resolution;

• Whether TTLs differ greatly across links;

• Whether old aliases are still retained after a CDN migration;

• Whether the root domain's ALIAS or CNAME Flattening hides an external chain.
  

If a detection tool only shows the final A record, that does not mean alias resolution did not occur in between. You should also check the authoritative configuration and the full responses from different recursive resolvers.

Step 5: Use +trace to check delegation and authoritative DNS

When multiple public DNS services are slow, occasionallySERVFAIL, or the same domain cannot be resolved in some regions, you can continue by running:

dig +trace www.example.com A

The ISC BIND dig manual states that+traceperforms iterative queries starting from a root server and follows delegations step by step to find the target answer.

It can help you check:

• Whether the root and top-level domain delegate correctly;

• Which authoritative NS records the parent zone returns;

• Whether authoritative servers are reachable from the current network;

• Whether the problem is stuck at the root, TLD, authoritative NS, or a subsequent CNAME target;

• Whether there are obvious timeouts or inconsistent answers.

However,dig +traceis not a speed test of the normal resolution process for ordinary users.

It bypasses the recursive resolver cache and queries the delegation chain directly from the current machine, mainly for diagnostics. Its total time should not be directly compared with browser DNS time.

You can also first query the authoritative servers:

dig example.com NS +short

Then directly ask one of the authoritative NS servers:

dig @ns1.example.net www.example.com A +stats

You should check all authoritative NS servers separately, not just one.

If one of them is unreachable or responds abnormally, whether users encounter problems depends on which server the recursive resolver selected at the time, which may appear as “mostly normal, occasionally very slow.”

Step 6: Use curl to confirm how much DNS is slowing things down

digmeasures the DNS query itself,curlcan place DNS back into the full HTTP request for observation:

curl -sS -o /dev/null \
  -w 'status=%{http_code}\nip=%{remote_ip}\ndns=%{time_namelookup}\nconnect=%{time_connect}\ntls=%{time_appconnect}\nttfb=%{time_starttransfer}\ntotal=%{time_total}\n' \
  https://www.example.com/

Example output:

status=200
ip=203.0.113.20
dns=0.420817
connect=0.486503
tls=0.552481
ttfb=0.681209
total=0.742135

These numbers are for demonstration only and do not represent reasonable thresholds or any real website.

The official curl manual's definition oftime_namelookupis: the cumulative time from the start of the request to completion of domain name resolution.

Other times are also cumulative from the start of the request, so you cannot treattime_connectdirectly as pure TCP time.

You can roughly calculate:

DNS时间      = time_namelookup
TCP阶段      = time_connect - time_namelookup
TLS阶段      = time_appconnect - time_connect
首字节前等待 = time_starttransfer - time_appconnect
下载阶段     = time_total - time_starttransfer

If DNS accounts for most of the total time, investigate resolution first; if DNS is very low but TTFB is high, focus on CDN cache, node processing, origin fetch, and the origin server.

UseCdnChart Website Speed Testfor multi-region testing, you should also view DNS time together with connection, TTFB, and download time in the same request chain, to avoid lumping all latency under “slow CDN.”

Step 7: Check A and AAAA separately

Modern browsers usually consider both IPv4 and IPv6.

First check the records separately:

dig www.example.com A +stats
dig www.example.com AAAA +stats

Then test the HTTP connections separately:

curl -4 -sS -o /dev/null \
  -w 'ipv4_ip=%{remote_ip} dns=%{time_namelookup} connect=%{time_connect} total=%{time_total}\n' \
  https://www.example.com/

curl -6 -sS -o /dev/null \
  -w 'ipv6_ip=%{remote_ip} dns=%{time_namelookup} connect=%{time_connect} total=%{time_total}\n' \
  https://www.example.com/

If AAAA resolution is fast, but the IPv6 connection is unreachable or of poor quality, the stall users feel may occur during connection and fallback, not because the DNS server responds slowly.

This type of issue is often misdiagnosed as “domain resolution is stuck.” When judging, look at the boundary between the DNS and TCP phases, not just the browser's overall wait time.

Common causes of slow DNS resolution

1. Slow response from local or ISP recursive DNS

This appears as noticeably slow default DNS in the same region, while public DNS is relatively normal.

The cause may be recursive node load, network path, cache miss, or unstable upstream queries.

You need to retest from the ISP where real users are located; you cannot draw conclusions only by changing resolvers on a cloud server.

2. Poor coverage or reachability of authoritative DNS nodes

If multiple recursive resolvers all have to wait for authoritative DNS on a cache miss, cold queries will be slow.

An abnormality on one authoritative NS server can also cause intermittent timeouts.

You should check whether all authoritative NS servers are reasonably distributed, whether UDP and TCP port 53 are available, and whether they respond reliably in different regions.

3. CNAME chain too long or upstream target unstable

A website may first go through a traffic scheduling platform, then enter the CDN, and afterward point to other services.

The more complex the chain, the more you should check each level's target, TTL, and authoritative service status.

4. TTL too short makes cache expiration more likely

TTL determines how long a DNS record can be cached.

A longer TTL usually improves the chance of cache hits but makes record changes propagate more slowly; a shorter TTL makes switching easier but increases how often recursive resolvers re-query.

Cloudflare'sDNS TTL documentationalso emphasizes this trade-off: a longer TTL helps cache queries, but record updates take longer to reach users.

Do not blindly set TTL extremely long just to make “DNS faster,” and do not think that setting TTL to tens of seconds will make resolution itself faster.

TTL controls cache lifetime, not an authoritative server's single-response speed.

5. DNSSEC misconfiguration

A common scenario is that after changing DNS providers, the registrar still keeps the old DS record, while the new service's DNSKEY cannot match. Recursive DNS that supports validation may returnSERVFAIL.

Cloudflare'sDNSSEC troubleshooting documentationrecommends using dig queries with+cdto help confirm: if normal validation returnsSERVFAIL, but when validation checks are disabled you still get a result, the DNSSEC configuration is worth checking closely.

Example:

dig @1.1.1.1 www.example.com A +dnssec
dig @1.1.1.1 www.example.com A +dnssec +cd

+cdis only suitable for diagnostics and cannot serve as a long-term solution to bypass DNSSEC errors. You should fix the registrar DS, DNSKEY, and signature configuration.

6. Domain delegation, Glue, or NS record inconsistency

The NS records delegated by the parent zone differing from those published by the child zone, expired Glue addresses, or authoritative server names that cannot themselves be resolved can all cause some resolvers to fail or take a longer path.

Google Public DNS'sdomain troubleshooting guidelists DNSSEC, authoritative server, delegation, and oversized DNS response issues as step-by-step check items.

When encountering cross-regionSERVFAILissues, you should not just repeatedly clear the local cache.

7. DNS response too large or TCP fallback abnormal

DNS usually prefers UDP.

If a response is too large and gets truncated, the client or recursive resolver needs to switch to TCP. If the firewall allows only UDP 53 and not TCP 53, intermittent failures may occur.

DNSSEC and larger TXT or DNSKEY responses deserve particular attention.

8. Browser uses a different DoH resolver

The browser's secure DNS or DNS over HTTPS settings may cause it to use a resolution path different from system commands.

Therefore,digis normal but the browser is slow, confirm whether the browser has DoH enabled, which provider it uses, and whether the corporate network proxies or intercepts it.

How should different results be judged?

How should DNS resolution be optimized?

Optimize only after identifying the responsible layer; don't switch providers immediately just because DNS time looks high.

For website operators

• Use authoritative DNS with multi-region coverage and a stable SLA;

• Ensure at least two authoritative NS servers can respond reliably over UDP and TCP;

• Remove unnecessary CNAME levels and legacy scheduling records;

• Set TTL appropriately based on change frequency;

• When switching DNS providers, also check registrar NS and DNSSEC DS records;

• Validate A, AAAA, CNAME, NS, SOA, and DNSSEC separately;

• Continuously monitor resolution success rate and P95 from target user regions and ISPs;

• Reduce unnecessary third-party domains on the page.

For end users or on-site troubleshooters

• Record the DNS resolver currently in use; don't just say “the network is normal”;

• Compare ISP DNS with multiple public DNS services;

• Also record resolution results, so you can tell whether changing DNS actually lands on a different CDN node;

• Compare wired, Wi-Fi, and mobile networks;

• Check whether the browser's DoH settings match the system DNS;

• Once resolution is normal, continue checking TCP, TLS, and TTFB; don't stop at the DNS layer.

The most common mistakes in DNS speed testing

Testing only once

The first run may be a cold query, and the second may hit the cache. Keeping only one of them cannot describe real stability.

You should run multiple consecutive rounds and observe over time.

Comparing only Query time, not answers

A CDN may return different nodes based on the resolver and user location.

A DNS query may be 10 ms faster but send the user to a more distant entry point, so the site may not ultimately be faster.

Treating speed after a page refresh as the result of DNS optimization

A refresh is affected by browser cache, DNS cache, TCP/TLS connection reuse, and CDN cache at the same time, so it cannot be attributed to DNS alone.

Using dig +trace to represent the ordinary user experience

+traceis used to check the delegation chain and authoritative servers; it does not reproduce the full scenario of users querying through ISP recursive DNS and caches.

Assuming all caches are cleared after clearing the local cache

Upstream recursive DNS may still hold answers or negative caches. A local flush does not force the ISP resolver to re-query authoritative DNS.

Assuming IPv6 is fine just because an AAAA record exists

A record existing does not mean connectivity works. You need to usecurl -4andcurl -6to verify the network phase.

Looking only at average latency, not failure rate and P95

If DNS takes 10 ms most of the time but occasionally times out for 2 seconds, the average may still look unremarkable, yet users will clearly feel the stalls.

For stability troubleshooting, record P50, P95, timeout rate, andSERVFAILpercentage.

FAQ

Does slow DNS resolution always slow down every page request?

Not necessarily.

Resolution results may be cached by the browser, operating system, or recursive DNS, and connections to the same hostname may also be reused. Slow DNS usually has a more noticeable impact on first visits, queries after cache expiration, and newly appearing third-party domains.

How many milliseconds is considered slow for DNS resolution?

There is no universal answer independent of region, network, and cache state.

You should distinguish cold queries from cache hits and establish a baseline with other domains and resolvers in the same region. More important than a fixed threshold are P95, timeout rate, and differences between ISPs.

Will switching to 1.1.1.1 or 8.8.8.8 definitely be faster?

Not necessarily.

Public DNS has different network paths in different regions and may also affect CDN scheduling results. You should compare query time, returned IPs, and final TCP, TLS, and TTFB together, not just DNS milliseconds.

Do more CNAMEs always mean slower DNS?

Multiple CNAME layers increase resolution work and potential failure points, but the recursive resolver may already have some records cached, so the impact is not fixed linear growth.

You need cold queries and multi-region data to determine this.

Does a lower TTL make DNS faster?

No.

A low TTL means answers expire sooner and recursive resolvers need to re-query authoritative DNS more frequently; it does not make an authoritative server return a single response faster.

Does the browser showing DNS as 0 mean there was no DNS resolution?

Not necessarily.

The browser may use a cache, an existing connection, or another pre-resolution mechanism. To observe cold resolution, combine independent commands, different resolvers, and multiple rounds of results.

DNS is fast, so why is the website still slow?

Resolution is only the first step.

After that come TCP, TLS, CDN processing, caching, origin fetch, content download, JavaScript execution, and page rendering. Continue checking TTFB, cache status, and the browser waterfall.

Can a DNS issue affect only one ISP?

Yes.

Different ISPs use different recursive DNS and network paths, and may also get different entry points from the CDN's authoritative DNS. You need to test China Telecom, China Unicom, and China Mobile separately in the same city.

Summary: Fast DNS does not equal a fast website, but slow DNS will definitely make connections start later

To troubleshoot DNS resolution time, remember this sequence:

1. Use browser Timing to confirm whether slow requests are really stuck in DNS Lookup;

2. Usedig +statsto check the current recursive DNS query time and answers;

3. Compare ISP DNS, 1.1.1.1, and 8.8.8.8, and record CNAME and IP at the same time;

4. Check CNAME levels, TTL, A, and AAAA;

5. Usedig +traceand direct authoritative NS queries to check the delegation chain;

6. When you encounterSERVFAILfocus on checking DNSSEC, NS, and Glue configuration;

7. Usecurlto compare DNS, TCP, TLS, TTFB, and total time together;

8. Continuously observe P50, P95, and failure rate from the regions and ISPs where real users are located.

If you want to first understand the domain's current resolution chain and CDN vendor clues, you can useCdnChart CDN Check; if the problem occurs only in certain regions or ISPs, then useCdnChart Website Speed Testto compare multi-region results, and refer toCdnChart Testing Methodologyto understand P50 and P95.

Slow DNS resolution can prevent a CDN connection from starting for a long time, but once the DNS phase is normal, you should continue looking downstream.

Only by separating DNS, connection, first byte, and download can you avoid blaming the CDN for every case of “the website is slow.”