DNS

DNS (Domain Name System) is the distributed, hierarchical system that translates human-readable domain names (example.com) into the IP addresses machines actually need to open a connection. It's often called "the phonebook of the internet," and the analogy is apt in one important way: almost nobody dials a raw number, and almost nothing on the internet connects to a raw IP — nearly every request starts with a name lookup you don't think about until it's slow or wrong.

That "don't think about it" property is exactly why DNS deserves real attention in an interview. It sits on the critical path of essentially every request, it has its own latency and failure modes independent of the service it's pointing at, and — as you'll see below — it doubles as one of the simplest tools for load balancing and failover at a global scale.

How a lookup actually resolves

A single domain lookup isn't one request — it's a chain, typically starting from your OS or browser's local cache and, if nothing is cached, working through several tiers of servers:

System Design Lab

Every hop in that chain caches its answer for a duration set by the record's TTL (time to live), which is why a DNS change doesn't take effect everywhere instantly — resolvers around the world are still serving the old answer until their cached copy expires.

Common record types

Record	Purpose
A	Maps a name to an IPv4 address
AAAA	Maps a name to an IPv6 address
CNAME	Aliases one name to another name (not directly to an IP)
MX	Specifies mail servers for a domain
NS	Delegates a zone to a set of authoritative name servers
TXT	Arbitrary text — commonly used for domain ownership verification

The TTL tradeoff

Choosing a TTL is a direct latency-vs-agility tradeoff, and it's worth naming explicitly in an interview:

• A long TTL (hours) means fewer repeated lookups, less load on your authoritative servers, and slightly faster resolution for most clients (more cache hits). The cost is that if you need to change where a name points — say, during an incident — that change propagates slowly, because clients everywhere are still holding a stale cached answer until it expires.
• A short TTL (seconds to a few minutes) means changes propagate almost immediately, at the cost of more frequent lookups hitting your authoritative servers and a small amount of added latency for clients whose cache keeps expiring.

A common pattern is to run with a longer TTL normally and deliberately lower it in advance of a planned migration or failover event, specifically to make the eventual cutover propagate faster.

DNS as a load balancing and failover mechanism

Because a domain can resolve to more than one IP address, and because a DNS provider can change which address(es) it returns based on health checks, DNS itself becomes a crude but genuinely useful load balancer:

• Round-robin DNS returns a rotating list of IPs for the same name, spreading clients across multiple servers without any dedicated load-balancing hardware.
• DNS failover monitors an endpoint's health and stops returning its IP if it goes unhealthy — the same idea covered in Failover, just implemented at the DNS layer instead of inside a load balancer. It's slower to react than a load balancer's health checks (bounded by TTL, and some clients cache more aggressively than the TTL even says to), which is exactly why it's usually used for coarse-grained failover — like routing an entire region's traffic away from a downed data center — rather than fine-grained per-request balancing, which is better handled by an actual Load Balancer.
• Geo-DNS returns different IPs depending on the resolver's geographic location, routing users to their nearest data center before a single packet of application traffic is even sent.

Why this matters in an interview

Naming DNS explicitly in a design — "clients resolve api.example.com, which is either a round-robin set of IPs or points at our load balancer" — shows you understand where the request path actually begins. It's also worth mentioning DNS as a latency contributor: an uncached lookup adds a full round trip (sometimes several, per the chain above) before the "real" request even starts, which is part of why browsers and OSes cache so aggressively and why CDNs (see CDN) care about DNS performance as much as edge caching.

Aggressive DNS caching (high TTL): pros and cons

Pros

• ✓Fewer repeated lookups — lower load on authoritative servers
• ✓Faster resolution for most clients thanks to more cache hits
• ✓Less exposure to resolver or authoritative-server outages, since answers are already cached

Cons

• ✕Slow propagation — an IP change can take up to a full TTL to reach every client
• ✕Makes DNS-based failover sluggish during an actual incident
• ✕Some resolvers ignore or override TTLs, making propagation timing unpredictable

Further Reading

• Cloudflare Learning — What is DNS? — a clear walkthrough of the resolution chain, caching, and record types.
• Wikipedia — Domain Name System — a detailed reference covering the hierarchy, record types, and protocol history.