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.

Diagnose DNS in under a minute

DNS lookup queries any record against the resolver of your choice. DNS trace follows resolution from the root servers down, which is where a slow or broken delegation becomes visible.

Run a DNS lookup → · 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 work normally, but browsing is still slow → DNS is less likely to be the primary problem. Investigate latency, loss and routing, or application and browser behaviour, next. DNS can still contribute to how slow browsing feels even when one lookup measures fine, so this narrows the field rather than closing it.

A more precise version is to time a lookup directly:

Windows          nslookup example.com
Windows (PS)     Resolve-DnsName example.com
macOS / Linux    dig example.com

dig prints a Query time line. For a cached answer, tens of milliseconds is generally reasonable, and consistently seeing hundreds of milliseconds is a good reason to investigate. Treat both as guidelines rather than thresholds — there is no universal figure, because resolver location, caching state, transport and network conditions all vary. Repeat the same query twice: the second should be noticeably faster if caching is working at all.

The ten-minute checklist

If you want the short version, this is the whole diagnosis. The rest of the article explains why each step works.

1. Ping an IP, then a name. Different results confirm DNS.
2. Time a lookup with dig or Resolve-DnsName 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.

What your symptoms suggest

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 one of a domain's authoritative nameservers stops responding, some recursive resolvers will periodically select it and wait for a timeout — often around five seconds — before retrying another. How often that happens depends on the resolver: most track per-server response times and health, so they learn to avoid a dead server, but they still re-probe it periodically. The result is a domain that 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 exact behaviour depends on the operating system and application — many modern clients use connection-racing mechanisms such as Happy Eyeballs, which substantially reduce the impact of a broken IPv6 path. Where it does occur, 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 has to be retried after a timeout. If you have packet loss, it will show up as intermittent DNS slowness and 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.

Intermittent failures can equally come from your own resolver or router rather than the domain's infrastructure, so compare the same lookup against several resolvers before concluding the authoritative servers are at fault.

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

If you control the record, lowering the TTL well before a planned change reduces how long recursive resolvers are permitted to cache the old value — 300 seconds is a common choice — and you can raise it again afterwards. Note this shortens the permitted cache lifetime rather than guaranteeing every resolver worldwide updates on schedule.

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.

What is 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. If you explicitly send queries to 1.1.1.1 but consistently receive answers from an unexpected resolver, that is evidence of interception or redirection somewhere in the path — or of local configuration overriding what you set. The DNS leak test shows which resolver actually answered.

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. The command-line equivalent is:

dig +trace example.com

which performs iterative lookups down the hierarchy from the root rather than asking your resolver for a final answer.

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 DNS queries between your device and the resolver you chose, which makes it substantially harder for the local network to read or modify those requests. Worth being precise about the limits.

They do not hide your DNS activity from the resolver itself. Whoever operates it receives every query — you have moved trust, not removed it.

They do not make the rest of your browsing invisible to the network. The connection that follows still reveals the destination address, and frequently the hostname too. And they have no effect on TLS interception, which operates at a different layer.

One practical wrinkle: browsers with DoH enabled may bypass your system resolver entirely, so you can end up with two resolvers in play at once.

OS resolver      →  ISP resolver / Pi-hole
Chrome, Firefox  →  the browser's DoH provider

That means Pi-hole and corporate filtering stop applying to browser traffic, and it makes troubleshooting confusing — dig and nslookup can look perfectly healthy while the browser behaves differently, because they are not asking the same server.

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. Lowering the TTL a day before a planned change shortens how long the old value may be cached.

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 or jitter. Latency is a partial exception: a resolver that steers you to a nearer CDN edge can genuinely shorten the round trip to the content, which is why a distant public resolver sometimes makes things worse rather than better. 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 queries are sent over UDP by default, so a lost query or response is not recovered by the transport — the resolver has to wait for its own timeout and retry, which is why the symptom is usually a multi-second stall rather than an instant failure. Intermittent DNS problems alongside other symptoms usually point at packet loss rather than a DNS-specific fault.