Low Level Design: DNS Resolution Internals

DNS (Domain Name System) is the internet’s distributed directory service — it translates human-readable hostnames like www.example.com into IP addresses that routers can use. Understanding DNS resolution internals is essential for designing reliable, low-latency systems and for diagnosing subtle networking failures.

DNS Hierarchy: Root, TLD, and Authoritative Nameservers

DNS is organized as a tree. At the top are 13 logical root nameserver clusters (operated by ICANN, Verisign, and others) distributed worldwide via anycast. Below them are TLD (top-level domain) nameservers for .com, .org, .net, country codes, etc. At the bottom are authoritative nameservers that hold the actual zone records for a domain. A full resolution typically traverses three levels: root → TLD → authoritative — usually 3 round trips from a cold cache.

Recursive vs. Iterative Resolution

There are two resolution modes. In recursive resolution, the stub resolver (on your OS) asks a recursive resolver (typically your ISP’s or a public one like 8.8.8.8) to do all the work. The recursive resolver contacts root, then TLD, then authoritative nameservers on the client’s behalf and returns the final answer. In iterative resolution, the resolver asks each level of the hierarchy, and each level responds with a referral to the next nameserver rather than the final answer. The resolver follows referrals until it gets an authoritative answer. In practice, stub resolvers use recursive mode; recursive resolvers perform iterative queries internally.

DNS Record Types

Key record types:

A: IPv4 address for a hostname
AAAA: IPv6 address
CNAME: canonical name alias — points one name to another; cannot coexist with other records at zone apex
MX: mail exchange server with priority
NS: nameserver delegation record
TXT: arbitrary text — used for SPF, DKIM, domain ownership verification
PTR: reverse DNS — maps IP address to hostname
SRV: service location record with port and priority — used by SIP, XMPP, Kubernetes
SOA: start of authority — contains serial number, refresh interval, and MINIMUM TTL for negative caching

Caching and TTL

Recursive resolvers cache responses for the duration specified by the record’s TTL (time to live). Caching dramatically reduces latency for repeat queries and shields root and TLD servers from load. TTL selection involves real tradeoffs: a low TTL (30–300 seconds) allows fast propagation of changes and supports DNS-based failover, but increases query volume to authoritative nameservers. A high TTL (3600–86400 seconds) reduces load and improves cache hit rate, but slows propagation when you change records. For DNS-based failover to work within a meaningful SLA, TTL must be 30–60 seconds — but this must be set before the failure, not after.

Negative Caching

When a query returns NXDOMAIN (name does not exist), that result is also cached — this is negative caching, defined in RFC 2308. The negative cache TTL is governed by the MINIMUM field in the zone’s SOA record. Without negative caching, every lookup for a nonexistent name would generate full recursive resolution. Negative caching prevents repeated expensive lookups for typos, non-existent subdomains, or names that legitimately don’t exist. Setting the SOA MINIMUM too low defeats this optimization; too high prevents quick recovery when a new name is added.

Anycast DNS

Anycast is a routing technique where the same IP address is announced from multiple physical locations via BGP. DNS queries are automatically routed to the topologically nearest node. Cloudflare’s 1.1.1.1, Google’s 8.8.8.8, and all 13 root nameserver clusters use anycast. Benefits: reduced latency (queries go to nearest PoP), resilience (if one node fails, BGP reconverges to the next-nearest), and DDoS absorption (attack traffic is absorbed across many PoPs rather than hitting a single target). Anycast is transparent to clients — they always use the same IP address.

DNSSEC: Cryptographic Chain of Trust

DNSSEC adds cryptographic signatures to DNS responses to prevent cache poisoning attacks (like the Kaminsky attack). The chain of trust works from root down: the root zone is signed with a root KSK (key signing key). Each TLD zone contains a DS (delegation signer) record pointing to the child zone’s DNSKEY. Each authoritative zone signs its records with RRSIG records. A validating resolver verifies the entire chain from root to record. Key record types: DNSKEY (public key for a zone), RRSIG (signature over a record set), DS (hash of child zone’s KSK, stored in parent), NSEC/NSEC3 (authenticated denial of existence). DNSSEC prevents spoofing but does not encrypt — it provides authenticity, not confidentiality.

