When DNS Is Slow or Not Resolving

DNS failures look like everything else being broken. Here is how to confirm DNS is actually the problem, find which part of the chain is failing, and fix it.

DNS problems rarely announce themselves as DNS problems. What you notice is that one site will not load while others are fine, or that every page hesitates for two seconds before anything happens, or that a change you made hours ago still has not taken effect. The connection tests clean. The speed test is fine.

Almost every connection begins with a name lookup, so when that lookup is slow or fails, the symptoms appear everywhere except where the fault actually is.

### Check the chain, not just the answer DNS lookup queries any record against the resolver of your choice, and DNS trace follows resolution from the root servers down — which is where a slow or broken delegation becomes visible. Run a DNS trace →

First: confirm it is actually DNS

This takes fifteen seconds and saves a great deal of misdirected effort.

Try reaching something by IP address instead of by name:

ping 1.1.1.1          # by address — bypasses DNS entirely
ping one.one.one.one  # by name — requires DNS

• Address works, name fails or is slow → DNS. Continue below.
• Both fail → not DNS. This is connectivity, and the packet loss guide is the right starting point.
• Both fine, but browsing is still slow → also not DNS. Look at loss, jitter and latency under load.

A more precise version is to time a lookup directly:

Windows          nslookup example.com
macOS / Linux    dig example.com

dig prints a Query time line. Under 50 ms is healthy for a cached answer; anything over 200 ms consistently means something in the chain is struggling. Repeat the same query twice — the second should be far faster if caching is working at all.

How resolution actually fails

DNS is a chain: your device, your router, your resolver, the root and TLD servers, and the domain's authoritative nameservers. Each link fails differently.

Slow resolution

A distant or overloaded resolver. Your ISP's default resolver is not always the closest or the fastest. Comparing query times against a public resolver takes seconds:

dig example.com @1.1.1.1
dig example.com @8.8.8.8
dig example.com          # your current resolver

If your ISP's resolver is consistently several times slower, that is your answer.

A dead nameserver in the delegation. If a domain lists four authoritative nameservers and one no longer responds, roughly a quarter of lookups wait for a timeout before failing over — typically five seconds. The domain works, but unpredictably slowly. A DNS trace exposes this because it queries the chain step by step and times each one.

No caching. Very short TTLs force a fresh lookup for almost every connection. That is a decision the domain owner made, and there is nothing you can do about it from the client side.

IPv6 fallback delays. A device that asks for an AAAA record on a network with broken IPv6 may wait for a timeout before falling back to IPv4. The symptom is a consistent delay of a second or two before every new connection, on some networks and not others.

Intermittent failures

Names resolving most of the time and failing occasionally is usually one of:

• One unhealthy nameserver out of several, as above. This is a frequent cause of "it works, just not always", and it stays invisible unless you query each nameserver individually rather than trusting whichever one answered first.
• UDP packet loss. DNS uses UDP by default, and a query or response that goes missing simply times out. If you have packet loss, it will show up as intermittent DNS failures alongside everything else.
• Rate limiting. Some resolvers throttle clients making a lot of queries, which can affect a busy household or an office behind one address.

Stale answers after a change

You updated a record hours ago and half the world still sees the old one. This is caching working as designed rather than a fault.

Every record carries a TTL controlling how long resolvers may keep it. A record with a 24-hour TTL can legitimately be served from cache for a full day after you change it. Checking what different resolvers currently hold tells you how far propagation has got:

dig example.com @1.1.1.1 +noall +answer
dig example.com @8.8.8.8 +noall +answer
dig example.com @9.9.9.9 +noall +answer

The lesson for next time is to lower the TTL to 300 seconds a day before a planned change, then raise it again afterwards.

A name that resolves for others but not for you

This is nearly always local. Working outward:

• Your device's cache. Flush it — ipconfig /flushdns on Windows, sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder on macOS, sudo resolvectl flush-caches on most modern Linux.
• A hosts-file entry overriding DNS entirely. C:\Windows\System32\drivers\etc\hosts or /etc/hosts. Leftover entries from testing outlive their usefulness constantly.
• Your router's resolver. Many routers run a small caching resolver, and some are poor at it. Point a device directly at a public resolver to test.
• Filtering. Pi-hole, corporate policy, parental controls or a security product may be deliberately blocking the name. A blocked domain usually returns NXDOMAIN or an address pointing at a block page rather than timing out.

Resolution that succeeds but returns the wrong thing

Some ISPs intercept DNS. Two behaviours to know:

NXDOMAIN hijacking. Instead of returning "no such domain", the resolver returns the address of a search or advertising page. The tell is that a deliberately nonsense name resolves to something:

