Low Level Design: DNS Resolution System

DNS Hierarchy: Root, TLD, and Authoritative Nameservers

The Domain Name System is a globally distributed hierarchical database organized as an inverted tree. At the top sit 13 logical root nameserver clusters (A through M), operated by different organizations and replicated via anycast to over 1,500 physical locations worldwide. Below the root are Top-Level Domain (TLD) nameservers, one set per TLD (.com, .org, .net, country-code TLDs). Below TLD servers sit authoritative nameservers, which hold the actual DNS records for registered domains. When a resolver needs to resolve example.com it starts at the root, which delegates to the .com TLD servers, which in turn delegate to the nameservers listed in example.com’s NS records, which finally answer with the A or AAAA record. This delegation chain is encoded in NS records at each level and is the mechanism by which DNS distributes authority across millions of independently operated domains without any central coordination. The root zone itself is managed by ICANN and the root zone maintainer (currently Verisign for the root zone file), and changes propagate via zone transfer to all root server operators.

Recursive Resolver: Stub Resolvers, Cache-First Lookup, and Root Priming

Most DNS queries originate from a stub resolver — a minimal DNS client built into the operating system — that knows only one thing: the IP address of a recursive resolver (typically provided by DHCP or manually configured). The stub sends all queries to the recursive resolver and expects a complete answer. The recursive resolver does the actual work: it checks its cache first, and if the answer is present and the TTL has not expired, it returns it immediately without any upstream queries. On a cache miss the resolver must walk the hierarchy. It starts with the root nameservers, whose IP addresses are compiled into the resolver software as a priming file (root.hints). The resolver sends a query to a root server and receives a referral to the TLD nameservers. It queries a TLD server and receives a referral to the authoritative nameservers. It queries the authoritative nameserver and receives the final answer. All intermediate results (NS records, glue A records for nameservers) are also cached with their respective TTLs so subsequent queries for the same zone skip earlier steps. A single recursive resolver serving many clients benefits from a warm cache: the more queries it handles, the higher its cache hit rate and the lower the average latency across all users.

Authoritative Nameserver: Zone Files, SOA Records, and Zone Transfer

The authoritative nameserver holds the ground truth for a zone. Zone data is stored in a zone file — a text file using the RFC 1035 master file format — containing all resource records (RRs) for the zone: A, AAAA, CNAME, MX, TXT, NS, and others. Every zone has a Start of Authority (SOA) record that carries administrative metadata: the primary nameserver hostname, the responsible party’s email address (encoded with a dot instead of @), a serial number, and timing parameters (refresh, retry, expire, and minimum TTL). The serial number is critical for zone transfer: secondary nameservers periodically poll the primary’s SOA record and compare the serial number. If the serial has incremented, the secondary initiates a zone transfer (AXFR for full transfer, IXFR for incremental transfer of only the changed records). TSIG (Transaction Signature) or DNSSEC signatures authenticate zone transfers to prevent a rogue server from impersonating the primary. DNS hosting providers have moved beyond static zone files to database-backed systems with API-driven record management, where the zone file format is a rendering detail rather than the authoritative data store.

Caching and TTL: Negative Caching, TTL Tuning, and Propagation Tradeoffs

Caching is the mechanism that makes DNS scalable: without it, every DNS query in the world would ultimately reach the authoritative servers. Recursive resolvers cache every resource record with its TTL countdown. When the TTL reaches zero the record is evicted and the next query triggers a fresh lookup. TTL values are a deliberate tradeoff between propagation speed and origin load. A TTL of 300 seconds means a DNS change (pointing a domain to a new IP after a migration) propagates globally in at most 5 minutes — any cached copies will expire and resolvers will fetch the new value. A TTL of 86400 seconds (one day) means changes take up to 24 hours to propagate but the authoritative server receives far fewer queries. Best practice for planned migrations is to lower TTLs to 60–300 seconds well before the cutover, perform the switch, and then raise TTLs back after confirming the change is correct. Negative caching (RFC 2308) applies to NXDOMAIN responses: a resolver caches the fact that a name does not exist for the duration specified in the SOA’s minimum TTL field, preventing repeated queries for nonexistent names from hammering authoritative servers.

Anycast for Authoritative Nameservers: BGP Announcement and Stateless Protocol Benefits

