A slow DNS lookup is not one problem. It is elapsed time accumulated across a path: your device reaches a recursive resolver, that resolver finds or retrieves an answer, and the browser may repeat the process for other hostnames used by the page.

You can shorten that path only after you identify which part is slow. Replacing hosting will not repair a poor route to a resolver. Switching resolvers will not repair a lame delegation. Raising a TTL will not make an uncached authoritative response travel faster.

This article builds a diagnosis from timings and controlled comparisons. It then matches the evidence to the device, resolver, network, domain, or website change that can fix it.

DNS delay has three clocks

The phrase “DNS lookup time” can describe three related measurements.

a) Device-to-resolver time

Your browser or operating system sends a question to a recursive resolver. The resolver may belong to your router, ISP, workplace, VPN, or a public DNS provider. Distance, routing, congestion, packet loss, filtering, and resolver load affect this leg.

b) Resolver work

A resolver answers quickly when it already has a valid record in cache. After a cache miss, it may contact root, top-level-domain, and authoritative nameservers. Google’s DNS performance documentation identifies cache misses, remote nameservers, overload, packet loss, and retransmission as major contributors to resolver latency.

c) Page-wide lookups

A page can contact its own hostname plus separate hosts for fonts, analytics, advertising, chat, video, payments, tag managers, and APIs.

Fast individual answers can still create a visible delay when dependencies force several new origins into the critical loading path.

That final case is not a slow lookup for the main domain. It is too much DNS work across the page. Keep the distinction clear because its fix belongs in the site architecture, not the domain’s nameserver settings.

Build a four-way test matrix

Do not change settings after one slow page load. Test the same hostname across four dimensions:

Dimension	Comparison	What it isolates
Device	Current device versus another device	Browser, local cache, adapter, security software
Network	Office or home network versus cellular or another ISP	Router, ISP resolver, VPN, filtering, route
Resolver	Current resolver versus named alternatives	Recursive service and path to it
Domain	Affected domain versus unrelated stable domains	Domain delegation or authoritative DNS

Keep the record type constant. An A query and an AAAA query may follow different routes and return different data. Keep the hostname constant too: example.com, www.example.com, and api.example.com are separate DNS names.

Record at least five results for each comparison. Note time, network, resolver, record type, response code, answer, TTL, and whether the result was the first or a repeated query. The first lookup may encounter a cache miss; a repeated lookup may not.

The pattern matters more than a universal threshold. A resolver that looks quick from one city or network can be slower from another. Google’s resolver guidance says network distance and routing to the serving resolver directly influence lookup speed.

Measure the browser’s DNS phase

Open Chrome DevTools, select Network, reload the page, choose a request, and inspect its Timing tab. Chrome separates queueing, DNS lookup, connection, TLS, request, waiting, and content download. Its Network reference documents those phases.

Do not blame DNS when the long bar belongs to Waiting for server response or content download. That points to the application, origin, network transfer, or hosting path. Our hosting speed article covers that layer.

For a repeatable command-line view, run:

curl -o /dev/null -s -w 'DNS: %{time_namelookup}s\nConnect: %{time_connect}s\nTTFB: %{time_starttransfer}s\nTotal: %{time_total}s\n' https://example.com/

On Windows PowerShell, use curl.exe and NUL:

curl.exe -o NUL -s -w "DNS: %{time_namelookup}s\nConnect: %{time_connect}s\nTTFB: %{time_starttransfer}s\nTotal: %{time_total}s\n" https://example.com/

The curl manual defines time_namelookup as time from the start until name resolution completes. Connection and first-byte timings include later stages.

Browser and curl results can differ. A browser may use Secure DNS, an internal cache, connection reuse, speculative resolution, or a service worker. Resource Timing exposes domainLookupStart and domainLookupEnd to web performance tools, but reused connections, cache state, and cross-origin privacy rules affect what a page can observe. The Resource Timing specification defines those fields.

Compare resolvers correctly

Windows can query a chosen resolver without changing the device’s permanent configuration:

Resolve-DnsName example.com -Type A -DnsOnly
Resolve-DnsName example.com -Type A -Server 1.1.1.1 -DnsOnly
Resolve-DnsName example.com -Type A -Server 8.8.8.8 -DnsOnly
Resolve-DnsName example.com -Type A -Server 9.9.9.9 -DnsOnly

On macOS, Linux, or a system with BIND tools:

dig @1.1.1.1 example.com A +stats
dig @8.8.8.8 example.com A +stats
dig @9.9.9.9 example.com A +stats

