Concept Drills: 16 DNS Probes

DNS questions appear in almost every system design interview, usually as a follow-up rather than the main problem. These are the probes that actually get asked.

The basics

1. Walk me through what happens when I type a URL and hit enter. · L4 · Testing: the fundamental path

The browser checks its own cache, then the OS cache, then asks the configured resolver — usually your ISP's. If that resolver has it cached, you get an answer immediately. Otherwise it walks the hierarchy iteratively: root returns the TLD servers for the suffix, the TLD returns the domain's authoritative servers, and the authoritative server returns the actual A record. You get back a list of IP addresses, and the browser connects to one of them.

2. What are the four main types of DNS server? · L4 · Testing: hierarchy recall

Resolver, root, TLD, and authoritative. The resolver initiates and caches on the client's behalf. The root directs to the right TLD. The TLD holds the addresses of authoritative servers per domain. The authoritative server holds the real records and is the source of truth for its zone.

3. Difference between an A record and a CNAME? · L4 · Testing: record types

An A record maps a hostname directly to an IP address and terminates the lookup. A CNAME maps a hostname to another hostname, so the resolver has to resolve that one too. A is an answer; CNAME is indirection — which is what lets a CDN or managed service answer for your name without you tracking their IPs.

4. Why can't you put a CNAME at the root of your domain? · L5 · Testing: a real operational detail

Because a CNAME can't coexist with other records for the same name, and the zone apex must carry NS and SOA records. So www.example.com can CNAME to a CDN but bare example.com can't. Providers work around it with ALIAS or ANAME records that behave like a CNAME but resolve server-side and hand back an A record.

Resolution

5. Iterative or recursive — which does DNS use? · L5 · Testing: precision

Both, at different segments. The client makes one recursive request to its resolver — "give me the answer." The resolver then queries the hierarchy iteratively, following referrals from root to TLD to authoritative. Answering "it's recursive" or "it's iterative" alone misses the actual arrangement.

6. Why is iteration preferred upstream? · Staff · Testing: load reasoning

To keep load off shared global infrastructure. Under recursion, root and TLD servers would hold open state for every in-flight query passing through them, scaling with total internet traffic. Under iteration they answer one cheap referral and forget the requester — stateless and trivially cacheable. It's the general pattern of pushing work to the edge and keeping shared infrastructure stateless.

7. Why are DNS names read right to left? · L5 · Testing: whether they see the design

So the most general component resolves first and each step narrows the search. The root only needs to know TLDs; .io only needs to know domains under it. That's what makes delegation work — registering a new domain touches exactly one TLD server, not the root and not anyone else. Left-to-right would have required the root to know something about every name in existence.

Caching and TTL

8. What is TTL and what does it trade off? · L4 · Testing: the core dial

Time-to-live: how long a resolver may cache a record. Short TTL means fresher records and faster propagation but more queries and load. Long TTL means high cache hit rates and low load but slow propagation. It's the only control you have over a global cache you don't own.

9. You need to change your site's IP. Walk me through it. · Staff · Testing: the sequencing detail

Lower the TTL first — then wait out the full old TTL before changing anything, because resolvers holding the record at the old long TTL won't see the new short one until they expire. Then change the record, dual-run both addresses so anyone still cached isn't broken, watch the old address drain, and raise the TTL back afterwards. Expect a long tail from clients that ignore TTL entirely. The better answer is to avoid it: CNAME to a load balancer so the address never changes.

10. Where is DNS cached? · L4 · Testing: layer awareness

Browser, operating system, local network resolver, and ISP resolver. A hit at any layer stops the lookup there. Even a miss on the specific domain can skip tiers, because the resolver may have cached the TLD or authoritative server addresses from earlier lookups and can jump straight there instead of starting at the root.

11. What is negative caching and when does it bite you? · Staff · Testing: an operational edge

Caching of NXDOMAIN — "this name doesn't exist" — for a period derived from the zone's SOA record. It protects authoritative servers from typos and scanning. It bites when you create a record for a name someone already queried unsuccessfully: they keep getting "doesn't exist" until the negative cache expires. Teams hit this constantly when they test a new subdomain a moment too early.

Distributed system properties

12. Why does DNS use UDP? · L5 · Testing: protocol reasoning

A lookup is a single small idempotent request, so TCP's three-way handshake would multiply latency for no benefit. UDP is connectionless, so there's no state to recover on failure — a lost query is just re-sent, often to a different server, which turns packet loss into free failover. It switches to TCP when a response exceeds 512 bytes or for zone transfers, where reliable ordered delivery genuinely matters.

13. What consistency model does DNS provide, and is that the right choice? · L5 · Testing: applying CAP

Eventual consistency, and yes, clearly. Updates propagate lazily — seconds to days depending on TTL and infrastructure. It's the canonical AP system: a stale IP usually still routes correctly and self-heals at TTL expiry, whereas unavailable DNS means nothing on the internet resolves. Trading a minor, bounded staleness problem for a catastrophic availability one would be the wrong way round.

14. There are 13 root servers. How does that serve the whole planet? · Staff · Testing: anycast

Those are 13 addresses, not 13 machines. Each is anycast — many physical instances worldwide advertise the same IP, and internet routing delivers each query to the topologically nearest one. Roughly a thousand instances back the 13 addresses. That single mechanism gives scalability, low latency, and automatic failover, since a dead instance is simply routed around. The number 13 comes from fitting the root server list in one 512-byte UDP response, not from any capacity limit.

Traffic steering

15. Can DNS load balance? What are its limits? · Staff · Testing: knowing the ceiling

It can distribute — round robin rotates the returned address order, and managed providers add weighted, geolocation, latency-based, and health-checked routing. But it's coarse: TTL and non-compliant resolvers make convergence minutes with an unbounded tail, and distribution skews because one large resolver caches one answer for thousands of users. It also has no visibility into server load, only health. So DNS picks the region; a load balancer inside the region picks the server.

16. Your primary region fails. Can DNS fail you over? · Staff · Testing: the dangerous assumption

Not fast enough to rely on alone. Health checks detect it in seconds and the record updates, but users keep hitting the dead address until their resolver, OS, or application picks up the change — minutes at best, longer for processes that resolved once at startup. For seconds-level failover the mechanism must be closer to the client: anycast so the network reroutes, a load balancer behind a stable address, or clients retrying across the full address list DNS already returned.

Self-check

The cheat sheet next compresses the whole chapter onto one page.