DNS is a UDP protocol (with TCP fallback for large responses and zone transfers), and UDP is stateless — each query-response pair is independent with no connection state. This property makes DNS uniquely well-suited to anycast routing. The operator announces the same IP address from multiple physical locations via BGP. Internet routers forward DNS queries toward the topologically nearest announcement, so a query from a user in Asia reaches the Asian PoP while a query from Europe reaches the European PoP. Each location handles queries for the same zone independently, with no coordination required between locations because there is no session state to synchronize. If a PoP goes offline, BGP withdraws its announcement and queries reroute to the next-nearest location within seconds, providing automatic failover without any application-level health checks. Authoritative DNS operators like NS1, Route 53, and Cloudflare operate dozens to hundreds of anycast PoPs, keeping authoritative query latency well under 10ms for most users globally. The occasional split-brain issue — where routing changes cause a query to reach a different PoP mid-resolution for TCP fallback — is handled by ensuring all PoPs serve identical zone data, typically through a distributed database with synchronous replication or a central zone publishing system.

DNSSEC Validation: Signatures, Key Hierarchy, and Authenticated Denial

DNSSEC adds cryptographic authentication to DNS responses, protecting against cache poisoning attacks where a malicious resolver injects forged records. Each zone signs its resource record sets (RRsets) with its Zone Signing Key (ZSK), producing RRSIG records that accompany the RRset in responses. The zone also publishes its DNSKEY records (the public key material) so validators can verify the signatures. The chain of trust works through DS (Delegation Signer) records: a parent zone publishes a DS record containing a hash of the child zone’s Key Signing Key (KSK). A validator resolving example.com starts by trusting the root zone’s DNSKEY (the trust anchor, distributed with resolver software and updated infrequently). It verifies the root’s signature over the .com DS record, then the .com zone’s signature over example.com’s DS record, then example.com’s KSK’s signature over its ZSK, and finally the ZSK’s signature over the queried RRset. Authenticated denial of existence uses NSEC or NSEC3 records to prove that a name does not exist without exposing the full zone contents to enumeration (NSEC3 adds hashing to prevent zone walking). DNSSEC validation is computationally expensive relative to plain DNS, which is why it typically runs at the recursive resolver rather than the stub.

DNS-Based Load Balancing: Round-Robin, Weighted Records, GeoDNS, and Health Checks

DNS is a natural load-balancing primitive because the authoritative server controls which IP addresses a name resolves to and can vary that answer per query. The simplest form is round-robin: return multiple A records and rotate the order with each response, relying on the client to use the first record. Weighted records assign different weights to each IP, so a server with twice the capacity receives twice the traffic. GeoDNS (or latency-based routing in Route 53 terms) inspects the source IP of the recursive resolver and returns different record sets based on the resolver’s inferred geographic region — European resolvers get European IPs, Asian resolvers get Asian IPs. Health-check-driven record removal closes the loop: a health-checking system continuously probes each backend and removes its A record from DNS responses when it fails, typically within one TTL window. The combination of GeoDNS and health checks is how global services like AWS Route 53 Latency Routing and Cloudflare Load Balancing implement active-active multi-region deployments. The fundamental limitation of DNS-based load balancing is that clients and intermediate resolvers cache responses for the TTL duration, so you cannot react faster than your TTL when removing a failed server — low TTLs are essential for health-check-driven routing to be effective.

DNS over HTTPS and DNS over TLS: Encrypted Resolution and Privacy

