In this article
Before you start
This page belongs to the distributed systems interview path, where the Domain Name System is the first hop of almost every request.
Why interviewers ask this
DNS sits in front of every web request, so a wrong picture of it leads to wrong designs: a failover plan that ignores caches, or a latency budget that forgets the first lookup. Interviewers use the question to see whether a candidate can explain a system everyone uses but few have looked inside, as in the "what happens when you type a uniform resource locator (URL)" prompt.
A weak answer says "DNS turns names into IP addresses" and stops. A strong answer names the roles (the machine that asks, the resolver that walks, the servers that refer, the one that owns the record), says where answers are cached, and states what limits how fast a change spreads. A Staff-level answer ties that to a design choice, such as how long a record should live before a migration.
DNS server from first principles
- Recursive resolver
- A recursive resolver is a DNS server that takes a question from a client and does the whole lookup on its behalf, asking other servers in turn and caching what it learns, so the client needs to ask only once.
- An authoritative server is a DNS server that holds the records of a domain as the source of truth and answers questions about that domain directly, instead of asking anyone else.
In plain words
Think of a phone directory with no single book. A regional office knows only which office handles each area code. That office knows which exchange handles each prefix. The exchange holds the actual numbers. You ask your own assistant, who calls down the chain. The assistant writes the answer in a notebook for next time. The analogy breaks in one place: real DNS notebooks expire on a timer set by the record's owner.
In one precise sentence, DNS is a distributed, hierarchical database of records. A "DNS server" is any server that plays a role in answering queries against it. Request for Comments (RFC) 1034 (1987) describes name servers that hold data and resolvers that retrieve it. RFC 9499 (March 2024) is the terminology reference that separates the roles.
Step 1: Your device asks a recursive resolver
A stub resolver is the small piece of software in your device that sends the question to a resolver and cannot do the lookup itself. RFC 9499 (March 2024) defines it as "A resolver that cannot perform all resolution itself."
Input: a name such as example.com. Output: one question sent to a recursive resolver, usually run by your network or an internet provider. The device first checks its own cache. If the answer is there, no network request happens at all. If not, the question goes out, and the device now waits for one reply, not a chain of them. You now know the first hop: the device never walks the hierarchy itself, which is why the next step happens on the resolver.
Step 2: The recursive resolver asks root, TLD and authoritative servers
The recursive resolver answers from its cache if it can; otherwise it walks the hierarchy from the top. A root server is a DNS server that knows only which servers run each top-level domain (TLD). A top-level domain is the last label of a name, such as com or org.
Input: the question and an empty cache. The resolver asks a root server, which does not know the answer but replies with the TLD servers for com. That reply is called a referral. A referral is a response that points to another server instead of giving the answer. The resolver then asks a TLD server, which replies with a referral to the domain's authoritative servers. In short, the root server refers to TLD servers and the TLD server refers to the domain's servers. RFC 1034 describes this referral-following algorithm.
Output: the address of an authoritative server. Root servers do not know every domain; they know who to ask next. You now know the walk has up to three stops, each a different role.
Step 3: The authoritative server gives the final answer and a time to live
The authoritative server for example.com is asked last, and it answers directly because it holds the domain's records. A record maps a name to a value. An A record maps a name to an Internet Protocol version 4 (IPv4) address, and an AAAA ("quad-A") record maps it to an Internet Protocol version 6 (IPv6) address, which is four times the size of an IPv4 address.
Input: the question from the resolver. Output: the record plus its time to live, set by whoever owns the domain. The time to live is the field RFC 1035 (1987) defines on every record, and it tells caches how long reuse is allowed. A short value means changes spread quickly but caches ask more often. A long value means fewer queries and slower changes. If the name does not exist, the server says so, and RFC 2308 (1998) lets resolvers cache that negative answer too the NXDOMAIN ("name error") response.
Step 4: Caches keep the answer until its time to live runs out
The recursive resolver keeps the answer in a cache and returns it to the device, and every later question for that name is served from the cache until the time to live expires. The device may keep its own copy for the same period.
Input: a repeat question inside the time to live. Output: an answer with no walk at all. This is why DNS scales: the root and TLD servers see few queries from each resolver, because each resolver caches the referrals it learned. It is also why a changed record is not visible everywhere at once: each cache holds the old value until its own timer ends. The worked example puts numbers on both effects.
Step-by-step description
- The device asks a recursive resolver.
- Root and TLD servers refer the resolver onward.
- The authoritative server returns the record.
- The resolver stores the answer for its time to live.
- The device asks a recursive resolver.
- The resolver asks a root server and a TLD server for referrals.
- The authoritative server gives the final record.
- The resolver keeps the answer in a cache.
Knowing it is half the job. Saying it is the other half.
Interview Clozo is an AI interview copilot for real interview rounds: it hears the question and puts a strong answer on your screen, and you say it in your own words. See the features or how it works.
Start Free Trial →Worked example
Take one lookup of example.com through a resolver with an empty cache. The round-trip times are illustrative: 5 milliseconds from device to resolver, 20 to a root server, 25 to a TLD server and 40 to the authoritative server. The cold lookup adds all four, which is 90 milliseconds.1 If the resolver already cached the referral to example.com's authoritative servers (the TLD server's answer), the root and TLD stops disappear and the lookup costs 5 plus 40, or 45 milliseconds. If it cached the final answer, the cost is the 5-millisecond hop alone.1
Now the average. If 9 in 10 lookups hit the resolver's cache (an illustrative hit rate), the expected lookup time is 0.9 times 5 plus 0.1 times 90, which is 13.5 milliseconds.1
| Quantity (illustrative inputs) | Value |
|---|---|
| Cold lookup, four round trips | 90 milliseconds |
| Lookup with the domain's referral cached | 45 milliseconds |
| Lookup with the answer cached | 5 milliseconds |
| Expected lookup at a 90% cache hit rate | 13.5 milliseconds |
| Authoritative queries per hour, one resolver, 300-second time to live | at most 12 |
| Authoritative queries per hour, one resolver, 60-second time to live | at most 60 |
| Worst-case staleness after a change, 300-second time to live | 300 seconds |
| Average staleness if caches expire evenly | 150 seconds |
The query ceiling is 3,600 seconds in an hour divided by the time to live.1 The same arithmetic shows how to plan a migration: with an 86,400-second (24-hour) time to live on the old record, lower it to 300 seconds at least 24 hours before the change, so every cache has already picked up the short value.1 For more on this kind of budgeting, see back-of-the-envelope estimation.
Text description of the diagram
- A cold lookup costs 90 milliseconds in this illustrative example.
- With the referral to the domain's servers cached it costs 45 milliseconds, and with the answer cached 5 milliseconds.
Trade-offs and edge cases
Short and long time-to-live values trade freshness for load. A short value lets a change reach users fast and makes failover quicker, but it multiplies queries to the authoritative servers. A long value is cheap and fast for users but makes a mistake slow to undo. The same trade appears in any cache, as in a distributed cache.
Negative answers are cached as well. If you create a record right after someone looked the name up and got "does not exist", resolvers may keep that answer for a while, per RFC 2308. A record you just added can therefore look missing.
Do not assume every cache obeys your time to live exactly. Treat it as the intended limit and plan for stragglers during a switch, for example by keeping the old target running until traffic drains. This matters when you move traffic between environments, as in deployment strategies.
A name can also have several address records, so one lookup can return a list; a client picks one, which spreads load only roughly. DNS is a naming service, not a health checker: it will keep handing out an address after the server behind it fails, until the answer expires.
Text description of the diagram
- The recursive resolver walks the lookup and caches answers.
- The root server refers to TLD servers and the TLD server refers to the domain's servers.
- Only the authoritative server holds the final record.
How to answer it in an interview
What is a DNS server and what happens when I look up a domain?
DNS is a distributed database of records, and "DNS server" is a role, not one machine. My device asks a recursive resolver, which checks its cache. On a miss it asks a root server, which refers it to the TLD servers, which refer it to the domain's authoritative server. That server returns the record with a time to live, and the resolver caches it. The trade-off is that a long time to live is fast but makes changes slow, so I lower it before a migration.
The spoken structure: say it is a role, walk the four hops in order, name the cache and the time to live, then give the trade-off.
Common mistakes
- "A DNS server is one machine that knows every domain." (wrong) Each role knows only part of the answer. (right) "Root servers refer to TLD servers, which refer to the authoritative server that holds the record."
- "Root servers return the IP address." (wrong) They return a referral. (right) "The root points the resolver at the TLD servers; only the authoritative server answers."
- "I changed the record, so everyone sees it now." (wrong) Caches keep the old value until the time to live ends. (right) "I lowered the time to live ahead of time so caches expire quickly."
- "DNS fails over automatically when a server dies." (wrong) DNS does no health checking. (right) "A separate health check updates the record, and the time to live bounds how fast clients follow."
Follow-up questions
What is a DNS?
DNS is the Domain Name System, the distributed, hierarchical database that maps names to records such as IP addresses. A DNS server is any server that takes part in answering queries against it.
Is a DNS server the same thing as a resolver?
Not always. A resolver is the role that asks questions and follows referrals, and a recursive resolver is also a DNS server. An authoritative server is a different role: it answers about its own domains and does not walk the hierarchy. RFC 9499 sets out these terms.
Why does a DNS change take time to show up?
Resolvers and devices cache answers for the record's time to live. Until that timer ends, each cache returns the old value, so the delay is bounded by the old time to live, not by the new one.
What happens if a DNS server is down?
It depends on the role. A domain normally lists more than one authoritative server, so a resolver can try another, and a client can use a second resolver. Cached answers keep working until they expire, which is one reason a longer time to live adds resilience.
Where does DNS fit in a system design answer?
Mention it at the front door: how users find the service, what time to live you choose, and how traffic moves during failover. Link it to the rest of the design in the distributed systems interview guide, and expect follow-ups from backend interview questions and from rate limiting at an application programming interface (API) gateway.
- "DNS server" names a role: recursive resolver, root, TLD or authoritative.
- The resolver walks the hierarchy through referrals; only the authoritative server holds the record.
- Every answer carries a time to live that tells caches how long to keep it.
- Caching makes lookups fast and also makes changes slow to spread.
- Lower the time to live well before a migration, by at least the old value.
Sources
- RFC 9499: DNS Terminology — IETF (Hoffman, Sullivan, Fujiwara), 1 Mar 2024
- RFC 1034: Domain Names - Concepts and Facilities — IETF (Mockapetris), 1 Nov 1987
- RFC 1035: Domain Names - Implementation and Specification — IETF (Mockapetris), 1 Nov 1987
- RFC 2308: Negative Caching of DNS Queries — IETF (Andrews), 1 Mar 1998
