DNS Resolver

Requirements

The approach

A hierarchy (root → TLD → authoritative) walked by recursive resolvers that cache aggressively by TTL; anycast routes users to the nearest resolver; results cached at every layer.

Key components

Client → recursive resolver (cache) → root/TLD/authoritative

Numbers that matter

• A cold DNS resolution walks 3 hops (root → TLD → authoritative); each adds ~10–50 ms RTT, making a worst-case first lookup add 100+ ms.
• Root servers handle ~1 trillion queries/day globally, but serve only ~2% of them — caching at recursive resolvers absorbs the other 98%.
• Cloudflare 1.1.1.1 answers ~90% of queries in <4 ms — the remainder require upstream fetches; p99 latency stays under 50 ms globally.
• A DNSSEC validation chain adds 2–5 additional queries per resolution (DS + DNSKEY records per zone level), roughly doubling lookup time.

Senior deep-dive

DNS is a globally distributed cache hierarchy — the recursive resolver does the work so authoritative servers don't have to serve every client.

TTL is the consistency knob: short TTLs (60s) enable fast failover but hammer resolver caches; long TTLs (86400s) make propagation of changes dangerously slow — choose based on how fast you need to fail over, not on default values.

Anycast routing collapses latency by advertising the same IP prefix from multiple PoPs — the BGP topology routes each client to the nearest one without any application-layer logic.

The resolution hierarchy: who does the actual work

A stub resolver (OS, browser) asks the recursive resolver (ISP or 8.8.8.8), which walks the hierarchy if its cache is cold: root → TLD → authoritative. The recursive resolver caches every hop's response by TTL, so it only recurses for cold or expired entries. Authoritative servers hold the ground truth and see only a fraction of actual query volume — the recursive layer is the real scale buffer.

Anycast: one IP, many servers

Anycast announces the same IP prefix from multiple data centers via BGP. Routing protocol topology, not DNS, selects the nearest server — a client in Singapore hits a Singapore PoP, one in London hits a London PoP. This gives sub-millisecond resolver latency within a region and automatic failover (BGP withdraws the prefix from a dead PoP). The subtlety: BGP routing isn't always geographically optimal — a user's ISP may have a suboptimal route to a nearer PoP.

TTL and the propagation vs. agility tradeoff

TTL is the only tool you have for consistency. Long TTLs (hours–days) mean low authoritative server load, high cache hit rates, and cheap operation — but changes take hours to propagate globally. Short TTLs (60–300s) enable rapid failover (e.g., health-check-driven routing) but generate 100x more recursive queries and increase resolution latency on cache miss. The right answer: lower TTLs 24 hours before a planned change, restore after.

Negative caching: the invisible footgun

NXDOMAIN (non-existent domain) responses are also cached by TTL — called negative caching (RFC 2308). If you deploy a new subdomain and a resolver already cached its NXDOMAIN, clients will fail to resolve it until the negative TTL expires. Negative TTL is set in the SOA record and defaults to hours in many configs. This bites teams deploying new services under existing zones without pre-warming resolvers.

DNSSEC: correctness vs. operational pain

DNSSEC adds cryptographic signatures (RRSIG records) to every DNS response, letting resolvers verify authenticity. The chain of trust runs from IANA's root KSK through ZSKs at each zone level. Key rollover is the operational pain point: rotating a Zone Signing Key must happen in a coordinated sequence (pre-publish → active → retire) over multiple TTL windows; rushing it breaks validation globally. Many large operators (CDNs, internal services) choose not to enable DNSSEC due to this complexity.

What breaks at scale

Cache poisoning at the recursive level (Kaminsky attack) was the defining DNS vulnerability — fixed by randomizing source ports + query IDs, but still a concern for DNS-over-UDP. Amplification DDoS abuses open resolvers: a forged UDP query returns a response 50–100x larger to the victim — mitigation is blocking open recursion and using Response Rate Limiting (RRL). In Kubernetes, CoreDNS becomes a SPOF when it's under-replicated: a burst of service discovery lookups during a deployment can spike CPU to 100% and make the entire cluster unable to resolve internal services.

In production

Cloudflare, AWS Route53, and Google Cloud DNS all use anycast combined with a distributed authoritative tier — a query to 8.8.8.8 may be answered by a server in one of hundreds of PoPs. CoreDNS (the Kubernetes in-cluster resolver) illustrates the in-cluster case: every service lookup hits CoreDNS before going external, making it a shared hot path. The real operational challenge is TTL misconfiguration: organizations with 86400-second TTLs during a datacenter migration discover their old IP serves traffic for 24 hours after the DNS change, forcing them to pre-reduce TTLs days in advance.

Common mistakes

• No caching (overload authoritatives)
• Ignoring TTL semantics
• Single resolver (SPOF) instead of anycast

Related System Design Library