DNS over HTTPS and DNS over TLS

Traditional DNS sends queries in plaintext UDP on port 53 — visible to any on-path observer (ISP, network admin, attacker on public Wi-Fi). DNS over TLS (DoT) wraps DNS in a TLS connection on port 853. DNS over HTTPS (DoH) sends DNS queries as HTTPS requests on port 443, making DNS traffic indistinguishable from regular web traffic. Both prevent eavesdropping and on-path manipulation. Tradeoff: DoH bypasses OS-level DNS configuration, which can break enterprise network controls, split-horizon DNS, and content filtering. Browsers like Firefox and Chrome have their own DoH implementations that can conflict with system DNS settings.

DNS-Based Load Balancing

DNS can distribute traffic across multiple servers by returning multiple A records. Common strategies: round-robin (return A records in rotating order), weighted routing (return different IPs with different probability), geolocation routing (return nearest datacenter based on resolver’s IP — used by AWS Route 53, Cloudflare), latency-based routing (measure latency from resolver to each endpoint and route to fastest), health-check-aware routing (Route 53 health checks remove unhealthy endpoints from DNS responses). Limitation: DNS-based load balancing is coarse — it operates at connection initiation, not per-request. Client-side DNS caching and TTL mean traffic shifts are not instantaneous.

Split-Horizon DNS

Split-horizon (or split-brain) DNS returns different answers for the same query depending on the source IP of the recursive resolver. Internal clients (behind the corporate network) get private/internal IP addresses; external clients get public IP addresses. This is commonly implemented with separate internal and external authoritative nameservers or with views in BIND. Use cases: routing internal traffic to internal load balancers (lower latency, no hairpinning through the internet), exposing different service endpoints to internal vs. external users, keeping internal infrastructure invisible to external DNS enumeration. Complexity: maintaining two zone files for every domain; ensuring internal and external records stay in sync.

Interview Tips

DNS is a foundational component that appears in system design interviews whenever you discuss service discovery, CDN routing, failover, or global traffic management. Know that DNS is eventually consistent by design — TTLs mean changes propagate over time, not instantly. Understand the difference between recursive and authoritative resolvers. Be able to explain why short TTLs are required for DNS failover to be meaningful, and what the tradeoff is. Anycast and DNSSEC are common depth signals. If asked about DNS at scale, discuss negative caching, anycast distribution, and the role of resolver caches in protecting authoritative infrastructure.

