How to Fix Slow DNS Lookup

A slow DNS lookup feels like "the internet is slow", but it has a narrower meaning: your device is taking too long to turn a name like www.example.com into an IP address. The browser may sit still for a second or more before any real page loading begins.

Do not start by changing random DNS settings. First identify which layer is slow:

1. Browser or operating system cache.
2. Router, DHCP, VPN, or local DNS forwarder.
3. Recursive resolver, such as ISP DNS, 1.1.1.1, 8.8.8.8, or corporate DNS.
4. Authoritative DNS for the affected domain.

This guide gives you a practical test sequence and then the fixes for each result. For a broader symptom-first workflow, see DNS troubleshooting.

Quick Fix Checklist

1. Test the affected hostname twice from the slow device. Start with macOS or Linux or Windows.
2. Compare the configured resolver with a public resolver using the same name and record type. Check several names if the problem affects many sites.
3. Use the result table to identify the failing layer before changing settings.
4. Apply one matching fix below. Flush a local cache only for a local stale answer; check router or resolver settings when multiple devices are affected.
5. Repeat the original tests and compare both response time and answer correctness. Keep a working configuration you can restore.

Read the Result

Use the pattern below to decide where to look next.

Confirm DNS Is the Bottleneck

Slow DNS is most obvious when new websites pause before loading, but already-open streams, video calls, or downloads continue normally. That happens because DNS affects connection setup, not the throughput of an existing connection.

You can confirm in three ways.

Browser DevTools

Open your browser's Network tab, reload the page, and inspect the timing for the first document request. If the DNS lookup phase is large while connection and response phases are normal, DNS is part of the delay.

This is useful for browser-only complaints, but it does not isolate whether the delay comes from the browser, OS, router, or resolver.

macOS or Linux with dig

dig prints query timing at the end of its output:

dig example.com

Look for this line:

;; Query time: 42 msec

Run the query twice:

dig example.com | grep "Query time"
dig example.com | grep "Query time"

The second query may be faster if your resolver cached the first answer. If both are slow, compare resolvers:

dig example.com @1.1.1.1 | grep "Query time"
dig example.com @8.8.8.8 | grep "Query time"
dig example.com @9.9.9.9 | grep "Query time"

For more examples, see the dig tutorial.

Windows with PowerShell

Check which DNS servers Windows is using:

Get-DnsClientServerAddress

Measure a normal lookup:

Measure-Command { Resolve-DnsName www.example.com -Type A -DnsOnly -ErrorAction Stop } | Select-Object TotalMilliseconds

Compare a specific resolver:

Measure-Command { Resolve-DnsName www.example.com -Type A -DnsOnly -ErrorAction Stop -Server 1.1.1.1 } | Select-Object TotalMilliseconds
Measure-Command { Resolve-DnsName www.example.com -Type A -DnsOnly -ErrorAction Stop -Server 8.8.8.8 } | Select-Object TotalMilliseconds

Repeat each measurement and keep the returned answer or error as well as the elapsed time. PowerShell timing includes command overhead, so compare these results with each other rather than treating them as identical to dig query time.

You can also use nslookup:

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

Fix Browser and OS Cache

Local cache problems usually affect one browser or one device. They are common after changing networks, disconnecting a VPN, changing DNS records, or moving a domain to another provider.

Windows

Open Command Prompt or PowerShell as Administrator:

ipconfig /flushdns

PowerShell equivalent:

Clear-DnsClientCache

Then restart the browser. If you use Chrome or Edge, also clear the browser DNS cache:

chrome://net-internals/#dns
edge://net-internals/#dns

Click "Clear host cache", then open:

chrome://net-internals/#sockets
edge://net-internals/#sockets

Click "Flush socket pools" to close reused connections that may still point at old IPs.

macOS

Run:

sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

There is usually no success message. Restart the browser and test again.

Linux

If the system uses systemd-resolved:

sudo resolvectl flush-caches
resolvectl statistics

If it uses dnsmasq or nscd:

sudo systemctl restart dnsmasq
sudo systemctl restart nscd

