DNS
In one line
DNS is the internet's distributed, heavily cached phone book that turns names like example.com into IP addresses by asking root, TLD and authoritative servers in turn.
What it is
The Domain Name System maps human-friendly names to records. The most common records are A (name to IPv4 address), AAAA (name to IPv6), CNAME (alias to another name), MX (mail servers), TXT (free text, used for domain verification and email policies like SPF) and NS (which servers are authoritative for a zone).
DNS is hierarchical: the root servers know who runs each top-level domain (.com, .org, .in), the TLD servers know which name servers are authoritative for each domain, and the authoritative servers hold the actual records. Every answer has a TTL (time to live) saying how many seconds it may be cached.
Why interviewers ask
DNS is step one of almost every network request and a frequent cause of outages and slow page loads. Interviewers ask about it in 'what happens when you type a URL', in system design (DNS-based load balancing, failover, CDNs), and to see whether you understand caching and TTL trade-offs.
How it works
- 1The application asks the operating system's stub resolver for a name. The OS checks its own cache and the hosts file first.
- 2On a miss, the stub sends a query (usually UDP port 53) to a recursive resolver, such as your ISP's resolver, 8.8.8.8 (Google) or 1.1.1.1 (Cloudflare).
- 3If the resolver has no cached answer, it asks a root server, which refers it to the TLD servers for .com.
- 4The .com TLD server refers it to the domain's authoritative name servers (the NS records).
- 5The authoritative server returns the record, for example an A record with a TTL of 300 seconds. The resolver caches it and returns it to the client, which also caches it.
- 6Later lookups within the TTL are answered from cache in about a millisecond instead of several network round trips.
Worked example · Resolving www.shop.com for the first time
- Browser cache: miss. OS cache: miss. Query goes to resolver 1.1.1.1.
- Resolver cache: miss. It asks a root server: 'www.shop.com?' Root replies: 'ask the .com servers' (a referral, with their addresses).
- Resolver asks a .com server. Reply: 'shop.com is served by ns1.dnsprovider.net'.
- Resolver asks ns1.dnsprovider.net. Reply: 'www.shop.com CNAME shop.cdn.net'. The resolver now resolves shop.cdn.net the same way and gets A 203.0.113.10, TTL 60.
- Resolver returns 203.0.113.10 to the browser and caches it for 60 seconds. The first lookup took about 80 ms; the next one from another user of the same resolver takes about 1 ms.
- The browser now opens a TCP connection to 203.0.113.10 port 443.
Picture it
DNS is like asking a librarian (the resolver) for a book's shelf. The librarian checks the catalogue at the front (cache); if it is not there they ask the main index (root), which points to the right section (TLD), whose staff point to the exact shelf (authoritative). The librarian then writes it down for a while so the next person gets an instant answer.
Key patterns
TTL tuning
When: Balancing change speed against lookup cost
How: Short TTLs (30 to 300 seconds) for records you may fail over; long TTLs (hours) for stable records. Lower the TTL well before a planned change.
CNAME to a managed service
When: Pointing your domain at a CDN, load balancer or SaaS
How: Create www CNAME to the provider's host name so they can change IPs freely. A CNAME cannot sit at the zone apex; use the provider's ALIAS or flattening feature there.
DNS load balancing and failover
When: Spreading users across regions
How: Return several A records or region-specific answers with health checks. It is coarse: clients cache answers, so pair it with real load balancers.
Real-world use
Public resolvers
Google Public DNS (8.8.8.8) and Cloudflare (1.1.1.1) are recursive resolvers serving huge numbers of users, with big shared caches and support for encrypted DNS (DNS over HTTPS and DNS over TLS).
DNS-based traffic routing
AWS Route 53 offers latency-based, geolocation and weighted routing plus health checks, returning different IPs to different users and removing unhealthy endpoints.
CDNs
Akamai and Cloudflare use DNS answers (and anycast addresses) so a user in Mumbai and a user in London get sent to nearby edge servers for the same name.
The 2016 Dyn outage
A large DDoS attack on DNS provider Dyn made sites like Twitter, GitHub and Netflix unreachable for many users even though their servers were up, showing why DNS needs redundancy across providers.
In a project
You must move a production website from an old data centre to a cloud provider with minimal downtime.
- Two days before, lower the TTL of the A record from 86400 seconds (1 day) to 60 seconds, so caches soon hold the record for only a minute.
- Run the new environment in parallel and test it using a hosts file entry or a temporary subdomain.
- Switch the A record to the new IP. Within a few minutes most resolvers pick up the change; keep the old servers running for stragglers that ignore TTLs.
- After traffic has moved and is stable, raise the TTL again (for example to 3600) to reduce query load and latency.
Impact: The cutover completes in minutes instead of a day of split traffic, rollback is just changing the record back, and users see no visible downtime.
Trade-offs
Use it when
- Mapping stable names to changing infrastructure
- Coarse global traffic steering by region or latency
- Domain ownership proofs and email policies via TXT records
Avoid it when
- Fast failover measured in seconds: caches and clients may ignore or stretch TTLs
- Fine-grained per-request load balancing; use an L4 or L7 load balancer
- Relying on a single DNS provider for a critical service
Cost: Uncached lookup: several round trips (often 20 to 120 ms); cached lookup: under a few ms. Most queries use UDP port 53, falling back to TCP for large answers and zone transfers.
Common mistakes
- Saying DNS changes 'propagate': nothing is pushed; old answers simply expire from caches after their TTL.
- Forgetting the many cache layers: browser, OS, resolver and sometimes the application or JVM.
- Putting a CNAME at the root of a domain alongside other records, which the standard does not allow.
- Assuming DNS is always UDP: it uses TCP for large responses and zone transfers, and DoH and DoT run over HTTPS and TLS.
- Thinking round-robin DNS gives even load or health awareness on its own.
Interview questions
Quick revision
- A = IPv4, AAAA = IPv6, CNAME = alias, MX = mail, TXT = text, NS = name servers.
- Path: stub resolver, recursive resolver, root, TLD, authoritative.
- Every record has a TTL in seconds; caches keep answers that long.
- Lower TTL before migrations; nothing propagates, caches expire.
- DNS uses UDP port 53, TCP for big answers and zone transfers.
- No CNAME at the zone apex; use ALIAS or flattening.
- DNS can steer traffic by region or weight but is coarse because of caching.
Check yourself
1. Which record maps a host name to an IPv6 address?
2. A record's TTL is 3600. You change it. How long might some users keep the old answer?
3. Which server holds the actual records for example.com?
4. When does DNS typically use TCP instead of UDP?
Saved on this device. Create a free account to keep it on every device.
Practise this with Sam
A real mock interview, out loud, with an honest scorecard. Free to start.