Overview
If every name lookup had to walk the full DNS hierarchy, the internet would be slow and the root servers overwhelmed. Caching is what makes DNS fast and scalable: answers are remembered for a while and reused. This lesson explains DNS caching and the role of the TTL.
Learning objectives
- Explain why DNS uses caching.
- Describe how TTL controls cache lifetime.
- Identify where caching happens along the resolution path.
Core concept
DNS caching stores the answer to a lookup so that subsequent requests for the same name can be answered immediately, without repeating the full resolution. How long an answer may be cached is governed by its TTL (time-to-live), a value (in seconds) set on each record by the domain's administrator. When the TTL expires, the cached entry is discarded and the next lookup fetches a fresh answer.
Caching happens at multiple points: the operating system, the recursive resolver, and sometimes the application/browser.
How it works
The first lookup for a name does the full work and the result is cached at each layer that handled it, tagged with its TTL. While the TTL is valid, repeat lookups are served from cache — fast and cheap. A short TTL means changes propagate quickly but caches refresh often (more queries); a long TTL means fewer queries and faster responses but slower propagation when a record changes. Administrators tune TTLs to balance performance against how quickly they may need to change a record.
Practical example
A site's A record has a TTL of 3600 seconds (one hour). The first visitor triggers a full resolution; for the next hour, that answer is served from caches everywhere it was stored. If the administrator plans to move the site to a new IP, they often lower the TTL in advance so old cached answers expire quickly and users pick up the new address soon after the change.
Cybersecurity relevance
Caching interacts with security in important ways. DNS cache poisoning aims to insert a false answer into a resolver's cache so users are misdirected until the TTL expires — long TTLs make such poisoning last longer. During incident response, defenders account for caching when blocking a malicious domain, since cached answers can persist. Understanding TTL behavior is essential to both attack timelines and remediation.
Common mistakes
- Forgetting cached records persist until TTL expiry, so a DNS change (or a block) may not take effect immediately.
- Setting TTLs too long before a planned change, causing stale answers to linger.
- Assuming one cache — answers may be cached at OS, resolver, and application layers simultaneously.
Key takeaways
- Caching reuses previous DNS answers to make resolution fast and reduce load on the hierarchy.
- The TTL on each record controls how long it may be cached; short TTLs propagate changes faster, long TTLs reduce queries.
- Caching happens at OS, resolver, and application layers, and it shapes both poisoning attacks and remediation timing.
Check your understanding
- What does a record's TTL control, and what is the trade-off between short and long TTLs?
- Why might an administrator lower a record's TTL before migrating a service to a new IP address?