Traditional DNS sends queries and responses in plaintext over UDP port 53, making them visible to any observer on the network path — ISPs, corporate network administrators, and adversaries who can see traffic. DNS over TLS (DoT, RFC 7858) wraps DNS in a standard TLS connection on port 853, encrypting the query and response from the stub resolver to the recursive resolver. DNS over HTTPS (DoH, RFC 8484) encodes DNS queries as HTTPS requests to a well-known URL (typically https://resolver/dns-query), making DNS traffic indistinguishable from ordinary web traffic and bypassing firewalls that block port 853. Both protocols provide confidentiality (an observer sees only that you contacted a DNS resolver, not what you queried) and integrity (TLS prevents tampering). From an infrastructure perspective, DoH and DoT require the recursive resolver to terminate TLS, which adds CPU cost and connection overhead relative to UDP. Large resolver operators (Cloudflare 1.1.1.1, Google 8.8.8.8) have absorbed this cost. Resolver discovery — how a stub learns the DoH URL of its assigned resolver — is addressed by DHCP option 252 for DoH and an ALPN-based mechanism for DoT, though both are still being standardized and adoption is uneven across operating systems and network equipment.

{ “@context”: “https://schema.org”, “@type”: “FAQPage”, “mainEntity”: [ { “@type”: “Question”, “name”: “Why does DNS TTL tuning matter for deployments and failover scenarios?”, “acceptedAnswer”: { “@type”: “Answer”, “text”: “TTL (Time To Live) controls how long resolvers cache a DNS record before re-querying the authoritative server. A high TTL (e.g., 86400s) reduces authoritative server load and speeds up resolution for clients, but means that after a record change — IP rotation, failover to a backup region — clients keep hitting the old address for up to TTL seconds. A low TTL (e.g., 60s) allows fast propagation of changes but increases query volume and can cause latency spikes if the authoritative server is slow. Best practice: lower TTL (to 60-300s) several hours before a planned migration so caches drain, then make the record change, then raise TTL again. For health-check-driven failover, TTLs of 30-60s are common, trading query cost for fast convergence.” } }, { “@type”: “Question”, “name”: “How does DNSSEC establish a chain of trust from the root zone down to a leaf zone?”, “acceptedAnswer”: { “@type”: “Answer”, “text”: “DNSSEC uses asymmetric cryptography to sign DNS records. Each zone has a Zone Signing Key (ZSK) that signs its resource records and a Key Signing Key (KSK) that signs the ZSK. The parent zone stores a DS (Delegation Signer) record containing a hash of the child zone’s KSK. The chain works as follows: the root zone’s public key is a well-known trust anchor distributed with resolvers. The root signs its own DNSKEY records and publishes DS records for TLD zones. Each TLD signs its DNSKEY records and publishes DS records for second-level domains, and so on. A validating resolver walks this chain from the root trust anchor down to the queried zone, verifying each signature. If any link breaks (expired signature, key mismatch, missing DS record), the resolver returns SERVFAIL rather than an unvalidated answer.” } }, { “@type”: “Question”, “name”: “What are the limitations of DNS-based load balancing compared to application-level load balancing?”, “acceptedAnswer”: { “@type”: “Answer”, “text”: “DNS-based load balancing returns multiple A/AAAA records or rotates records (round-robin DNS) to distribute traffic. Limitations: (1) Client caching — clients and intermediate resolvers cache the DNS response for the TTL duration and keep hitting the same IP, defeating rotation. (2) No health awareness — DNS cannot remove an IP from rotation the moment a backend fails; it depends on external health checks and TTL expiry. (3) No connection-level visibility — DNS cannot balance based on active connection count, CPU load, or response latency. (4) Sticky sessions break — if a client resolves a different IP on re-query, session affinity is lost. Application-level load balancers (L4/L7) operate on every connection or request, can drain connections gracefully, perform active health checks with sub-second failover, inspect HTTP headers for routing, and maintain session persistence — none of which DNS can do.” } }, { “@type”: “Question”, “name”: “How does GeoDNS route traffic to regional endpoints based on client location?”, “acceptedAnswer”: { “@type”: “Answer”, “text”: “GeoDNS inspects the source IP of the DNS query (or the EDNS Client Subnet extension, which forwards a prefix of the client’s IP through recursive resolvers) and looks it up in a GeoIP database to determine the client’s country, region, or ASN. The authoritative server then returns different record sets for different geographic buckets — e.g., US clients get the us-east-1 load balancer IP, EU clients get eu-west-1. This routes users to their nearest region without requiring anycast or application-layer redirection. Limitations: GeoIP accuracy varies (VPNs, satellite ISPs, CGNAT all skew location); recursive resolvers may be geographically distant from the actual client, causing misrouting; EDNS Client Subnet improves accuracy but not all resolvers send it. GeoDNS is typically combined with health checks so that if a regional endpoint fails, its IPs are replaced by a fallback region’s IPs.” } }, { “@type”: “Question”, “name”: “How does DNS negative caching work, and what is the impact of NXDOMAIN responses?”, “acceptedAnswer”: { “@type”: “Answer”, “text”: “Negative caching (RFC 2308) allows resolvers to cache the fact that a name does not exist (NXDOMAIN) or that a record type does not exist for a name (NOERROR with empty answer). The cache duration is the minimum of the SOA record’s MINIMUM field and the SOA TTL returned in the authority section of the negative response. This prevents repeated queries to authoritative servers for non-existent names, which matters for typo-driven traffic and non-existent subdomains. The impact of NXDOMAIN: if a new hostname is provisioned but the negative cache has not expired, clients continue receiving NXDOMAIN even though the record now exists — a problem during rapid DNS provisioning. Additionally, wildcard DNS records interact with negative caching: a wildcard prevents NXDOMAIN for covered names, so resolvers never cache a negative for those names. High NXDOMAIN rates in logs also indicate misconfigured clients or DNS reconnaissance attacks.” } } ] }