{ “@context”: “https://schema.org”, “@type”: “FAQPage”, “mainEntity”: [ { “@type”: “Question”, “name”: “What is the difference between recursive and iterative DNS resolution?”, “acceptedAnswer”: { “@type”: “Answer”, “text”: “In recursive resolution, the stub resolver (on the client machine) sends a query to a recursive resolver (typically provided by ISP or a public resolver like 8.8.8.8). The recursive resolver does all the work — it queries root servers, TLD servers, and authoritative servers iteratively, assembles the answer, and returns it to the stub resolver. In iterative resolution, each DNS server returns a referral to the next server to query — the client must follow each referral itself. Stub resolvers always use recursive; recursive resolvers use iterative when talking to authoritative servers.” } }, { “@type”: “Question”, “name”: “How does DNS caching work and what are the trade-offs of low vs high TTL?”, “acceptedAnswer”: { “@type”: “Answer”, “text”: “DNS responses include a TTL (Time to Live) value. Recursive resolvers cache the response for the TTL duration, serving it from cache for subsequent identical queries without contacting authoritative servers. Low TTL (30-60 seconds): DNS-based failover propagates quickly but increases load on authoritative nameservers and recursive resolvers (more cache misses). High TTL (3600+ seconds): reduced resolver load and faster subsequent responses but DNS changes (IP updates, failover) take longer to propagate globally. Cloudflare and major CDNs use very low TTLs (30-60s) on their authoritative DNS for fast health-check-based failover.” } }, { “@type”: “Question”, “name”: “How does anycast DNS work?”, “acceptedAnswer”: { “@type”: “Answer”, “text”: “Anycast assigns the same IP address to DNS servers in multiple geographic locations. Each location announces this IP via BGP to the internet. Internet routers route DNS queries to the nearest (lowest AS-path-cost) location. From the client’s perspective, there is one IP address; packets are automatically routed to the closest node. If one location goes down, BGP withdraws its announcement and traffic reroutes to the next nearest location. Cloudflare (1.1.1.1), Google (8.8.8.8), and most enterprise authoritative DNS services use anycast for low latency and DDoS resilience.” } }, { “@type”: “Question”, “name”: “What is DNSSEC and what attack does it prevent?”, “acceptedAnswer”: { “@type”: “Answer”, “text”: “DNSSEC (DNS Security Extensions) prevents cache poisoning attacks (Kaminsky attack). Without DNSSEC, an attacker can inject forged DNS responses into a recursive resolver’s cache, redirecting users to attacker-controlled IPs. DNSSEC adds cryptographic signatures to DNS records. The zone signs all its records with a private key. The public key (DNSKEY record) is signed by the parent zone (DS record), creating a chain of trust from the root to the leaf zone. Resolvers verify the signature chain before accepting responses. DNSSEC prevents tampering but does not encrypt queries (use DoH/DoT for privacy).” } } ] }

Frequently Asked Questions

What is the difference between recursive and iterative DNS resolution?

In recursive resolution, the stub resolver (on the client machine) sends a query to a recursive resolver (typically provided by ISP or a public resolver like 8.8.8.8). The recursive resolver does all the work — it queries root servers, TLD servers, and authoritative servers iteratively, assembles the answer, and returns it to the stub resolver. In iterative resolution, each DNS server returns a referral to the next server to query — the client must follow each referral itself. Stub resolvers always use recursive; recursive resolvers use iterative when talking to authoritative servers.

How does DNS caching work and what are the trade-offs of low vs high TTL?

DNS responses include a TTL (Time to Live) value. Recursive resolvers cache the response for the TTL duration, serving it from cache for subsequent identical queries without contacting authoritative servers. Low TTL (30-60 seconds): DNS-based failover propagates quickly but increases load on authoritative nameservers and recursive resolvers (more cache misses). High TTL (3600+ seconds): reduced resolver load and faster subsequent responses but DNS changes (IP updates, failover) take longer to propagate globally. Cloudflare and major CDNs use very low TTLs (30-60s) on their authoritative DNS for fast health-check-based failover.

How does anycast DNS work?

Anycast assigns the same IP address to DNS servers in multiple geographic locations. Each location announces this IP via BGP to the internet. Internet routers route DNS queries to the nearest (lowest AS-path-cost) location. From the client’s perspective, there is one IP address; packets are automatically routed to the closest node. If one location goes down, BGP withdraws its announcement and traffic reroutes to the next nearest location. Cloudflare (1.1.1.1), Google (8.8.8.8), and most enterprise authoritative DNS services use anycast for low latency and DDoS resilience.

What is DNSSEC and what attack does it prevent?

DNSSEC (DNS Security Extensions) prevents cache poisoning attacks (Kaminsky attack). Without DNSSEC, an attacker can inject forged DNS responses into a recursive resolver’s cache, redirecting users to attacker-controlled IPs. DNSSEC adds cryptographic signatures to DNS records. The zone signs all its records with a private key. The public key (DNSKEY record) is signed by the parent zone (DS record), creating a chain of trust from the root to the leaf zone. Resolvers verify the signature chain before accepting responses. DNSSEC prevents tampering but does not encrypt queries (use DoH/DoT for privacy).