Many Linux systems do not cache DNS at the OS level unless a resolver service is running. In that case, restart the application or browser instead.

For the cache layers behind these commands, read DNS cache explained.

Fix One Slow Device

If other devices on the same network resolve names quickly, focus on local configuration.

Check Configured DNS Servers

Windows:

Get-DnsClientServerAddress

macOS:

scutil --dns

Linux:

resolvectl status
cat /etc/resolv.conf

Look for:

• Old corporate DNS servers from a VPN.
• Unreachable private IPs like 10.x.x.x or 172.16.x.x when you are not on that network.
• A slow router IP as the only resolver.
• Multiple resolvers where the first one times out before the second works.
• Search domains that force extra failed lookups before the real name is queried.

Check VPNs and Virtual Adapters

VPN clients, Hyper-V, Docker, VMware, VirtualBox, and security tools can install network adapters and DNS rules. If a stale adapter still has DNS priority, each lookup may wait for a timeout before falling back.

If the affected public site does not require the VPN, compare with the VPN disconnected where your network policy allows it. Avoid disabling adapters needed for corporate access. Then test:

Measure-Command { Resolve-DnsName www.example.com -Type A -DnsOnly -ErrorAction Stop } | Select-Object TotalMilliseconds

If the delay disappears, fix the adapter DNS settings instead of changing public resolvers globally.

Check Hosts File and Security Software

A huge or malformed hosts file can slow local name handling. DNS filtering, antivirus, endpoint security, and parental-control software can also intercept DNS. Inspect the filter logs and compare the affected hostname with a known working one. On a managed device, have your administrator check the DNS policy or stale rules before changing protection settings.

Fix a Whole Slow Network

If phones, laptops, and desktops are all slow on the same network, the likely problem is upstream of the devices.

Restart and Update the Router

Home and small-office routers often act as DNS forwarders. Clients ask the router, and the router forwards the query to an ISP resolver or a configured public resolver. If the router's DNS forwarder is stuck, overloaded, or buggy, every client feels slow.

Restart the router. If the issue returns, update firmware and check whether clients can bypass the router DNS forwarder by using a known resolver directly:

dig www.example.com @1.1.1.1
dig www.example.com @8.8.8.8

If direct queries are fast but queries through the router are slow, change DHCP DNS settings so clients receive reliable resolvers directly, or replace the router DNS forwarder with a local resolver you control.

Check DHCP DNS Settings

Your DHCP server should hand out a deliberate resolver set. Avoid sending conflicting DNS options such as:

• Router IP plus Pi-hole IP when Pi-hole is expected to see all DNS.
• Old ISP resolver plus a new local resolver.
• Two private DNS servers where one is unreachable off VPN.
• IPv6 DNS servers you forgot to configure.

After changing DHCP DNS, renew the lease or reconnect clients so they receive the new settings.

Check Pi-hole, Unbound, dnsmasq, or Other Local Resolvers

If you run a local resolver, inspect its own latency and cache behavior.

On Linux with systemd-resolved:

resolvectl statistics

For Pi-hole, compare the local resolver with an upstream resolver. Replace the documentation-only address 192.0.2.53 with your Pi-hole address:

dig www.example.com @192.0.2.53
dig www.example.com @1.1.1.1

If the local resolver is slower, check its upstream DNS, blocklists, conditional forwarding, IPv6 configuration, and whether the device is overloaded.

Change or Benchmark Resolvers

Switching DNS providers can help, but do not assume one public resolver is fastest everywhere. Your location, ISP peering, Wi-Fi, router, and the resolver's cache state all matter.

Compare several resolvers from your own network:

for resolver in 1.1.1.1 8.8.8.8 9.9.9.9 208.67.222.222; do
  echo "$resolver"
  dig www.example.com @"$resolver" | grep "Query time"
done

Common public resolver addresses:

Choose based on consistent results, not one query. Run several rounds at different times. If your ISP resolver is fastest and reliable, using it is reasonable. If it is slow or flaky, switch to a public resolver at the device or router level.

Fix One Slow Domain

