DNS resolution time is how long it takes a resolver to turn a domain name into an IP address after your browser asks for it. For a typical home connection, a lookup under about 30 ms is good and one over about 80 ms is a problem. Those are guideline figures, not a law, and they only matter if the lookup is actually on the critical path of what you are doing. This guide explains the numbers, shows how to measure your own, and covers what to change when the result is bad.
TL;DR
- DNS resolution time is the wait between asking for a name and getting an address back. It is one slice of latency, not the whole of it.
- For local resolvers, under 30 ms is good, 30 to 80 ms is acceptable and over 80 ms is problematic. Cross-region lookups get a looser scale.
- Measure with
dig,nslookup,Resolve-DnsNameordnsping, repeat the test, and compare cached and uncached answers. - Switching to a public resolver can cut lookup time, but it will not raise your download speed, and it can sometimes make CDN-hosted content slower.
Table of Contents
- What DNS resolution time actually measures
- What is a good DNS lookup time?
- Why DNS lookups get slow
- How to measure DNS response time
- How to read your results
- Perspective: what we see at GrandSpeed
- How to reduce high DNS latency
- Check DNS alongside everything else
- FAQ
- Sources
What DNS resolution time actually measures
Every connection to a website, game server or video platform starts with a name. Your device asks a resolver, usually your ISP's or your router's forwarder, for the address behind that name. DNS resolution time is the interval from the query to the resolver's answer. People also call it DNS lookup time, DNS response time or DNS latency. In practice they all describe the same wait.
That wait happens before any data moves. Your browser cannot open a connection to a server until it knows where the server is. So a slow lookup adds delay at the very start of a page load, a login or a matchmaking request.
How it differs from ping and from speed
DNS time is a narrow slice of overall latency. Network latency generally refers to the round-trip time for data packets to travel between endpoints, and the DNS lookup is one distinct component of that wait. A ping to a game server measures the path to that server. It does not include the lookup, because the IP is already known by then.
That is why a faster resolver does not directly improve your ping. A community-verified answer on Super User makes the same point: once the address is cached, DNS no longer touches individual ping results. If you want the full picture of why one ping number hides so much, our piece on ping versus latency covers it.
It also has nothing to do with bandwidth. A 1 Gbps plan with a 200 ms resolver still feels sticky when you click a link, because the first request waits. A 50 Mbps plan with a 15 ms resolver feels snappy for browsing. Speed decides how fast the bytes arrive, and DNS decides how fast they can start.
What is a good DNS lookup time?
Sources disagree a little, because they measure different things. Here are the ranges that appear in the references we used.
| Scenario | Good | Acceptable | Problematic |
|---|---|---|---|
| Local resolver (IO River) | Under 30 ms | 30 to 80 ms | Over 80 ms |
| Cross-region lookup (IO River) | Under 60 ms | 60 to 120 ms | Over 120 ms |
| Enterprise internal DNS (ManageEngine) | Not stated | Not stated | Above 50 ms |
| Enterprise external DNS (ManageEngine) | Not stated | Not stated | Above 100 ms |
Other guides put the average lookup between 20 ms and 120 ms, and call anything in or below that band very good. Cloudflare says its resolver typically answers in about 10 to 20 ms, while other resolvers may take well over 100 ms. That is a vendor claim about its own product, so treat it as a ceiling to compare against, not a promise for your location.
The real-world average is worse than any of these. Google reported an average end-to-end resolution time of 300 to 400 ms once packet loss, dead name servers and misconfigurations are counted. That figure describes the whole internet, not a healthy home setup, but it shows why outliers matter more than the best case.
A practical rule of thumb
For a home or small office, aim for:
- Under 30 ms for a cached or nearby answer.
- Under 100 ms for an uncached name that has to be resolved from scratch.
- Consistency. A resolver that answers in 12 ms nine times and 900 ms the tenth time feels worse than one that answers in 40 ms every time.
Why DNS lookups get slow
Google lists the causes of slow resolution: distance to the resolver, cache misses, underprovisioned servers, packet loss, congestion and denial-of-service traffic. In a home setting, they break down like this:
- Your ISP's resolver is overloaded or far away. It may be fine most of the day and poor at peak hours.
- Your router is a weak forwarder. Many routers run a tiny DNS cache. When it is full, buggy or rebooting, every lookup goes out cold.
- Wi-Fi or line problems. A DNS query is a small packet. If your link drops packets, the query is retried after a timeout, and a single lost packet can add a full second or more to that lookup.
- Cache misses. The first visit to a name is always slower than the second. Rarely visited sites will always show the uncached cost.
- Pages that pull from many domains. Slow DNS makes browsing feel sticky because pages load resources from many domains and the lookup costs stack up.
- Security events. DoS attacks and malicious traffic against a resolver can raise latency, though this is outside your control.
Why it matters for page speed
A site with a dozen third-party domains for fonts, analytics, ads and embeds needs a dozen lookups. Each one is small, but the first ones block the page from rendering. Website owners who want to see how this fits into the wider picture can read about website load time and conversions.
Why it matters for gaming, streaming and calls
Once a game session is running, DNS barely matters, because the server's address is already known. It matters at the edges: logging in, finding a match, switching servers, loading a store page or launching a new app. A slow resolver will make those steps drag while in-match ping stays fine. If your in-match ping is the problem, start with our guide to diagnosing high ping in games instead.
Video calls and VoIP work the same way. Setting up a call needs lookups for signaling servers, and then the media flows over addresses already resolved. Choppy audio mid-call is almost always jitter or packet loss rather than DNS. For that, see fixing VoIP jitter and our VoIP latency tests.
One more caveat from MDN: subsequent requests in a session often show lower latency because connections are already established. The first request pays the full price, and later ones do not.
How to measure DNS response time
The key rule: never trust a single query. One lookup may hit a warm cache or a cold one, and the difference can be a factor of ten. Repeat the test and look at the spread.
On Mac and Linux: dig
Running dig example.com +stats on Linux or macOS prints a query time in milliseconds at the end of the output. To test a specific resolver, add it with an at sign, for example dig @1.1.1.1 example.com. Run it three or four times. The first answer is usually the uncached one, and the later ones show cache performance.
On Windows: nslookup and PowerShell
On Windows, you can use nslookup or the PowerShell cmdlet Resolve-DnsName. Wrapping the PowerShell cmdlet in Measure-Command gives you a millisecond figure you can repeat in a loop. Add -DnsOnly so the cmdlet skips other name sources like the local hosts file and gives you a clean DNS number.
Repeated tests with dnsping
For a better view, use dnsping from the dnsdiag toolkit. It sends a DNS query repeatedly to a chosen resolver and reports the minimum, maximum and average response time, plus jitter. Its defaults are 10 requests, record type A and a five-second maximum wait. Jitter in a DNS test is a useful signal. A low average with high jitter means the resolver is inconsistent.
For heavier benchmarking, DNS-OARC's dnsperf is a tool for accurate DNS latency and throughput measurement that reads a file of queries and self-paces the load. It is aimed at people running DNS servers, not home users.
Rules for a fair comparison
If you compare resolvers, how you test matters as much as which tools you use.
- Interleave providers. A good script alternates domains and providers rather than hammering one provider in a burst, repeats complete passes and reports the mean of successful attempts while keeping errors and timeouts visible.
- Run at least three iterations. Net-Benchmark's guidance is to run at least three iterations for a stable mean or median. For DNS over HTTPS or TLS, add a warm-up so the handshake does not distort the timing.
- Use the median on mobile. On a hotspot or cellular link, compare median latency, not average, because a few spikes will skew the mean.
- Test IPv4 and IPv6 separately. The same script notes that detecting an IPv6 route does not prove end-to-end reachability.
- Use names you actually visit. DNS-OARC's benchmarking guidance warns that different queries have different costs and recommends test data based on normal operation or real traffic samples. Ten popular domains will all be cached and flatter every resolver.
How to read your results
A number alone means little. The IETF's draft on DNS latency measurement says results depend on scope and context: cache state, transport, query type, location, observation interval and resolver configuration. Before you decide anything, ask which segment you measured. It could be client to resolver, the resolver's own work, or the resolver's trip to the authoritative server. That last segment is out of your hands. Our walkthrough on measuring DNS latency from your network separates the three.
A simple reading guide:
| What you see | Likely meaning | Next step |
|---|---|---|
| First query slow, repeats fast | Normal cache behavior | Nothing to fix |
| Every query slow, even repeats | Resolver or router is the problem | Test another resolver |
| Mostly fast, occasional multi-second spikes | Packet loss or timeouts | Test your link for loss and jitter |
| Fast resolver, slow pages | DNS is not the bottleneck | Check bandwidth and bufferbloat |
Rule out the connection first
If spikes line up with timeouts, you may be chasing the wrong problem. Packet loss on Wi-Fi hurts DNS first because queries are small, unacknowledged UDP packets that wait for a timeout before retrying. Run a full test of your line before you touch DNS settings. Bufferbloat is another common culprit: when your uplink is saturated, DNS queries queue behind your uploads. Our bufferbloat test methods show how to find it in a few minutes, and the RPM approach to latency under load explains why an idle ping can look fine while a loaded one does not.
Perspective: what we see at GrandSpeed
Most people who arrive with a DNS question really have a "my internet feels slow" question. A single speed figure rarely explains that feeling, and neither does a single DNS figure. That is the reason we measure download and upload speed, latency, jitter, packet loss, bufferbloat and DNS resolution time together.
Our view is simple. DNS is worth checking when pages hesitate before loading but stream and download fine once they start. It is not worth tuning when your calls break up or your game rubber-bands. Those symptoms point to jitter, loss or bufferbloat, and a resolver swap will not fix them. Test first, change one thing, then test again and compare the same metrics. Keeping a history of results is what turns a hunch into evidence.
— Peter D
How to reduce high DNS latency
Work through this in order, and re-measure after each step.
- Reboot the router and modem. It clears a stale or overfull DNS cache. Then measure again with repeated queries.
- Move to a wired connection for the test. If DNS is fast over Ethernet and slow over Wi-Fi, the problem is your wireless link.
- Try a different resolver. You can use a resolver other than your ISP's. Google says its public service reduces delay by adequately provisioning servers, load-balancing for shared caching and offering global coverage so that servers sit closer to users. Test two or three candidates side by side, using the rules above. For a gaming-focused version of this process, see our 15-minute test for the fastest DNS.
- Set it in the right place. Changing DNS on the router covers every device. Changing it on one device covers only that device.
- Re-test at different times of day. Evening congestion can change results.
- Keep the old setting written down. If the new resolver is not faster, you can switch back.
Does 8.8.8.8 make your internet faster?
Not in the sense of bandwidth. A faster resolver shortens the lookup, and that is all it does. The evidence on page-load benefit is mixed. A study of one ISP found that browser prefetching and caching masked the benefit of faster DNS for most requests, and that the choice of public resolver could hurt CDN performance, with a median download-throughput decrease of 35% in that study. The report is from 2013 and covers one network, so do not read it as a rule. It does show the risk: a resolver that is far from you can hand you a distant CDN node. If you switch, test real downloads and not just DNS timings.
Check DNS alongside everything else
DNS is one of several numbers that decide how a connection feels, so measure it with the others. Our speed test reports download and upload speed, latency, jitter, packet loss, bufferbloat and DNS resolution time in one run, works in any modern browser on a phone, tablet or laptop, and keeps a history of your results so you can see whether a change helped. It is free to use. If you stream video, the video streaming quality test shows what your connection can sustain, and the internet speed rankings give context for how your provider compares.
FAQ
What is a good DNS lookup time?
For a local resolver, under 30 ms is good, 30 to 80 ms is acceptable and over 80 ms is a problem. For lookups that cross regions, the ranges stretch to under 60 ms, 60 to 120 ms and over 120 ms. Check the first uncached lookup and the repeats separately, since the first is always slower.
Why is my DNS resolution slow?
Common causes are a distant or overloaded ISP resolver, a weak router cache, packet loss on Wi-Fi, and cold caches for rarely visited sites. Test over a wired connection and against a second resolver to see which part is at fault. If every resolver is slow, the problem is your connection, not DNS.
How do I measure DNS response time?
On Mac or Linux, run dig example.com +stats and read the query time. On Windows, use nslookup or Resolve-DnsName. For repeated queries with minimum, maximum, average and jitter, use dnsping, and run at least three passes before comparing resolvers.
Will changing DNS fix lag in games or video calls?
Usually not. DNS affects the moment a connection starts, such as logging in or joining a call, not the ping or jitter during it. If lag happens mid-session, test latency, jitter, packet loss and bufferbloat instead.
Sources
- What Is DNS Latency? Why It Happens & How To Measure It (IO River)
- Understanding latency (MDN)
- Performance Benefits, Public DNS (Google for Developers)
- What Is DNS Lookup Time & How to Reduce It? (Sematext)
- How to fix slow DNS lookup in enterprise networks (ManageEngine)
- How to Make the Internet Faster for Everyone (Cloudflare)
- dnsping(1), dnsdiag (Debian Manpages)
- dnsperf README (DNS-OARC)
- dnsperftest.sh (hagezi)
- Best Practices (Net-Benchmark)
- A Framework for DNS Resolution Latency Measurement (IETF)
- DNS Benchmarking 101 (DNS-OARC 42)
- DNS resolver study (technical report, 2013)
- Can changing DNS affect ping time? (Super User)