Interview questions

Interview questions (with the counter-questions you'll get)

Q1. Walk me through a DNS lookup.

They're testing: the full chain, in order, including caching.

Think about your answer first, then open it.

reveal

1Show the strong answer, counter-questions and trap
2**Strong answer:** The browser checks its cache, then the operating system's. If neither has it, the device asks a recursive resolver, often the ISP's or a public one. With an empty cache, the resolver asks a root server, which refers it to the TLD servers for `.com`; the TLD servers refer it to the domain's authoritative name servers; those return the record with a TTL. The resolver returns the answer and everyone along the way caches it for the TTL.
3
4**Counter-questions:**
5- *"How often does the resolver really go to the root?"* → Rarely. The root and TLD referrals have long TTLs and are cached by busy resolvers almost all the time.
6- *"What transport does DNS use?"* → Usually UDP on port 53, with TCP for large answers and zone transfers. Encrypted options include DNS over HTTPS and DNS over TLS.
7
8**Trap:** "the browser asks the DNS server and gets the IP", with no caching and no hierarchy.

Q2. Recursive vs iterative resolution?

They're testing: precise vocabulary.

Think about your answer first, then open it.

reveal

1Show the strong answer, counter-questions and trap
2**Strong answer:** In a recursive query, the client asks a resolver to return the final answer, and the resolver does all the work. In iterative resolution, each server replies with either the answer or a referral to the next server, and the asker follows the referrals itself. Devices normally make recursive queries to a resolver, and the resolver resolves iteratively through root, TLD and authoritative servers.
3
4**Counter-questions:**
5- *"Why don't root servers answer recursively?"* → They'd have to do the work for every query on the internet. Referrals keep them simple and let the load spread down the hierarchy.
6
7**Trap:** using the two words as if they meant the same thing.

Q3. A record vs CNAME? Why can't the bare domain be a CNAME?

They're testing: record semantics and a classic gotcha.

Think about your answer first, then open it.

reveal

1Show the strong answer, counter-questions and trap
2**Strong answer:** An A record maps a name to an IPv4 address; a CNAME makes a name an alias of another name, which is then resolved. A CNAME can't coexist with other records at the same name, and the bare domain must hold NS and SOA records, so it can't be a CNAME. Providers offer ALIAS or "CNAME flattening" as a non-standard workaround that returns A records.
3
4**Counter-questions:**
5- *"When would you choose a CNAME over an A record?"* → When pointing at a service you don't control, like a CDN or a hosting platform, so their IP changes don't need your changes.
6- *"Any cost to a CNAME?"* → Potentially one more lookup to resolve the target, though resolvers often return both together.
7
8**Trap:** "a CNAME is a redirect". It's an alias at the DNS level, not an HTTP redirect.

Q4. What is a TTL, and how would you choose one?

They're testing: the freshness vs load trade-off.

Think about your answer first, then open it.

reveal

1Show the strong answer, counter-questions and trap
2**Strong answer:** The TTL is how long resolvers may cache a record. Short TTLs let changes and failovers take effect quickly but increase queries and slightly increase lookup latency; long TTLs reduce load and survive short DNS outages better but make changes slow. I'd use a few minutes for records I might need to fail over, and hours for stable records like MX.
3
4**Counter-questions:**
5- *"Do all resolvers respect your TTL?"* → Most do, but some clamp very short or very long TTLs, and some apps cache longer than they should. So keep old servers running a while after a change.
6
7**Trap:** "set the TTL as low as possible so changes are instant".

Q5. We're moving to new servers next week. How do you change DNS without downtime?

They're testing: practical operations.

Think about your answer first, then open it.

reveal

1Show the strong answer, counter-questions and trap
2**Strong answer:** Well before the move, lower the TTL of the record to a few minutes and wait at least the old TTL so long-lived copies expire. On the day, change the record. Keep the old servers running and serving correctly until the old TTL has passed, plus some margin. Monitor traffic on both. Then raise the TTL again.
3
4**Counter-questions:**
5- *"What if the old servers can't stay up?"* → Make them forward traffic to the new servers (a reverse proxy) during the overlap, so stale DNS answers still work.
6
7**Trap:** "change the record and wait for propagation".

Q6. Can DNS be used for load balancing? What are the limits?

They're testing: knowing what DNS can and can't do.

Think about your answer first, then open it.

reveal

1Show the strong answer, counter-questions and trap
2**Strong answer:** Yes, roughly: multiple A records give round-robin spreading, and GeoDNS or latency-based routing sends users to a nearby region. But DNS doesn't see server load or health in real time, caching delays any change by up to the TTL, clients don't spread evenly, and routing is based on the resolver's location. So I'd use DNS to pick a region and proper load balancers inside each region.
3
4**Counter-questions:**
5- *"How do you stop DNS handing out a dead server?"* → Use a DNS service with health checks that removes unhealthy endpoints, keep TTLs short on those records, and have load balancers in front so a single dead machine never appears in DNS at all.
6
7**Trap:** treating DNS round-robin as a full load balancer.

Q7. How does GeoDNS know where a user is?

They're testing: a subtle but real limitation.

Think about your answer first, then open it.

reveal

1Show the strong answer, counter-questions and trap
2**Strong answer:** The authoritative server usually sees the recursive resolver's IP address, not the user's, so it routes based on the resolver's location. If a user uses a far-away public resolver, they may be routed badly. The EDNS Client Subnet extension lets resolvers pass part of the user's address so the authoritative server can route more accurately, where both sides support it.
3
4**Counter-questions:**
5- *"What's an alternative to GeoDNS?"* → Anycast: announce the same IP address from many locations and let the network route each user to the nearest one.
6
7**Trap:** "GeoDNS reads the user's IP".

Q8. What happens to your site if your DNS provider goes down? How do you protect against it?

They're testing: awareness of DNS as a single point of failure.

Think about your answer first, then open it.

reveal

1Show the strong answer, counter-questions and trap
2**Strong answer:** Users whose resolvers don't have your records cached can't find you, so the site is effectively down even though the servers are fine; the Dyn attack in 2016 showed this. To protect against it, I'd use a provider with a strong record, consider a second independent provider serving the same records, keep moderate TTLs so cached answers ride out short outages, and make sure internal recovery tools don't depend on the same DNS.
3
4**Counter-questions:**
5- *"Why does a longer TTL help here?"* → Resolvers that cached your records keep serving them during the outage, at least until the TTL runs out.
6
7**Trap:** "DNS is managed, so it won't fail".

Q9. Why does DNS mostly use UDP?

They're testing: connecting transport choices to the workload.

Think about your answer first, then open it.

reveal

1Show the strong answer, counter-questions and trap
2**Strong answer:** A DNS lookup is usually one small question and one small answer. UDP avoids the TCP handshake, so it's one round trip and very light on the server, which matters at the scale of resolvers. The client simply retries if a packet is lost. When an answer is too large, or for zone transfers, DNS uses TCP.
3
4**Counter-questions:**
5- *"What about privacy?"* → Plain DNS is unencrypted, so networks along the way can see which names you look up. DNS over HTTPS or DNS over TLS encrypts the queries to the resolver.
6
7**Trap:** "UDP because it's faster", with no reasoning.

Q10. A user says your site doesn't load for them, but it works for everyone else. How could DNS be involved?

They're testing: debugging instinct.

Think about your answer first, then open it.

reveal

1Show the strong answer, counter-questions and trap
2**Strong answer:** Their resolver may have a stale or wrong cached answer, for example after a recent IP change with a long TTL. Their device or browser may have a stale cache or a `hosts` file entry. Their resolver may be broken or blocking the name. Or GeoDNS may be sending them to an unhealthy region. I'd ask them to resolve the name (with `dig` or `nslookup`), compare with what our authoritative servers return, try a public resolver, and flush local caches.
3
4**Counter-questions:**
5- *"How would you catch this before users report it?"* → Monitor resolution and site reachability from many locations and resolvers, and alert when answers or reachability differ.
6
7**Trap:** blaming the user's internet without checking DNS.
8
9---
10
11## Practice coverage
12
13Every section in this chapter is tested at least once.
14
15| Section | Tested by |
16|---|---|
17| 4.1 Why names | Level 5.1, Q1 |
18| 4.2 Parts of a domain | Level 1A, Q2 |
19| 4.3 The lookup chain | Level 2.3, Level 3, Q1, Q2, Q9 |
20| 4.4 Record types | Level 1A, Level 1B.3, Level 3, Q3 |
21| 4.5 TTL and caching | Level 2.1, Level 2.2, Level 3, Q4 |
22| 4.6 DNS load balancing, GeoDNS | Level 1B.2, Level 5.1, Level 5.2, Level 5.5, Q6, Q7 |
23| 4.7 Propagation | Level 1B.1, Level 2.4, Level 4, Q5 |
24| 4.8 DNS failures | Level 5.4, Q8, Q10 |
25
26---

4. DNS