LiveChat 
Support 
How to Fix Slow DNS Lookups: Diagnose the Real Cause
When a page feels slow before anything has even loaded, the culprit is often invisible: DNS lookup time. This is the delay that happens *before* a connection is established, while the browser translates a domain name into an IP address. Nothing downloads, nothing renders, nothing happens until that resolution completes.
The good news is that slow DNS is one of the most diagnosable performance problems you’ll meet. If you measure it correctly, you can almost always point to a single root cause. My approach is methodical: measure first, isolate the layer that’s slow, then fix that layer specifically. Below, I’ll walk you through how to do exactly that.
Key Takeaways
• DNS lookup time is the delay before a connection starts, while a domain name is resolved to an IP address.
• Measure it with `dig` (look at Query time) or your browser’s DevTools (the DNS phase in the network waterfall).
• There are two different “slow DNS” problems: a slow *client-side resolver* (affects only you) and slow *authoritative nameservers* (affects every visitor worldwide).
• Use `dig` from multiple locations to tell them apart: slow only for you means the resolver; slow everywhere means your authoritative DNS.
• Common fixes include switching to a fast public resolver, using an Anycast authoritative DNS provider, tuning TTLs sensibly, and cutting unnecessary third-party lookups.
What exactly is a DNS lookup, and why does it slow things down?
Every connection to a website starts with a question: *what IP address belongs to this domain name?* The browser asks a resolver, which (if it doesn’t already know the answer) walks up the DNS hierarchy until it reaches the domain’s authoritative nameservers and gets a definitive reply.
That whole round trip is the DNS lookup. Until it finishes, the browser cannot open a TCP connection, cannot start TLS, and cannot request a single byte of your page. A lookup that takes 200ms instead of 20ms adds nearly a fifth of a second of dead air to the start of every fresh visit.
The frustrating part is that DNS lookup time is easy to overlook. It doesn’t show up in your server logs, and it’s not something your application code controls. You have to go looking for it.
How do you measure DNS lookup time?
Before changing anything, measure. Guessing at DNS problems wastes hours.
Using dig
`dig` is the most precise tool for this. Run it against your domain:
“` dig darazhost.com “`
Look at the line near the bottom:
“` ;; Query time: 24 msec ;; SERVER: 1.1.1.1#53(1.1.1.1) “`
Query time is the headline number. It also tells you which SERVER (resolver) answered. Run the command a few times. The first query may be slow; subsequent ones are often near-instant because the answer is now cached.
To bypass the cache and see what an *uncached* lookup really costs, trace the full resolution path:
“` dig darazhost.com +trace “`
This shows each hop from the root servers down to your authoritative nameservers, so you can see *where* the delay accumulates.
Using nslookup
On systems without `dig`, `nslookup` works too:
“` nslookup darazhost.com “`
It’s less detailed, but it confirms which server is answering and whether resolution succeeds at all.
Using the browser and webpagetest
In Chrome or Firefox DevTools, open the Network tab, reload, and click any request. The timing breakdown shows a distinct DNS Lookup phase. Tools like WebPageTest display the same phase in their waterfall and let you test from multiple geographic locations at once, which is exactly what you need for the next step.
Is it your resolver or your nameservers? (the question that matters most)
This is the single most important distinction in DNS troubleshooting, and most guides skip it. There are two completely different “slow DNS” problems, and they have opposite fixes.
- Client-side slowness. Your resolver (often your ISP’s, or your office network’s) is slow or distant. This affects *you and people on your network*, but not the wider world. The fix lives on the client side.
- Authoritative-side slowness. Your domain’s own authoritative nameservers are slow, overloaded, or geographically distant from your visitors. This makes the *first* lookup slow for *every visitor worldwide*. The fix lives on your domain’s DNS hosting.
Here’s the diagnostic test that tells them apart. Run `dig` for your domain from your own machine, then run it from a different network or location (a remote server, a colleague abroad, or WebPageTest’s multi-location test):
- Slow for you, fast from elsewhere → the problem is your resolver. Switch your client’s DNS to a fast public resolver.
- Slow everywhere → the problem is your authoritative nameservers. You need faster, better-distributed authoritative DNS.
Getting this wrong is how people waste a weekend. If you change your authoritative DNS host because *your* lookups felt slow, but the real issue was your ISP’s resolver, you’ve solved nothing for your visitors and possibly introduced new risk for no benefit. Diagnose the layer first.
What are the common causes of slow DNS, and how do you fix each?
Here is the diagnostic table I keep coming back to. Match your symptom to a cause, confirm it, then apply the matching fix.
| Symptom you observe | Likely cause | Fix |
|---|---|---|
| `dig` slow on your machine, fast elsewhere | Slow/distant resolver (ISP) | Switch the client to a fast public resolver (e.g. 1.1.1.1 or 8.8.8.8) |
| Lookups repeat constantly, no caching benefit | Very low TTLs | Raise TTLs to sensible values for stable records |
| `dig +trace` slow at the final hop; slow everywhere | Slow authoritative nameservers | Move to a fast, Anycast authoritative DNS provider |
| Every lookup is full-cost, even repeats | No local caching / cache disabled | Enable OS or local resolver caching |
| Intermittent slowness, packet loss | Network issues | Check the path with `traceroute`/`mtr`; fix routing or hardware |
| Many third-party domains on the page | Too many DNS lookups | Reduce third-party requests; add `dns-prefetch` |
| One hostname triggers several lookups | Long CNAME chains | Flatten CNAME chains; point closer to the apex |
Let me unpack the ones that trip people up most.
A slow or distant resolver (client side)
If your test showed slowness only for you, your resolver is the suspect. ISP resolvers vary wildly in quality and proximity. Switching the client device or network to a well-run public resolver such as 1.1.1.1 or 8.8.8.8 frequently cuts query time dramatically. This is a *client-side* fix: it speeds up *your* browsing, not your visitors’ experience of your site.
TTLs: low ones hurt, high ones don’t
A common myth is that high TTLs cause slow DNS. They don’t. A high TTL means resolvers cache your records longer, so lookups are *less* frequent, not slower. The real trap is the opposite: very low TTLs (say, 30 or 60 seconds) force resolvers to re-fetch your records constantly, and every re-fetch is a fresh round trip to your authoritative nameservers. Keep TTLs low only while you’re actively migrating; otherwise tune them up to sensible values for stable records.
Slow authoritative nameservers (your site’s side)
If `dig +trace` crawls at the final hop and your domain is slow to resolve from *everywhere*, your authoritative DNS is the bottleneck. Single-location nameservers force distant visitors to make a long round trip on their very first visit. The fix is an Anycast authoritative DNS network, where the same nameserver IP is announced from many locations worldwide and each visitor reaches the nearest one. This shrinks that critical first-lookup latency for a global audience.
Too many lookups and CNAME chains
Even with fast DNS, a page that references a dozen third-party domains needs a dozen lookups. Audit your page for unnecessary third-party scripts and fonts. For the ones you keep, add a resolver hint in the `
`:“`html “`
This tells the browser to resolve that hostname early, in parallel, so the lookup is already done by the time the resource is needed. Separately, watch for long CNAME chains (a CNAME pointing to a CNAME pointing to another), since each link can add its own lookup. Flatten them where you can.
How DarazHost helps you resolve fast worldwide
Once you’ve diagnosed an *authoritative-side* problem, the fix is infrastructure, and that’s where your hosting choice matters. DarazHost runs hosting backed by fast, reliable authoritative DNS, so visitors resolve your domain quickly no matter where in the world they are, keeping that all-important first lookup short.
You also get straightforward DNS management with sensible default TTLs, so you’re not fighting a clunky control panel when you need to tune a record or flatten a CNAME. And because DNS problems can be subtle, our 24/7 support can help you read a `dig` trace and isolate whether the slowness is on your authoritative DNS or somewhere else entirely. Pair that with fast underlying infrastructure, and the time between “visitor clicks” and “page starts loading” stays as short as it should be.
Frequently asked questions
What is a good DNS lookup time?
Lower is always better, and well-configured DNS typically resolves in a small number of milliseconds from a nearby resolver. The exact figure varies by network and distance, so focus on the *trend*: if your Query time in `dig` is consistently high, or far higher from some regions than others, that’s your signal to investigate.
Does changing my DNS resolver speed up my website for visitors?
No, and this is the most common misunderstanding. Changing *your* resolver (to 1.1.1.1 or 8.8.8.8) speeds up *your own* browsing. It does nothing for your visitors, because they use their own resolvers. To speed up resolution for visitors, you must improve your domain’s authoritative DNS.
Why is my first visit slow but reloads are fast?
That’s caching at work. The first lookup makes a full round trip to your authoritative nameservers; the result is then cached by your resolver and OS for the duration of the TTL, so repeat lookups are near-instant. If first visits are consistently slow, your authoritative DNS is likely the cause.
How do I know if DNS or the server is the slow part?
Use the timing breakdown in browser DevTools or WebPageTest. The DNS phase and the connect/wait phases are shown separately. If the DNS phase is large, the problem is resolution. If DNS is small but the wait time is large, your server or application is the bottleneck, not DNS.
Can a low TTL cause slow DNS?
Indirectly, yes. A very low TTL means resolvers can’t cache your records for long, so they re-query your authoritative nameservers far more often. Each of those re-queries is a fresh lookup. Raising TTLs to sensible values for stable records reduces this load and improves perceived speed.
