How to Fix Slow DNS Lookups

A slow DNS lookup adds latency before anything else on your page even starts loading. The browser cannot request HTML, CSS, images, or scripts until it resolves the domain name to an IP address. If that resolution takes 200ms instead of 20ms, every single resource on the page is delayed by the difference.

DNS lookups are supposed to be fast. On a well-configured setup, they take 10-50ms. When they regularly exceed 100ms or spike into multi-second territory, something is wrong. This guide walks through the most common causes of slow DNS lookups and how to fix each one.

Why DNS Lookups Get Slow

DNS resolution involves multiple steps: your browser checks its local cache, asks the operating system, which asks a recursive resolver, which may query root servers, TLD servers, and authoritative nameservers. A slow result at any of those layers slows down everything downstream.

Here are the most common culprits.

Your ISP's Resolver Is Slow

Most devices are configured to use whatever DNS resolver the ISP provides. ISP resolvers are often underpowered, overloaded, or geographically distant from your users. They may also have smaller caches, meaning more queries end up doing full recursion instead of returning cached answers.

ISP resolvers are the single most common cause of slow DNS for end users. They are not optimized for speed the way dedicated public DNS services are.

High TTL With Stale Cache Entries

If your DNS records have very long TTLs and the cached entries have expired, the next lookup requires a full recursive resolution. That full trip through the DNS hierarchy can take 100-300ms depending on network conditions. With a short TTL and a warm cache, the same lookup returns in under 5ms.

The flip side: if TTLs are too short, the cache is always cold and every request triggers a fresh lookup. Finding the right balance matters. For more on this tradeoff, see DNS Caching and TTL.

Geographic Distance to Your DNS Provider

DNS is a network operation. If your authoritative nameserver is hosted in a single location in Virginia and your user is in Tokyo, the recursive resolver has to make a round trip across the Pacific to get an answer. Authoritative DNS providers with anycast networks (where the same IP is served from dozens of locations worldwide) eliminate this problem.

Your DNS Provider Is Having Issues

DNS providers can experience outages, degraded performance, or routing problems just like any other service. If your authoritative nameserver responds slowly or drops queries, every user experiences the delay. This is harder to diagnose because the problem is upstream and invisible unless you are actively monitoring resolution times.

Too Many DNS-Dependent Resources

Every unique hostname on your page triggers a separate DNS lookup. If your page loads resources from cdn.example.com, fonts.googleapis.com, analytics.example.com, api.example.com, and images.example.com, that is five DNS lookups before everything finishes loading. Each one adds to your total page load time.

How to Diagnose Slow DNS Lookups

Before you fix anything, measure the problem. You need to know which part of the DNS resolution is slow and whether the issue is consistent or intermittent.

Using dig

The dig command is the standard tool for DNS diagnostics. It shows you exactly how long each query takes.

dig example.com

Look at the Query time line at the bottom of the output:

;; Query time: 23 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)

If the query time is consistently above 100ms, you have a problem. To test against a specific resolver:

dig example.com @8.8.8.8
dig example.com @1.1.1.1
dig example.com @9.9.9.9

Compare the results. If one resolver is significantly faster, your default resolver is likely the bottleneck.

To trace the full resolution path and see where the delay happens:

dig +trace example.com

This shows each step of the recursive resolution, from root servers through TLD servers to the authoritative nameserver. You can pinpoint exactly which step is slow.

Using nslookup

On Windows or systems without dig, nslookup works for basic testing:

nslookup example.com
nslookup example.com 8.8.8.8
nslookup example.com 1.1.1.1

nslookup does not show query times by default, so it is less useful for performance diagnostics. Use it to confirm resolution works, then switch to dig or browser DevTools for timing data.

Using Browser DevTools

Chrome and Firefox DevTools show DNS lookup times for every request on the page.

A healthy DNS lookup in Chrome DevTools is under 20ms for cached results and under 50ms for uncached results. Anything above 100ms is worth investigating.

Using DNS Benchmarking Tools

Tools like namebench (from Google) and DNS Benchmark (from GRC) can test dozens of DNS resolvers and rank them by speed for your specific location and network. Run these to find the fastest resolver available to you.

How to Fix Slow DNS Lookups

Once you have identified the cause, apply the appropriate fix. Most environments benefit from multiple fixes applied together.

Switch to a Faster DNS Resolver

The single biggest improvement for most users. Replace your ISP's DNS resolver with a public DNS service optimized for speed.

You can change the DNS resolver at the device level (in network settings), at the router level (affects all devices on the network), or at the application level (some browsers let you configure DNS-over-HTTPS separately). For a deeper comparison, see Public DNS Providers Compared.

To change your DNS on most systems:

# Linux (systemd-resolved)
sudo nano /etc/systemd/resolved.conf
# Set DNS=1.1.1.1 8.8.8.8
sudo systemctl restart systemd-resolved

On Windows, go to Network Adapter settings and set the preferred DNS server to 1.1.1.1 and the alternate to 1.0.0.1.