Repeat the set with several domains that resemble your real workload. One popular hostname often sits in every resolver’s cache and tells you little about cache-miss performance. One rare hostname can exaggerate a cold lookup.

Compare these outcomes:

• median response time, not just the fastest result;

• timeouts and unanswered queries;

• consistency across A and AAAA records;

• cold-looking versus repeated results;

• performance on each network you actually use; and

• required privacy, filtering, logging, and DNSSEC behaviour.

Do not select a resolver from ping time alone. Ping measures ICMP round-trip time, not recursive resolution. A nearby resolver can still queue queries or perform slow upstream work. A resolver with slightly more network distance can win when it has a useful cache and healthy authoritative routes.

If one service wins consistently across a representative test, try it temporarily on one device. Keep the former settings so you can restore them. Corporate, school, parental-control, and filtered networks may require their assigned resolver.

Fix a device-side delay

Device-side evidence looks like this: one device is slow, another device on the same network is normal, and direct tests against the same resolver differ.

Start with the narrowest change.

Clear one stale cache

On Windows:

Clear-DnsClientCache

The Command Prompt equivalent is:

ipconfig /flushdns

Microsoft cache documentation confirms that the two actions are equivalent. Flush once, then rerun the original comparison. Repeated flushing forces cold lookups and makes a performance test less representative.

macOS and Linux use different local resolvers across versions and distributions. Follow the current operating-system instructions for the resolver actually running on the device. Do not execute a random privileged command merely because it appears in an older tutorial.

Compare browser DNS

Chrome can use encrypted DNS independently of the operating system. In automatic mode, Chrome may fall back when secure lookup fails. With a custom provider, it does not use that automatic unencrypted fallback. Chrome settings explains the distinction.

Compare Chrome’s configured provider with the system resolver, but preserve organizational policies. A VPN, endpoint-security product, browser extension, or proxy can also intercept or reroute queries. Change one layer, retest, and restore required controls.

Inspect local software

Update the browser, operating system, network driver, VPN, and security software through their official channels. Review security logs before disabling protection. If an authorized diagnostic requires a short pause, restore the control immediately after the test.

Fix a network-side delay

Network-side evidence looks different: every device on one connection is slow, but the same devices work normally on another network.

First, identify which resolver the router distributes through DHCP. Compare direct queries to that resolver with public alternatives. If all external resolvers are slow from the affected connection, the route, firewall, packet loss, or DNS interception may be the real problem.

Test IPv4 and IPv6 separately where your tools allow it. A browser can appear inconsistent when one transport reaches the resolver through a poor path. Google documents cases where IPv6 resolution becomes slower because the network lands in a more distant serving location or follows a worse route.

Then compare DNS over UDP and TCP:

dig @8.8.8.8 example.com A
dig @8.8.8.8 example.com A +tcp

A small answer normally uses UDP. DNS switches to TCP in several cases, including truncated responses. Modern DNS infrastructure must support both transports; TCP requirements states that resolvers and servers must service UDP and TCP queries.

If UDP repeatedly times out while TCP works, investigate port 53 filtering, fragmentation, MTU, or middlebox behaviour. If TCP fails, check whether a firewall assumes DNS uses only UDP. Do not lower the MTU or open broad firewall ranges without confirming the network evidence.

Restart personal network equipment through its documented process when several devices share the problem. Do not factory-reset a managed router. Escalate persistent route or packet-loss evidence to the ISP or network administrator with timestamps, resolver addresses, record types, and command results.

Fix one slow domain

If unrelated domains resolve normally but one domain is slow across resolvers and networks, move from the client path to the domain’s delegation and authoritative service.

List the delegated nameservers:

dig example.com NS +short

Trace the referral chain:

dig +trace example.com A

+trace follows referrals from the root. It is a delegation diagnostic, not a benchmark of a normal cached user lookup. The BIND manual documents that distinction.

Query every authoritative server directly:

dig @ns1.example-dns.test example.com A +norecurse
dig @ns2.example-dns.test example.com A +norecurse

Repeat each query over UDP and TCP. Compare response codes, answers, TTLs, SOA serials, and reliability. A resolver may wait for one server, time out, and retry another. That retry makes an uncached lookup slow even when the second server answers quickly.

Correct these faults at the registrar or DNS host:

• parent and child zones list different NS records;

• required glue addresses are missing or stale;

• one authoritative server is unreachable;

• nameservers serve different zone versions;

• TCP queries fail;

• the domain expired or entered a hold status; or

