DNS

DNS is the phonebook of the Internet: it translates human-readable domain names like www.google.com into machine-readable IP addresses like 172.217.160.142. Nothing else in the request path can start until it finishes — no TCP handshake, no TLS, no HTTP — so a cold lookup sits in front of every other millisecond you spend optimising. It is also a distributed cache with a TTL you choose, which makes that TTL a failover budget rather than a configuration detail.

The hierarchy

DNS is not a single server but a globally distributed, hierarchical database. Three tiers matter.

Root servers. Thirteen logical root server clusters, each fronted by many anycast instances worldwide. They hold no information about your domain; they answer with a referral to the right TLD server.

TLD servers. They manage the last label of a name — .com, .org, .uk, .in — and refer queries to the authoritative name servers registered for that specific domain.

Authoritative name servers. They hold the actual records for a domain and are the source of truth for it, usually run by the registrar, the hosting provider, or a managed DNS vendor.

The lookup path

The browser and OS check their own caches first; a hit ends the process immediately. On a miss, the query goes to a recursive resolver — your ISP's, or a public one such as 8.8.8.8 or 1.1.1.1 — and the resolver does the walking.

Recursive DNS resolution for shop.example.com100%−+FitSVGEsc

Scroll to zoom · drag to pan · 0 fits · Esc closes

The resolver caches every step, honouring each record's TTL, so the root and TLD legs are almost never walked in practice — root and TLD referrals carry TTLs measured in days.

What a lookup costs

Put the latency ladder against it. Assume a user in Mumbai, a resolver 5 ms away, and authoritative servers hosted in US East at roughly 200 ms round trip.

• Fully cold, non-anycast: 5 ms to the resolver, ~10 ms to a nearby root instance, ~10 ms to a nearby TLD instance, 200 ms to the authoritative server, 5 ms back ≈ 230 ms before the first SYN leaves the client.
• Warm at the resolver for root and TLD, cold for the name: ≈ 210 ms, because the authoritative round trip dominates.
• Browser or OS cache hit: ≈ 0 ms.

Then TCP adds one round trip and TLS 1.3 adds one more, so on a cold lookup name resolution can be a third of the time to first byte. The fix is not caching harder on the client; it is anycast authoritative DNS, where the same IP is announced from dozens of points of presence and the query is answered ~10–30 ms away instead of ~200 ms. This is the same reason the origin itself moves closer behind a CDN.

TTL sets both your load and your failover speed

Authoritative query volume does not scale with user traffic. It scales with the number of distinct resolvers divided by the TTL.

Take an app with 1M DAU making 20 requests each: 20M requests/day ÷ 86,400 s ≈ 230 QPS average, ~1,000 QPS peak. Suppose those users sit behind roughly 20,000 distinct recursive resolvers. At a 300-second TTL each resolver refetches at most once per window, so the authoritative tier sees 20,000 ÷ 300 ≈ 67 QPS — two orders of magnitude below user traffic. Cut the TTL to 30 s and it becomes 20,000 ÷ 30 ≈ 667 QPS: ten times the load and cost, bought to make failover ten times faster.

The failure mode is what makes that trade real. Repoint an A record mid-incident with a 3,600-second TTL and resolvers keep handing out the dead IP for up to an hour. Worse, the TTL is a request, not a rule: some resolvers clamp long TTLs down and short TTLs up, browsers keep their own pinned cache (Chrome's is around 60 s), and a JVM configured with networkaddress.cache.ttl set to -1 caches a resolved address for the life of the process.

So the rejected alternative is worth naming: DNS is a poor failover mechanism. Rather than driving traffic with a 30-second TTL, keep a stable address — an anycast VIP or a load balancer hostname — and let the load balancer remove unhealthy backends in seconds via health checks. Reserve DNS changes for planned moves, and when you do plan one, drop the TTL to 60 s a day ahead, migrate, then raise it back.

Record types

• A maps a name to an IPv4 address; AAAA to an IPv6 address.
• CNAME maps a name to another name — an alias, resolved by following the chain.
• MX names the mail servers that receive email for the domain.
• NS names the authoritative servers for the zone.

One rule catches people in production: a CNAME cannot coexist with any other record at the same name, and the zone apex must carry SOA and NS records. That means example.com itself cannot be a CNAME to cdn.provider.net, even though www.example.com can. The workaround is a provider-side ALIAS/ANAME record or CNAME flattening, which resolves the target and serves A/AAAA at the apex.

DNS for load balancing

Round robin DNS publishes several A or AAAA records for one name; servers rotate the order they return. It is simple and needs no extra hardware, and GeoDNS extends it by answering with the nearest region's address, which is how CDNs steer users to an edge.

The limits follow from caching. DNS knows nothing about server health or load, so a failed host keeps receiving traffic until its record is pulled and every cache expires. And the unit of distribution is the resolver, not the user: with three A records and one large ISP resolver serving 30% of your users, that 30% pins to whichever IP it cached for the whole TTL window. Browsers will retry a second address when a connection fails outright, but not when a server answers with errors. Round robin DNS is coarse regional steering, not a substitute for a dedicated load balancer.

In an interview

The interviewer is checking that you know what happens before the first byte, and that you treat DNS as a cache hierarchy with a knob you own. Understand the hierarchical lookup, the role of caching and TTL, and the common record types — especially A and CNAME — and be able to name round robin DNS as a basic load balancing mechanism along with its limitations.

Say the arithmetic out loud: authoritative load is resolvers ÷ TTL, not user QPS, so a 300 s TTL on 20,000 resolvers is about 67 QPS at the authoritative tier. Then say what TTL you would pick and why.

The mistake that loses points is claiming you will "just fail over with DNS" as if it were instant. Caches that ignore your TTL make DNS an eventual-consistency control plane measured in minutes. The second mistake is spending five minutes here: unless the question is about global traffic routing, DNS is a sixty-second part of the answer before you draw the load balancer.

Check yourself

1. Your authoritative tier answers ~67 QPS at a 300 s TTL. Ops wants failover inside 60 s. What do you change, and what does it cost?

Dropping to a 60 s TTL gives 20,000 ÷ 60 ≈ 333 QPS at the authoritative tier — five times the load, still cheap. But it does not buy 60-second failover, because browser and JVM caches ignore the TTL. Keep a stable address in DNS, put a load balancer or anycast VIP behind it, and fail over there in seconds.

2. A Mumbai user, cold cache, authoritative servers in US East. Estimate the delay before the TCP handshake starts, and name the cheapest fix.

Roughly 5 + 10 + 10 + 200 + 5 ≈ 230 ms, dominated by the single 200 ms authoritative round trip. The cheapest fix is anycast authoritative DNS so the answer comes from a nearby PoP, cutting resolution to ~10–30 ms without touching the application.

3. You need example.com (the apex, not www) to point at cdn.provider.net. Why does a CNAME fail, and what do you use instead?

The apex must carry SOA and NS records, and a CNAME cannot coexist with other records at the same name. Use the provider's ALIAS/ANAME record or CNAME flattening, which resolves the target and serves A/AAAA at the apex — or point an A record at a stable anycast VIP.