The Anatomy of DNS Latency

A DNS lookup is not one operation

When your browser resolves a domain name, it triggers a chain of network round trips, cache lookups, and — if DNSSEC is enabled — cryptographic validations. The total time depends on which parts of the chain are already cached and which require fresh queries across the internet.

Here is what contributes to the total lookup time:

Component	Typical latency	When it applies
Client-to-resolver RTT	1–20 ms (local), 10–80 ms (remote)	Every query
Resolver cache lookup	Under 1 ms	Every query (in-memory hash table)
Resolver-to-root RTT	5–30 ms	Cache miss for TLD delegation
Resolver-to-TLD RTT	10–50 ms	Cache miss for domain delegation
Resolver-to-authoritative RTT	10–100 ms	Cache miss for the actual record
DNSSEC validation	1–3 ms per signature	When the resolver validates signatures
TCP fallback	+1 RTT (30–100 ms)	When the UDP response is truncated
Packet loss retransmission	+1,000 ms average	DNS retransmit timer defaults to ~1 second

A cold-cache resolution — no cache hits anywhere in the chain — averages 300–400 ms, accounting for real-world packet loss, dead name servers, and misconfigurations.

A warm-cache resolution — the resolver has the answer cached — takes 1–20 ms, dominated entirely by the network round trip between your device and the resolver.

The difference is dramatic. Caching is the single most important optimization in the DNS ecosystem.

Cold versus warm cache

The cache state at the resolver determines which of these paths a query takes:

Scenario	Typical latency	What happens
Full cache hit	1–5 ms	Resolver returns the answer from memory
Partial cache hit (TLD cached)	30–80 ms	One additional RTT to the authoritative server
Complete cache miss	100–400 ms	2–4 RTTs through the full delegation chain
Cache miss + DNSSEC	200–700 ms	Additional RTTs for DNSKEY/DS fetches + validation
Cache miss + CNAME chain	200–600 ms	Multiply by chain depth

A recursive resolver handling 135,000 queries per second serves approximately 80–95% of queries from cache. Only 5–20% of queries take the expensive cold path. This is why large public resolvers — which see enormous query diversity — maintain warmer caches and deliver faster average response times than smaller resolvers.

DNSSEC: the biggest single source of added latency

DNSSEC validation is the most significant contributor to additional DNS latency. It affects resolution in two ways: extra round trips and cryptographic computation.

Chain of trust traversal

For a cold-cache DNSSEC-validated query to www.example.com, the resolver must:

1. Query root for .com NS records, fetch root DNSKEY, verify RRSIG
2. Query .com TLD for example.com NS, fetch .com DNSKEY, verify DS/RRSIG
3. Query example.com authoritative for the A record, fetch DNSKEY, verify RRSIG

Each zone in the chain requires fetching DNSKEY records and validating the DS (Delegation Signer) chain. This adds 2–4 additional round trips beyond a non-validating resolution.

Measured impact

Metric	Without DNSSEC	With DNSSEC
Server-side CPU	Baseline	+1–3 ms per cold query
Response size	~100–300 bytes	+200–800 bytes (RRSIG, DNSKEY)
Queries affected	—	~1–2% see measurable penalty
Serial DS query overhead	—	Doubles resolution from ~30 ms to ~60 ms
Traffic multiplier	1x	Up to 13x for fully signed zones

ISC’s 2022 benchmarks on a busy resolver showed DNSSEC validation added approximately 1 ms penalty for about 1–2% of queries — those that hit the cold-cache path. For the 80–95% served from cache, validation is effectively free because validated records are already cached.

The picture changes for smaller resolvers. Home resolvers performing DNSSEC validation must issue a separate DS query in addition to the initial A query, and most do these serially rather than in parallel — effectively doubling resolution time from ~30 ms to ~60 ms.

Truncation and TCP fallback

DNSSEC-signed responses with multiple RRSIG records can reach 1,800+ bytes, exceeding the typical IPv4 path MTU of 1,500 bytes. This causes UDP fragmentation (often dropped by middleboxes), triggering TCP fallback — which adds a full round trip. Measured median latency increases from 15 ms to 45 ms due to the TCP retry.

CNAME chains: latency multipliers

CNAME (Canonical Name) records create aliases. When CNAMEs chain — one CNAME pointing to another CNAME pointing to an A record — each hop requires an additional DNS resolution:

Chain depth	Additional RTTs	Typical added latency	Example
1 CNAME	+1	20–60 ms	www.example.com CNAME example.com
2 CNAMEs	+2	60–200 ms	CDN aliases through CloudFront
3+ CNAMEs	+3+	100–400 ms	Common with ad tech and analytics chains

Chains longer than 2 CNAMEs become a significant contributor to tail latency (p95/p99). CNAME flattening mitigates this — the authoritative server resolves the chain itself and returns the final IP directly in the A record response. Cloudflare and other providers support this at the zone apex.

Glue records: solving circular dependencies

Glue records address a bootstrapping problem: when a domain’s name servers are hosted under the domain itself (e.g., ns1.example.com is the nameserver for example.com), the resolver needs to look up ns1.example.com to find the nameserver — but it cannot resolve ns1.example.com without already knowing the nameserver.

With glue records, the parent zone (.com TLD) includes A/AAAA records for the nameserver alongside the NS delegation. The resolver receives the IP address in the Additional section of the referral response — zero extra RTTs.

Without glue records (out-of-bailiwick nameservers), the resolver must perform a separate resolution for the nameserver’s IP address, adding 1–3 additional RTTs (50–200 ms) depending on cache state.

When glue records are missing for in-bailiwick nameservers, resolution enters a circular dependency. The resolver may time out or fail entirely, recovering only if alternative nameservers are available.

Performance budget targets

Production DNS systems target:

• Under 50 ms at p50 (median)
• Under 150 ms at p95

Cache hit rates of 80–95% at major resolvers mean the cold-cache path (50–300 ms) is relatively rare at scale. But for the 5–20% of queries that miss the cache, the anatomy described above — root RTT, TLD RTT, authoritative RTT, potential DNSSEC validation, potential CNAME resolution — all compound into hundreds of milliseconds that directly delay the connection your application is waiting to make.