A DNS cache is a temporary store of previously obtained DNS answers, such as the IP address for a domain name, that a resolver, operating system, browser or other client keeps so it can answer repeated queries without asking the DNS hierarchy again. In DNS each cached record is kept only for the time to live (TTL) set by the authoritative server, after which it must be fetched anew.
Caching is what makes the Domain Name System fast and scalable. Without it, every lookup would travel to root, top-level domain and authoritative servers, adding tens to hundreds of milliseconds and multiplying load on those servers. The same mechanism explains why DNS changes are not visible everywhere at once, a delay often described as DNS propagation.
How a DNS cache answers queries
When an application needs an address, the query passes through several layers of caching before any network request is made. Each layer checks whether it holds a valid answer; if so, it replies immediately, and if not, it forwards the query to the next layer. A recursive resolver that misses its cache performs full resolution by querying the root, the TLD servers and the authoritative servers, then stores every answer it received.
| Layer | Where it lives | Typical retention |
|---|---|---|
| Application cache | Browser or runtime, such as a browser host cache | Seconds to about one minute, often capped below TTL |
| Operating system cache | Stub resolver service on the device | Up to the record TTL |
| Local network cache | Home router or office forwarder | Up to the record TTL |
| Recursive resolver cache | ISP, enterprise or public resolver | Up to the TTL, bounded by resolver limits |
Each cached entry counts down from the TTL it was received with. A downstream client that asks a resolver receives the remaining TTL, not the original value, so a record with a TTL of 3,600 seconds that has been cached for 3,000 seconds reaches the client with 600 seconds left. This keeps all layers roughly synchronized with the authoritative expiry.
TTL values and what they control
The TTL is the main control a domain owner has over caching. It is set per record set in the DNS zone and expressed in seconds. Short values allow fast changes but increase query volume and dependence on authoritative server availability; long values reduce load and latency but slow down changes.
| TTL range | Typical use | Advantage | Drawback |
|---|---|---|---|
| 30 to 300 seconds | Failover records, planned migrations | Changes take effect quickly | More queries, more exposure to outages |
| 3,600 seconds | Ordinary web and mail records | Balanced load and agility | Changes take up to an hour |
| 86,400 seconds | Stable records such as NS delegations | Minimal query load | Changes take up to a day |
Resolvers often apply their own bounds. Many enforce a maximum cache time, commonly about one day to one week, and some raise very low TTLs to a minimum. Failed lookups are cached too: negative caching stores NXDOMAIN and no-data answers for a period derived from the zone’s SOA record, typically from a few minutes to a few hours.
DNS cache compared with related DNS concepts
A DNS cache is a function, not a separate server type. Recursive resolvers almost always include one, while authoritative servers do not cache other zones’ data. Confusing these roles leads to wrong troubleshooting steps.
| Term | Relationship to the cache | Key point |
|---|---|---|
| DNS resolver | Usually contains the main cache | Answers from cache or resolves recursively |
| Authoritative DNS | Source of the records being cached | Sets the TTL, does not cache other zones |
| Time to live | Lifetime of each cached record | Controls freshness |
| DNS propagation | Visible effect of caches expiring at different times | Not an active push of changes |
| DNSSEC | Signatures cached with records | Validated answers can be served from cache |
Inspecting and flushing a DNS cache
Flushing a cache removes stored entries so that the next query fetches fresh data from upstream. It is useful after a DNS change, when troubleshooting a site that resolves to an old address, or after a suspected poisoning incident. Flushing a local cache does not affect upstream resolvers, which keep their copies until the TTL ends.
| Platform | Typical method | Note |
|---|---|---|
| Windows | ipconfig /flushdns | Clears the DNS Client service cache |
| macOS | dscacheutil -flushcache and restarting mDNSResponder | Exact steps vary by version |
| Linux with systemd-resolved | resolvectl flush-caches | Other resolvers use their own commands |
| Chromium-based browsers | Clear host cache on the internal net-internals page | Separate from the OS cache |
| Public resolvers | Purge forms offered by some operators | Clears one name, not the whole cache |
To see what a resolver returns and how much TTL remains, administrators query it directly with tools such as dig or nslookup. Comparing answers from several resolvers shows which caches still hold the old record.
Security risks and common mistakes
Because caches serve answers to many users, a poisoned entry can redirect every user of a resolver to a malicious server until the record expires. DNS cache poisoning attacks attempt to inject forged responses; modern resolvers defend with randomized source ports and query IDs, and DNSSEC validation rejects unsigned or tampered data for signed zones.
- Lowering the TTL too late before a migration has no effect until the old, longer TTL has expired in caches.
- Flushing only the local cache does not help when the ISP resolver still holds the old record.
- Forgetting browser caches makes a site appear unchanged even after the OS cache is cleared.
- Ignoring negative caching causes a newly created subdomain to fail for a while after an earlier failed lookup.
- Hard-coding addresses in applications that cache lookups indefinitely bypasses TTL and breaks failover.
Stripped to the essentials
Every website has a name that people use and a number that computers use. Finding the number takes a short trip across the internet. A DNS cache is a memory of recent lookups, so the trip does not have to be repeated every time.
It is like writing a friend’s phone number on a sticky note instead of searching the phone book again. Each note has an expiry time set by the website owner. When the note expires, the computer looks the number up again. That is why changes can take a while to reach everyone.
Where it is applied
An online shop plans to move its website to a new hosting provider on a Saturday night. Its main address record has a TTL of 86,400 seconds, so caches around the world could keep the old address for a full day after the switch.
On Wednesday the administrator lowers the TTL to 300 seconds, which gives the old one-day value time to expire everywhere before the move. On Saturday the record is updated to the new address, and within about five minutes most visitors reach the new servers. The old server keeps running for one more day to serve any client with a stale cache. A support agent who still sees the old site clears the browser host cache and the operating system cache, and the new site appears.
After a stable week the TTL is raised back to 3,600 seconds, reducing query load while keeping future changes reasonably fast.