If every site is fast except one domain you control, the problem may be authoritative DNS or zone design.

Compare Recursive and Authoritative Answers

First find the nameservers:

dig NS example.com +short

Then query a public resolver and the authoritative nameserver directly:

dig www.example.com @1.1.1.1
dig www.example.com @8.8.8.8
dig www.example.com @ns1.example-dns-provider.net

If public resolvers are slow but the authoritative server is fast, resolver caching or routing may be the cause. If the authoritative query itself is slow, investigate the DNS provider or nameserver location.

Use the DNS lookup tool and DNS health check to inspect the public domain configuration. The network performance page shows provider latency from monitoring probes.

Reduce CNAME Chains

Each CNAME target may require another lookup. One CNAME is normal. Long chains add latency and more failure points.

Check the chain:

dig www.example.com CNAME +short
dig www.example.com A +trace

If you see multiple hops such as:

www.example.com -> app.example.net -> edge.vendor.net -> customer.cdn.net

consider flattening the chain where appropriate or using direct records for performance-critical names. See CNAME records explained.

Check TTL and Cache Misses

Very low TTLs can increase cache misses. That does not usually create multi-second lookups by itself, but it makes users hit authoritative DNS more often. If the authoritative path is slow, low TTLs expose that slowness more often.

For stable records, use sensible TTLs such as 300-3600 seconds for web endpoints and longer values for records that rarely change. See DNS TTL best practices.

Check DNSSEC

DNSSEC failures usually show up as SERVFAIL, but some users describe them as slow DNS because browsers pause before failing.

Compare normal and checking-disabled queries:

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

If +cd works but the normal query fails, DNSSEC validation is a likely cause; inspect the delegation, signatures, and any extended DNS error before changing DNSSEC settings. See SERVFAIL errors and how DNSSEC works.

Use Faster Authoritative DNS

Authoritative DNS performance matters when resolvers do not have your records cached. A good authoritative provider should have:

• Anycast nameservers close to major networks.
• Multiple independent nameservers.
• Low response times from the regions where your users live.
• Published monitoring or a status page.
• Fast support for authoritative timeouts and SERVFAILs.

DNScale publishes independent probe-based DNS latency on the network performance page. For the underlying model, see DNS network performance monitoring and anycast DNS networks.

Prevent Slow DNS Lookup From Returning

After the immediate fix, make the configuration harder to break again.

Keep DNS Settings Simple

Every client should have a clear resolver path. For a home network, that may mean the router hands out Cloudflare, Google, Quad9, ISP DNS, or a local resolver. For an office, it may mean clients always use corporate DNS while on VPN and public DNS when off VPN.

Avoid half-configured mixtures. The most common slow-DNS pattern is not "bad DNS", but one unreachable resolver that times out before a good resolver answers.

Use Practical TTLs

TTL is the maximum time a resolver may cache a record before refreshing it. RFC 1035 defines TTL as the interval a record may be cached before it should be discarded. Long TTLs improve cache hit rates; short TTLs make changes visible sooner.

Use low TTLs temporarily during migrations. Raise them again after the change is stable.

Monitor Resolver and Authoritative Latency

For business-critical domains, monitor both:

• Recursive lookup from user-like networks.
• Direct authoritative query to your DNS provider.

Those two measurements answer different questions. Recursive checks show user experience. Authoritative checks show whether your DNS provider is responding quickly when caches miss.

Keep a Known-Good Test Set

Document three test commands for your team:

dig www.yourdomain.com @1.1.1.1
dig www.yourdomain.com @8.8.8.8
dig www.yourdomain.com @ns1.your-dns-provider.example

When someone reports "DNS is slow", run the same commands before changing anything.

References

• BIND dig documentation for resolver selection and query options.
• RFC 1035 for DNS TTL behavior.
• Microsoft Resolve-DnsName and Clear-DnsClientCache for Windows DNS diagnostics.
• systemd resolvectl for Linux cache and resolver commands.
• Cloudflare 1.1.1.1 docs and Google Public DNS docs for public resolver addresses.