Free preview

Cheat Sheet

Key takeaway

DNS maps names to addresses through a delegated hierarchy, absorbs load with multi-layer caching, stays up via anycast replication and stateless UDP, and accepts eventual consistency on purpose. It is the internet's directory and your first, coarsest load balancer.

Key terms

TermOne line
Resource record (RR)Smallest unit of DNS data: type, name, value (plus TTL)
Name serverAny server that answers DNS queries
ResolverServer that resolves on the client's behalf and caches; usually the ISP's
Authoritative serverHolds the real records for a zone — the source of truth
ZoneThe slice of namespace one operator is authoritative for
DelegationHanding a subtree to another operator, via NS records
TTLHow long a resolver may cache a record
AnycastMany machines sharing one IP; routing picks the nearest
NXDOMAIN"Name does not exist" — cached too (negative caching)
GSLBGlobal server load balancing — DNS-level region selection

Record types

TypeMapsNameValueExample
AHostname to IPHostnameIP address(A, relay1.main.educative.io, 104.18.2.119)
NSDomain to its authoritative DNSDomain nameHostname(NS, educative.io, dns.educative.io)
CNAMEAlias to canonical hostnameHostnameCanonical name(CNAME, educative.io, server1.primary.educative.io)
MXMail alias to mail serverHostnameCanonical name(MX, mail.educative.io, mailserver1.backup.educative.io)

Also: AAAA (IPv6) · TXT (verification, SPF/DKIM) · SRV (service+port) · PTR (reverse) · SOA (zone metadata)

Only A terminates a lookup. NS = delegation, CNAME = indirection, MX = service pointer. CNAME cannot sit at the zone apex — use ALIAS/ANAME.

The hierarchy

Resolver  ->  Root  ->  TLD  ->  Authoritative  ->  IP
(caches)     (.io?)    (which  (the actual
             which     server   records)
             TLD)      for it)
TierKnowsDoesn't know
RootName servers for every TLDAnything about a specific domain
TLDAuthoritative servers per domainAny individual host's IP
AuthoritativeEvery record in its zoneAnything outside it

Names read RIGHT to LEFTeducative.io resolves .io first. That's what makes delegation work: adding a domain touches one TLD server.

Resolution modes

IterativeRecursive
Who navigatesThe local serverEach server in turn
Upstream returnsA referralThe final answer
Load on root/TLDLow, statelessHigh, holds state
Used forResolver → hierarchyClient → resolver

Real answer: both. Stub resolver → resolver is recursive; resolver → hierarchy is iterative, so shared infrastructure stays stateless.

Caching

Browser -> OS -> Local/ISP resolver -> Hierarchy
   (hit stops the lookup at that layer)

Even on a miss, the resolver may hold cached TLD or authoritative addresses and skip the root entirely.

TTLHit rateYour DNS loadPropagationGood for
30–60 sLowHighMinutesFailover targets, imminent migrations
300 sGoodModerateReasonableGeneral default
24 hVery highLowA day+NS, MX, apex — stable records

TTL is a request, not a guarantee. Resolvers clamp it, browsers have their own logic, and long-lived processes resolve once at startup.

The migration playbook

1. Lower TTL          2. WAIT OUT THE OLD TTL    3. Change the record
4. Dual-run both IPs  5. Drain, decommission     6. Raise TTL back

Step 2 is the one people skip and the one that matters. Better: CNAME to a load balancer so the address never changes.

Distributed system properties

  • Scalable — hierarchy divides labor; ~1,000 instances back the 13 logical roots (A–M), run by 12 organizations
  • Anycast — 13 addresses, not machines; routing picks the nearest. Gives scale + proximity + failover in one mechanism
  • Reliable — caching survives server loss · global replication · UDP + retransmit (no connection state to recover)
  • UDP → TCP when responses exceed 512 bytes or for zone transfers. DoH/DoT for privacy
  • Consistencyeventual, deliberately. Propagation takes seconds to days. The canonical AP system: a stale IP usually still works; unresolvable names break everything

Traffic steering

PolicyDecides byUse for
Round robinRotating address orderCrude free distribution
WeightedConfigured ratioCanaries, gradual migration
GeolocationResolver's locationData residency
Latency-basedMeasured latencyFastest region
FailoverHealth checksActive-passive DR

Two-tier pattern: DNS picks the region; a load balancer inside picks the server.

Limits: slow (TTL + non-compliant resolvers) · skewed (one resolver caches one answer for thousands) · blind to server load · resolver location ≠ user location.

Inspecting it

CommandShows
nslookup example.comQuick answer; "Non-authoritative" = from cache
dig example.comFull record, TTL, query time
dig +trace example.comThe whole iterative walk, root → TLD → authoritative
dig example.com MXMail records
dig +short example.comJust the answer

Run dig twice: the TTL counts down. That's the resolver showing you how much life its cached copy has left.

Quick decision cues

  • Need global region selection → DNS / GSLB
  • Need failover in seconds → not DNS; anycast or a load balancer
  • Putting a CDN in front → CNAME (ALIAS at the apex)
  • Planning an IP change → lower TTL first, wait out the old one
  • Record must move fast someday → keep its TTL permanently short
  • Want the address never to change → point at a load balancer, swap behind it
  • Debugging "some users see the old site" → check TTL and cache state per region

Work the Interview Walkthrough for the full design and the Concept Drills for rapid-fire practice.

Enjoying the preview?

Create a free account to unlock the rest of this course, the in-browser judge, and live AI mock interviews.

Sign up free to continue