When your browser needs to connect to example.com, it can't use the name directly — it needs an IP. DNS is the system that looks it up. The journey goes through several layers, each one potentially caching the answer.
Choose a scenario
ready
What is each node?
Caching & TTL
How DNS answers are stored and when they expire
Every DNS answer carries a TTL (Time To Live) in seconds. Every node in the chain — your OS, the local resolver — stores the answer until the TTL expires. A cached answer means skipping some or all of the resolution chain.
The caching chain
① OS / Browser Cache
Fastest. Stored in RAM. Checked first. Usually lasts the full TTL value from when it was fetched.
Check on Linux: resolvectl statistics On Windows: ipconfig /displaydns
② Local Resolver (stub)
Your router or 127.0.0.53 (systemd-resolved). Forwards queries to your recursive resolver (ISP or 8.8.8.8).
Does the actual work. Queries Root → TLD → Authoritative. Caches each RR with its TTL. Shared across many users.
Common resolvers: 8.8.8.8 Google 1.1.1.1 Cloudflare
Live cache simulator
🗄️ Recursive Resolver Cache
Name
Type
RDATA
TTL remaining
Status
How TTL works
Low TTL (60–300s)
✓ Changes propagate fast
✓ Good before migrations
✗ More DNS queries = more latency
✗ More load on your nameservers
High TTL (3600–86400s)
✓ Fewer queries = faster responses
✓ More resilient (outlasts outages)
✗ Old IPs stay cached longer
✗ Changes take hours to propagate
Best practice: lower TTL to 300s before a planned change, then raise it back after.
Negative caching (NXDOMAIN)
When a domain does not exist, resolvers also cache that fact (called a negative cache entry). The TTL for negative caching comes from the SOA record's Min TTL field. This prevents hammering the nameservers with repeated NXDOMAIN queries.
example.com.86400INSOA ns1. admin. 2024022801 3600 900 604800 300 ↑ Min TTL — NXDOMAIN cached for 300s
Resource Records (RRs)
The data units that DNS stores and returns
A Resource Record (RR) is the basic unit of data in DNS. When a resolver queries an authoritative nameserver, it gets back one or more RRs. Each RR has the same wire format — only the RDATA field changes meaning by TYPE.
Universal RR format — every DNS answer looks like this
example.com.NAME — what name is being answered
3600TTL — cache this for N seconds
INCLASS — always IN (Internet)
ATYPE — what kind of data
93.184.216.34RDATA — the actual answer (varies by TYPE)
How RRs answer different questions
Question
"What is the IP of example.com?"
→ resolver queries TYPE A
example.com.3600INA93.184.216.34
Question
"Where do I send email for @example.com?"
→ resolver queries TYPE MX
example.com.3600INMX10mail.example.com.
Question
"Who controls the DNS for example.com?"
→ resolver queries TYPE NS
example.com.86400INNSns1.example.com.
Question
"What host is at 8.8.8.8?"
→ resolver queries TYPE PTR on reversed IP
8.8.8.8.in-addr.arpa.INPTRdns.google.
RR sets — multiple records for the same name + type
Multiple RRs with the same NAME + TYPE form an RRset. They're returned together. Used for round-robin load balancing (A records) or fallback chains (MX records).
; RRset — 3 A records for www.example.com (returned together, resolver picks one)www.example.com.300INA10.0.0.1; server 1www.example.com.300INA10.0.0.2; server 2www.example.com.300INA10.0.0.3; server 3;; MX RRset — ordered by priority (lowest = tried first)example.com.3600INMX10mail1.example.com.; primaryexample.com.3600INMX20mail2.example.com.; backup
Where RRs live in the DNS hierarchy
Root zone ( . )
Stores NS records for TLDs 13 root server clusters
com.NSa.gtld-servers.net.
TLD zone ( .com )
Stores NS records for second-level domains + glue A records