How to optimize DNS performance

DNS resolution happens before anything else: before the TCP handshake, before TLS, before the first byte. A slow lookup adds dead time to the very front of every new connection, and on a typical page that pulls assets from a dozen hostnames, the cost multiplies. The flip side: DNS optimization is cheap. Most of the wins below take minutes to implement.

This guide covers both directions: making your machine or network resolve faster, and making your domain resolve faster for visitors.

Step 1. Measure current DNS lookup times

Optimize nothing until you've measured. dig reports query time directly:

$ dig example.com

;; Query time: 42 msec
;; SERVER: 192.168.1.1#53(192.168.1.1)

Two caveats when benchmarking:

• The first query is the honest one. Repeat queries hit the resolver's cache and come back in single-digit milliseconds regardless of how slow the resolver really is. To measure cold-cache performance, query names you haven't recently resolved, or compare different domains.
• Run each test several times. One sample tells you nothing; take five and look at the spread.

For the full picture of where DNS sits in your page load, curl breaks out the resolution phase:

curl -o /dev/null -s -w 'dns: %{time_namelookup}s  connect: %{time_connect}s  total: %{time_total}s\n' https://example.com/

A healthy uncached lookup is 10-50 ms. Consistently seeing 100 ms+ means the next two steps will pay off immediately.

Step 2. Choose the fastest DNS servers

Resolver performance varies a lot by location and network. Benchmark the candidates from where you actually sit:

for r in 8.8.8.8 1.1.1.1 9.9.9.9 208.67.222.222; do
  echo -n "$r: "
  dig example.com @$r | grep "Query time"
done

Run it a few times with different domains. The usual outcome: Cloudflare (1.1.1.1) and Google (8.8.8.8) trade first place depending on region, and both typically beat default ISP resolvers, not always on raw latency, but on cache hit rate and consistency. A huge public resolver has your record cached far more often than a small ISP one, and a cache hit beats a recursive walk by an order of magnitude.

Latency to the resolver is the floor for every uncached query, so it's worth checking the round-trip with a ping test too: if 1.1.1.1 is 8 ms away and your ISP resolver is 35 ms away, no amount of cache warmth saves the ISP resolver on misses.

Set the winner at the router level so every device on the network benefits, not just one machine.

Step 3. Implement DNS caching

Caching is what makes DNS fast in practice; your job is making sure each layer is actually doing it.

• OS level. macOS and Windows cache by default. On Linux, check that something is actually caching; resolvectl statistics shows cache hits if systemd-resolved is active. A bare /etc/resolv.conf pointing straight at an upstream with no local cache means every single lookup goes over the network.
• Network level. A caching resolver on your LAN (dnsmasq, Unbound, Pi-hole) answers repeat queries in under a millisecond and serves the whole network. For an office or a homelab, this is the single biggest win available.
• Application level. Many runtimes don't cache DNS at all by default; Node.js famously resolves on every request unless you add a caching agent (e.g. cachedLookup or keep-alive connection reuse). If your service makes thousands of outbound calls to the same API hostname, check whether each one pays the lookup tax.

Step 4. Reduce DNS lookup counts

The fastest lookup is the one that never happens. On the web side:

• Consolidate hostnames. Every unique hostname on a page costs a resolution (plus a TCP and TLS handshake). Ten asset domains means ten cold lookups for a first-time visitor. Fold assets onto fewer hostnames where you can.
• Audit third-party tags. Analytics, ads, fonts, and widgets each drag in their own domains, often chains of them. Remove what you don't use.
• Keep CNAME chains short. Each CNAME in a chain can trigger another resolution step. www → cdn-alias → cdn-edge resolves slower than a direct alias. One CNAME is normal; three deep is worth flattening.

On the backend, connection reuse (HTTP keep-alive, connection pools) eliminates repeat lookups along with repeat handshakes, usually a config flag, not a refactor.

Step 5. Optimize TTL values

TTL is the cache lifetime you grant the world, and it's a straight trade-off between speed and agility:

• Long TTL (3600-86400s): more cache hits everywhere, fewer queries reaching your nameservers, faster average resolution for visitors. Right for stable records: MX, NS, TXT, and A records that rarely move.
• Short TTL (60-300s): fast failover and quick changes, at the price of constant re-resolution. Right for records behind load balancers or anything you might need to repoint in a hurry.

The common mistake is leaving everything at 300 seconds because that's what the provider defaulted to. If an A record hasn't changed in a year, a 300-second TTL means the entire internet re-resolves it 288 times a day for no benefit. Raise stable records to 3600+ and you make every visitor's cached-lookup probability dramatically better. Check current TTLs with the DNS Lookup tool; the TTL is reported alongside each record.

(For planned migrations, do the reverse: lower the TTL ahead of time. See how to check DNS propagation.)

Step 6. Use DNS prefetching

Browsers can resolve hostnames before the user clicks, hiding lookup latency entirely:

<link rel="dns-prefetch" href="https://cdn.example.com">
<link rel="preconnect" href="https://cdn.example.com" crossorigin>

dns-prefetch does just the lookup; preconnect also opens the TCP and TLS connection. Use preconnect for the two or three origins you're certain the page will hit (your CDN, your API), and dns-prefetch as the cheap fallback for likely-but-not-certain origins. Don't preconnect to everything; speculative connections have their own cost and browsers cap them.

Step 7. Monitor DNS performance over time

DNS performance regresses quietly: a provider migration doubles authoritative latency, a new marketing tag adds four hostnames, a teammate drops a TTL to 60 "temporarily" and forgets. Two habits keep it honest:

• Re-run the step 1 measurements after any DNS or CDN change, and keep the numbers somewhere you can compare.
• Watch the records themselves. TTL and record changes are exactly the kind of silent edits a DNS record drift monitor catches: it alerts with a diff when your record set changes, so a "temporary" TTL drop doesn't live on for six months unnoticed.

TL;DR

1. Measure first: dig example.com and read the query time; 10-50 ms uncached is healthy.
2. Benchmark resolvers (dig @8.8.8.8, @1.1.1.1, ...) from your own network and set the winner at the router.
3. Make sure something caches at every layer: OS, LAN resolver, and your application runtime.
4. Cut lookup counts: fewer hostnames per page, fewer third-party tags, shorter CNAME chains, connection reuse.
5. Raise TTLs on stable records (3600+); keep short TTLs only where you genuinely need fast failover.
6. Add dns-prefetch/preconnect hints for origins the page will definitely hit.
7. Re-measure after changes and monitor records for drift so regressions don't accumulate silently.