• firewall and rate-limit rules block legitimate resolvers.

Google’s delegation checks explains why stale parent referrals and glue can break resolution. RFC 9199’s authoritative guidance also connects authoritative placement, peering, anycast design, and TTL policy to global latency and resilience.

Our DNS overview explains how nameservers and records divide these responsibilities. You can explore our domain services when you need registration or management options.

Check DNSSEC and response size

DNSSEC validation can expose a fault that non-validating tests miss. A broken chain often appears as SERVFAIL, but repeated validation attempts or oversized responses can also make the failure look slow.

Compare a normal validating query with a diagnostic query that sets the checking-disabled flag:

dig @8.8.8.8 example.com A +dnssec
dig @8.8.8.8 example.com A +dnssec +cd

If the second query succeeds while the first fails, inspect the DS, DNSKEY, and signature chain. The +cd test diagnoses validation; it is not a production fix. Google’s DNSSEC checks identifies stale DS records after DNS-provider changes as one common cause.

Inspect response size and TCP fallback for DNSKEY or large TXT answers:

dig @ns1.example-dns.test example.com DNSKEY +dnssec
dig @ns1.example-dns.test example.com DNSKEY +dnssec +tcp

When a large UDP response cannot arrive intact and TCP fallback also fails, resolvers retry and visitors see delays or failures. Repair transport and firewall behaviour. Do not remove DNSSEC simply to make the symptom disappear.

Reduce page-created DNS work

Open the browser Network panel and group requests by hostname. Count the origins needed before the main content appears. Remove an origin only after you identify what it supplies and whether the page still needs it.

Common candidates include duplicate analytics tools, unused chat widgets, old tag-manager containers, external fonts, advertising vendors, social embeds, and abandoned API integrations. Consolidating them reduces more than DNS work; it can also remove connections, TLS handshakes, scripts, and privacy exposure.

Inspect CNAME dependencies too:

dig www.example.com CNAME +short

Follow each target until it reaches address records. Remove aliases you control when they serve no current routing or verification purpose. Keep provider-required CNAMEs unless that provider supports another configuration; replacing a managed target with a fixed IP can break future changes.

Resource hints can start necessary work earlier:

<link rel="dns-prefetch" href="//static.example.net">
<link rel="preconnect" href="https://api.example.net" crossorigin>

The Resource Hints specification defines dns-prefetch as an early resolution hint and preconnect as early DNS, connection, and optional TLS setup. Add them only for critical origins the page will probably use. Too many hints compete for bandwidth, sockets, and browser attention.

This page-wide work overlaps with broader network issues, but it does not justify changing the main domain’s nameservers when those nameservers already answer well.

Use TTLs deliberately

TTL controls how long a resolver may cache a record. It does not control the network speed of an authoritative response.

Use longer TTLs for stable records when the operational benefit of more cache reuse outweighs slower changes. Use shorter TTLs when a record must change frequently or during a planned transition. Lower the old TTL before a migration and allow it to expire before switching the record.

Do not lower a TTL after a bad answer has already entered caches and expect immediate correction. Resolvers can reuse the old answer until its existing TTL expires. A newly created hostname can also remain hidden behind a cached negative answer. Negative caching uses SOA data to control that period.

TTL guidance summarizes the trade-off: longer caching can improve lookup reuse, while record changes take longer to reach users.

Match the fix to the evidence

Evidence	Owner	Fix
One browser differs from native tools	User or IT	Correct Secure DNS, extension, VPN, or browser policy
One device is slow	User or IT	Clear one stale cache; repair local networking or security software
One network is slow	Network owner or ISP	Correct resolver assignment, routing, filtering, packet loss, or transport
One resolver is consistently slow	User or network owner	Choose a tested resolver that meets policy and privacy requirements
One domain is slow everywhere	Domain or DNS operator	Repair delegation, glue, authoritative reachability, or zone consistency
Validating queries fail	Domain or DNS operator	Repair DNSSEC chain and response transport
Main hostname is fast but page DNS is high	Site owner	Remove unnecessary origins and add selective resource hints
DNS is fast but TTFB is slow	Application or hosting owner	Investigate server, database, application, and caching

After each fix, repeat the original matrix. Test the same hostname and record type on the original network, another network, multiple resolvers, and another region when the site has a global audience.

If a domain or DNS zone managed with us still shows slow or inconsistent answers, send the hostname, record type, timestamps, resolver addresses, networks, response codes, and command output through our support center. That evidence gives our team a reproducible starting point.