Design a Domain Name System

Every time you type a URL in your browser, a system translates that human-readable name into a machine-readable IP address, often in under 5 milliseconds. That system is DNS, and it handles trillions of queries per day. Designing a DNS-like system means designing the resolution pipeline that the entire internet depends on.

Functional

Domain name resolution: Resolve human-readable domain names (like www.example.com) to IP addresses so clients can connect to the correct server. Support both forward lookups (name to IP) and reverse lookups (IP to name). This is the single most important function. Everything else exists to make this faster and more reliable.

DNS numbers look deceptively small per query. A 60-byte request and a 300-byte response. But multiply by trillions of queries per day, and the system processes more traffic than nearly any other internet service. The saving grace: caching eliminates 85-90% of upstream queries, so capacity planning is really about cache tiers and hit rates.

Traffic

Global DNS volume: Roughly 8.5 billion DNS queries per day, or about 100K QPS on average. But this is distributed across millions of recursive resolvers worldwide. Any single ISP resolver handles 50K-200K QPS for its user population.

DNS predates REST APIs by two decades. Its "API" is a binary UDP protocol defined in RFC 1035 (1987). But for a modern DNS-like system, you need both the efficient binary protocol for resolution and RESTful APIs for management. The key design decision: every resolution query uses UDP for speed, falling back to TCP only when the response exceeds the UDP limit.

DNS Wire Protocol (Resolution)

The resolution protocol uses UDP on port 53. A single round-trip: client sends a query, server sends a response. The binary format includes a query ID (for matching responses to requests), flags (recursion desired, authoritative answer), the question section (domain name + record type), and the answer section (records + TTL).

DNS does not use a traditional database. Authoritative servers store records in zone files. Flat text files that predate relational databases by a decade. But for a modern DNS-like system, you need to think about both the zone file format for wire compatibility and the underlying storage engine for scale.

Zone File Schema (as SQL for Clarity)

1CREATE TABLE dns_records (
2record_id UUID PRIMARY KEY,
3zone_name VARCHAR(253) NOT NULL,
4domain_name VARCHAR(253) NOT NULL,
5record_type VARCHAR(10) NOT NULL, - A, AAAA, CNAME, MX, TXT, NS, SOA
6record_value TEXT NOT NULL, - IP address, canonical name, etc.
7ttl INT NOT NULL DEFAULT 3600,
8priority INT, - for MX records
9created_at TIMESTAMP DEFAULT NOW(),
10updated_at TIMESTAMP DEFAULT NOW()
11);
12CREATE INDEX idx_lookup ON dns_records(domain_name, record_type);

The DNS architecture is a tree. Root servers at the top know where to find TLD servers. TLD servers know where to find authoritative servers. Authoritative servers know the actual IP addresses. And recursive resolvers walk this tree on behalf of billions of clients, caching answers at every step so the tree is rarely traversed in full.

Root Servers

Understanding DNS means understanding two critical flows: how a query gets resolved (the read path) and how records get updated and propagated (the write path). The read path is what makes DNS fast. The write path is what makes DNS eventually consistent.

Flow 1. Full Recursive Resolution (Read Path)

If the DNS hierarchy is the skeleton, the resolution pipeline is the nervous system. This section deep-dives into the recursive resolver (the most complex component) and the caching, coalescing, and security mechanisms that make it work at scale.

The Resolution Pipeline (GATE)

DNS makes one overarching trade-off: availability over consistency. The entire system is eventually consistent by design. When you update a DNS record, the world does not see the change instantly. It sees it as caches expire. This is deliberate, and it is correct.

TTL Length: Freshness vs. Query Reduction

Short TTL (60s) generates 60x more queries per hour than 3600s but enables sub-minute failover. Long TTL (86400s) produces 1,440x fewer queries but means a 24-hour propagation delay. Best practice: use long TTLs for stable records, short TTLs for dynamic ones, and lower TTLs temporarily before planned changes.

DNS is designed to survive failure. The hierarchical architecture, redundant servers, and aggressive caching mean that most components can fail without users noticing. But when failures cascade, the impact is catastrophic. The 2016 Dyn DDoS attack took down Twitter, Reddit, Netflix, and Spotify by targeting a single major DNS provider.

Authoritative Server Failure

DNS was designed in 1987 and has evolved remarkably well. But several modern extensions address its original blind spots: privacy, intelligence, and security.

DNS-over-HTTPS (DoH) and DNS-over-TLS (DoT)

Traditional DNS queries are sent in plaintext. Anyone on the network path (ISP, coffee shop WiFi, corporate proxy) can see which domains you resolve. DoH wraps DNS queries in HTTPS to a trusted resolver (e.g., https://dns.cloudflare.com/dns-query). DoT uses TLS on port 853. Both encrypt queries end-to-end. The trade-off: ISPs lose visibility into DNS traffic, which breaks ISP-level parental controls and malware domain blocking. Some enterprises block DoH to maintain DNS-based security policies.