On macOS, go to System Settings, Network, select your connection, click Details, then DNS, and add the resolver IPs.

Optimize Your TTL Values

TTL controls how long resolvers cache your DNS records. Setting it correctly reduces the number of full lookups.

For records that rarely change (MX records, NS records), set TTLs to 3600-86400 seconds. For records that may need to change quickly (A records for web servers), 300-3600 seconds is a good range.

Avoid TTLs under 60 seconds unless you have a specific need like active failover. Very short TTLs mean nearly every request requires a fresh lookup, which adds latency for all your users.

If you are planning a DNS change, lower the TTL in advance, make the change, then raise the TTL afterward. This is covered in detail in DNS Caching and TTL.

Enable Local DNS Caching

Operating systems cache DNS results, but the cache may not be enabled or configured properly.

On Windows, the DNS Client service handles caching and is enabled by default. Verify it is running:

sc query dnscache

On macOS, mDNSResponder handles DNS caching automatically.

On Linux, the behavior depends on your distribution. If you are running systemd-resolved, caching is built in. Otherwise, you may need to install a local caching resolver.

If your DNS cache gets corrupted or stale, flushing it forces fresh lookups. See How to Flush Your DNS Cache for platform-specific commands.

Run a Local DNS Resolver

For servers and advanced setups, running a local caching resolver like unbound or dnsmasq eliminates the network hop to an external resolver for cached queries. The cache sits on the same machine (or local network), so cached responses return in under 1ms.

# Install unbound on Ubuntu/Debian
sudo apt install unbound
sudo systemctl enable unbound
sudo systemctl start unbound

Then configure your system to use 127.0.0.1 as the DNS resolver. Unbound will handle caching locally and forward uncached queries to an upstream resolver of your choice.

This is especially valuable for servers making many DNS queries (mail servers, web crawlers, API services).

Use DNS Prefetching for Web Pages

If you control a website, you can tell browsers to resolve DNS for third-party domains before the user clicks any links. Add dns-prefetch hints to your HTML:

<link rel="dns-prefetch" href="https://cdn.example.com">
<link rel="dns-prefetch" href="https://fonts.googleapis.com">
<link rel="dns-prefetch" href="https://analytics.example.com">

This triggers DNS resolution during page idle time rather than at the moment the resource is needed. It does not fix slow DNS, but it hides the latency by resolving in advance.

Reduce the Number of DNS Lookups

Every unique domain on your page costs a DNS lookup. Consolidating resources onto fewer domains reduces total lookup overhead.

Instead of loading assets from five different subdomains, host everything on one or two. Instead of embedding third-party scripts from a dozen ad and analytics providers, evaluate whether each one is actually necessary.

For your own infrastructure, consider putting static assets on the same domain as your main site rather than a separate CDN subdomain. Modern HTTP/2 multiplexing makes the old advice of "domain sharding" obsolete anyway.

Choose a DNS Provider With Anycast

If you control the authoritative DNS for your domain, make sure your provider uses an anycast network. Anycast means the same IP address is announced from multiple points of presence around the world. When a resolver queries your authoritative server, it gets routed to the nearest node automatically.

Major DNS providers like Cloudflare DNS, AWS Route 53, Google Cloud DNS, and NS1 all use anycast. If you are using a small hosting provider's nameservers, they may only have servers in one or two locations. That single point of presence becomes a bottleneck for users far away from it.

Verifying Your Fixes

After applying changes, measure again. Run the same dig queries, check browser DevTools, and compare the numbers.

# Before fix
dig example.com @your-isp-resolver
;; Query time: 187 msec

# After switching to Cloudflare
dig example.com @1.1.1.1
;; Query time: 12 msec

For ongoing monitoring, track DNS resolution times over days and weeks. A one-time test tells you the current state, but DNS performance can degrade gradually as ISP infrastructure changes or your DNS provider has intermittent issues.

When Slow DNS Is Not Your Fault

Sometimes slow DNS is caused by factors outside your control:

• Your user's ISP resolver is slow, and you cannot change it for them. DNS prefetching and long TTLs help mitigate this.
• A third-party domain on your page has slow DNS. You can switch providers or remove the dependency, but you cannot fix their DNS.
• Network congestion between the resolver and your authoritative server. Anycast helps, but transient routing issues happen.

Monitoring DNS performance over time helps you distinguish between transient blips and persistent problems that need action. For a broader look at diagnosing DNS problems, see the DNS Troubleshooting Guide.

References

[1] Cloudflare. "1.1.1.1 Public DNS Resolver." https://developers.cloudflare.com/1.1.1.1/

[2] Google. "Google Public DNS: Get Started." https://developers.google.com/speed/public-dns/docs/using

[3] P. Mockapetris. "Domain Names - Implementation and Specification." RFC 1035, November 1987. https://datatracker.ietf.org/doc/html/rfc1035

Slow DNS lookups are one of the most overlooked performance bottlenecks. A few minutes of diagnostics and a resolver change can shave hundreds of milliseconds off every page load.