How it works
An application asks a resolver for a record, usually A for an IPv4 address or AAAA for an IPv6 address. Browser, operating-system, and recursive-resolver caches may answer without contacting the domain's authoritative servers.
On a cache miss, the recursive resolver follows the DNS hierarchy. For api.example.com, it can ask a root server where to find the .com servers, then ask a .com server for example.com's authoritative name servers, then query those servers for the requested record. Cached referrals often let it skip earlier steps.
Authoritative servers publish records for a domain. A and AAAA records contain addresses; a CNAME points to another name that must also be resolved; NS records identify authoritative name servers. For example, api.example.com might resolve to a load balancer's address rather than directly to an application server.
DNS answers include a time to live, or TTL, that tells caches how long they may reuse them. With a 60-second TTL, a resolver can serve many lookups from one cached answer. Negative answers, such as a name not existing, can also be cached, so creating a missing record may not fix every client's lookup immediately.
DNS-based traffic steering returns different answers according to configured weights, estimated location, or endpoint health. Many clients share recursive resolvers, so the authoritative server usually sees the resolver's address rather than the client's; some resolvers provide a client-subnet hint. DNS selects an address for a lookup, not a backend for every HTTP request.
After resolution, the client connects to the returned address and performs any required TLS handshake and application requests. Changing DNS does not move existing connections. Traditional DNS uses UDP or TCP on port 53; encrypted transports such as DNS over HTTPS change how the resolver is reached, not the basic naming and caching model.
A worked example
Keeping DNS off a crawler's critical path
Suppose a crawler targets 20,000 page fetches per second across 2,000 active hostnames. If each hostname has one relevant address record with a 60-second TTL, a shared cache needs roughly 2,000 / 60, or 33 successful refreshes per second in steady state, not 20,000. This assumes evenly distributed refreshes, stable records, and no extra alias lookups. Workers use asynchronous resolution with bounded concurrency so one slow lookup does not block a fetch thread. The cache respects positive and negative TTLs, while retries use backoff. Monitor cache misses, resolution latency, timeouts, and response codes separately from HTTP failures. Per-host politeness limits still apply after resolution.
Trade-offs to say out loud
- Caching efficiency versus routing freshness
- Longer TTLs reduce upstream lookups, while shorter TTLs allow faster routing changes at the cost of more resolution work and greater exposure to resolver or authoritative-server outages.
- Global steering versus coarse control
- DNS can distribute clients across regions, but shared resolver caches, approximate location, and connection reuse prevent precise per-request balancing.
- Failover simplicity versus uncertain recovery time
- Health-aware DNS can stop returning a failed endpoint, but detection delays, cached answers, client behavior, and existing connections mean the TTL is not a hard recovery deadline.
- Stable names versus discovery staleness
- DNS keeps endpoint addresses out of application configuration, but rapidly changing service membership may require discovery clients or proxies that react faster than DNS caches.
- Availability versus operational dependencies
- Redundant authoritative servers and resolvers improve resilience, but broken delegation, expired domains, or incorrect records can make an otherwise healthy service unreachable.
- Authenticity versus confidentiality
- DNSSEC can validate signed DNS data but does not encrypt queries, while encrypted DNS protects the client-to-resolver transport without making a malicious destination safe.
When to reach for it
- You need a stable public hostname that resolves to a CDN, reverse proxy, or load balancer.
- A multi-region design needs coarse geographic routing, weighted traffic distribution, or health-aware endpoint selection.
- You are designing a crawler, where repeated lookups, slow resolvers, and nonexistent domains can limit fetch throughput.
- An internal service needs name-based discovery, and its clients can tolerate cached endpoint information.
- You are planning an endpoint migration and need to explain how old and new addresses coexist during cutover.
How to bring it up in the interview
- Separate the resolution path from the request path: DNS finds an address; the load balancer or proxy handles requests after connection establishment.
- State what the hostname resolves to and why, such as a regional load balancer rather than individual application instances.
- Give a TTL choice with a reason, then explain that health-check delay, resolver behavior, retries, and connection lifetimes also affect failover.
- For migrations, lower the TTL ahead of time and wait out the previous TTL before switching; keep the old endpoint available while stale clients drain.
- Expect follow-ups about authoritative-server redundancy, negative caching, resolver outages, and how to measure resolution latency separately from connection and application latency.
Common mistakes
- Saying DNS forwards HTTP traffic or balances every request; clients connect directly to the returned address.
- Claiming that a 30-second TTL guarantees every client switches endpoints within 30 seconds.
- Assuming multiple returned addresses provide health checks or reliable failover without additional client or DNS-provider behavior.
- Treating DNS changes as an instantaneous global update rather than authoritative changes observed through independent caches.
- Assuming DNS proves an endpoint is trustworthy; TLS certificate validation and application authorization remain necessary.
Where it comes up
Interview questions where dns is part of a strong answer, and why.
Questions people ask
How does DNS work step by step?
A client checks available caches and asks a recursive resolver for the name. On a cache miss, the resolver follows referrals from root to top-level-domain to authoritative servers, skipping any steps it already has cached. It returns the requested records, which the client uses to establish a connection.
What is the difference between DNS load balancing and a load balancer?
DNS load balancing influences which address a client discovers, and its decisions are cached. A network or application load balancer receives connections or requests and chooses a backend using more current health and capacity information. Designs often use DNS to select a region and a load balancer within that region.
How long do DNS changes take to propagate?
There is no single global propagation event: authoritative servers publish the update, while existing cached answers remain usable until they expire. A client that just cached an answer may retain it for nearly the full previous TTL. Provider update delays, application caches, serve-stale behavior, and long-lived connections can extend the time before all traffic moves.