dig thisnamedoesnotexist-9182734.com

That should return NXDOMAIN. An address means your resolver is rewriting answers.

Transparent redirection. Some networks redirect all port 53 traffic to their own resolver regardless of what you configured. The DNS leak test shows which resolver actually answered — if you set 1.1.1.1 and something else replies, your queries are being intercepted.

Reading a DNS trace

A DNS trace walks the hierarchy: root servers → TLD servers → the domain's authoritative nameservers. Each step is timed, which turns "DNS is slow" into a specific link in the chain.

What to look for:

• A step that takes far longer than the others. That server is slow or distant.
• A step that times out and retries. Usually a nameserver listed in the delegation that no longer serves the zone — very common after a DNS provider migration where the old records were never removed.
• Different nameservers returning different answers. A zone that is inconsistent between its own nameservers produces symptoms that appear entirely random to users.
• A delegation pointing somewhere unexpected. If the TLD servers hand you nameservers you do not recognise, the domain's configuration is wrong, or worse.

Choosing a resolver

If your ISP's resolver is the problem, changing it is one of the few genuinely easy fixes in networking.

Two things worth knowing before you switch.

Proximity matters more than brand. A resolver physically near you can beat a famous one that is far away. Time them rather than assuming — the dig @resolver comparison above takes a minute.

CDN geolocation. Content networks use your resolver's location to decide which server to send you to. A resolver far from you can land you on a distant CDN node, making everything slightly slower even though DNS itself got faster. EDNS Client Subnet mitigates this, but not every resolver enables it.

Encrypted DNS

DNS over HTTPS and DNS over TLS encrypt your queries so the local network cannot read or modify them. Worth understanding what that does and does not change.

It prevents your ISP or local network from logging which domains you look up, and from tampering with the answers.

It does not prevent the resolver you chose from seeing everything — you have moved trust, not removed it. It also does not hide which sites you visit from the network entirely, since the connection that follows still reveals the destination address, and often the hostname too. And it has no effect on TLS interception, which operates at a different layer.

One practical wrinkle: browsers with DoH enabled may bypass your system resolver entirely, which means Pi-hole and corporate filtering stop applying — and makes DNS troubleshooting confusing, because the browser and the rest of the system are using different resolvers.

A ten-minute checklist

1. Ping an IP, then a name. Different results confirm DNS.
2. Time a lookup with dig and repeat it — the second should be faster.
3. Compare resolvers — yours against 1.1.1.1 and 8.8.8.8.
4. Flush the local cache and check /etc/hosts for stale overrides.
5. Run a DNS trace to find which link in the chain is slow.
6. Query each authoritative nameserver individually to catch one that is unhealthy.
7. Check for interception with a nonsense-name lookup and the DNS leak test.

Frequently asked questions

How do I know if my problem is DNS or my connection?

Ping an IP address and a hostname. If the address responds and the name does not — or takes noticeably longer — the problem is name resolution. If both fail, it is connectivity, not DNS.

Why is DNS slow on my network but fast on my phone?

Usually a different resolver. Mobile networks assign their own, and your phone may also be using encrypted DNS through the browser. Compare query times with dig @1.1.1.1 against your default resolver to see whether the resolver is the difference.

How long do DNS changes take to propagate?

Up to the record's TTL, which is set by the domain owner. A 24-hour TTL means resolvers may legitimately serve the old value for a full day. Lower the TTL to a few minutes a day before a planned change so the switch happens quickly.

Why does one website not load when everything else works?

Check whether it resolves at all. If the lookup fails, it may be filtering (Pi-hole, corporate policy, security software), a stale local cache, or an actual problem with that domain's nameservers. If it resolves but does not load, the fault is beyond DNS.

Should I change my DNS server?

Only if you have measured that yours is slow. Public resolvers are often faster than an ISP's, but not always — proximity matters more than reputation, and a distant resolver can also worsen CDN routing. Time them before switching.

Does changing DNS make my internet faster?

It can reduce the delay before each new connection begins, which makes browsing feel more responsive. It does not change your bandwidth, and it will not fix packet loss, jitter or latency. Those are different problems with different causes.

What does it mean when a nonsense domain still resolves?

Your resolver is rewriting NXDOMAIN responses, usually to a search or advertising page. It means answers are being modified in transit, which is worth knowing about — switching to a resolver that does not do this restores correct behaviour.

Can packet loss cause DNS failures?

Yes. DNS uses UDP by default with no retransmission at the protocol level, so a lost query or response simply times out. Intermittent DNS failures alongside other symptoms usually point at packet loss rather than a DNS-specific fault.