What Is DNS Caching

What Is DNS Caching and How Does It Work?

DNS caching is the temporary storage of DNS lookup results to reduce query latency and authoritative nameserver load. Every DNS record has a TTL (Time to Live) value — a number of seconds that instructs resolvers how long they may cache that record's answer before they must re-query the authoritative nameserver for a fresh result.

Where DNS Caching Happens

DNS caching occurs at multiple independent layers between your device and the authoritative nameserver. Understanding each layer helps you troubleshoot propagation delays and cache-related issues.

• Browser cache: Chrome, Firefox, Safari, and Edge each maintain their own DNS cache. Browser caches typically honour the record's TTL but have their own minimum and maximum bounds. Chrome's DNS cache can be viewed and cleared at chrome://net-internals/#dns. Firefox caches DNS within its network layer and clears when you restart the browser with cache cleared.
• Operating system cache: Windows uses the DNS Client Service to cache lookups. macOS uses mDNSResponder. Linux systems may use systemd-resolved or nscd. These caches persist across browser sessions and application restarts. Flushing the OS cache does not flush the browser cache — you may need to flush both.
• Router DNS cache: Many home routers and office firewalls cache DNS results for all devices on the local network. This cache can serve stale data even after you've flushed your device's local cache. Restarting the router clears its DNS cache.
• ISP recursive resolver: Your Internet Service Provider runs DNS resolvers that cache records for all of their subscribers. ISP resolvers often cache longer than the published TTL, especially for heavily queried domains.
• Public resolvers: Services like Google (8.8.8.8), Cloudflare (1.1.1.1), and OpenDNS cache records globally. These resolvers tend to be more reliable about respecting published TTL values than ISP resolvers.

How TTL Controls Cache Duration

The TTL value on a DNS record is the maximum time, in seconds, that a resolver is permitted to cache that record. Common TTL values:

• 300 seconds (5 minutes): Low TTL used before planned DNS migrations. Records propagate quickly after a change but increase query load on your nameservers.
• 3600 seconds (1 hour): A common default. Good balance between cache efficiency and propagation speed for most use cases.
• 86400 seconds (24 hours): High TTL appropriate for stable records like MX records that rarely change. Reduces nameserver load but slows propagation if you need to make emergency changes.

The recommended practice for planned DNS changes is to lower your TTL to 300 seconds at least 48 hours before the change, make the change, verify it has propagated, then optionally raise the TTL back to a higher value for efficiency.

Practical Guide: Lowering TTL Before DNS Changes

If you change a DNS record without lowering the TTL first, every resolver that recently cached the old record will serve the old value until the original TTL expires. For a record with TTL 86400 (24 hours), this means some users see the old value for up to 24 hours after your change. The correct procedure for any planned migration:

1. 48 hours before the change: Lower the TTL on every record you plan to change to 300 seconds. This means any cached copies expire quickly after your change is made.
2. Wait 48 hours: Allow the lowered TTL itself to propagate globally. Once 48 hours have passed, all resolvers have expired their caches of the old TTL value and re-queried with the new 300-second TTL.
3. Make the DNS change: Update the record values — new IP address, new MX records, or whatever the change requires. With a 5-minute TTL, most resolvers pick up the change within 5-15 minutes.
4. Verify propagation: Use the DNS propagation checker to confirm the new values are live globally. At 300 seconds TTL, propagation should be complete for 95% or more of global resolvers within 30 minutes.
5. After propagation completes: Optionally raise the TTL back to 3600 or 86400 to reduce DNS query load on your nameservers. Low TTL increases query frequency, which is negligible for small sites but adds cost at scale on providers like AWS Route 53 that charge per query.

ISP DNS Caching: The Part You Cannot Control

While you can flush your own device's DNS cache and control the TTL on your records, you cannot force ISP resolvers to expire their caches early. Some ISPs cache DNS records beyond the published TTL — this is technically non-compliant with RFC 1035 but common in practice. If users are still seeing old DNS values after your TTL has expired on major public resolvers (Google 8.8.8.8, Cloudflare 1.1.1.1), their ISP's resolver is likely the source. There is no remedy other than waiting — most ISP resolvers refresh within 24-48 hours even if they cache beyond TTL. Corporate networks that run internal DNS resolvers may need a manual flush by an IT administrator.

Negative DNS Caching

When a resolver queries for a hostname that does not exist and receives an NXDOMAIN response, it caches that negative result. The caching duration for NXDOMAIN responses is controlled by the negative TTL value in the zone's SOA record, typically 1800 to 3600 seconds. If you add a new DNS record and some users still get NXDOMAIN, it may be because their resolver cached an NXDOMAIN before you added the record. Lowering the SOA negative TTL before adding new records helps prevent this. Negative caching is separate from the per-record TTL — the SOA negative TTL applies to all missing records in the zone.

DNS Cache vs DNS Propagation

These terms are often confused. DNS propagation refers to the time it takes for a change to spread from the authoritative nameserver to all recursive resolvers worldwide. The propagation window is bounded by the TTL — once all cached copies of the old record expire, propagation is complete. Cache poisoning is a different issue where a resolver stores a fraudulent record injected by an attacker — DNSSEC protects against this by adding cryptographic signatures to DNS responses. Check if your domain has DNSSEC enabled with the DNSSEC validator. See the DNS not propagating fix guide if your changes are taking longer than expected. Use the DNS propagation checker to test which global servers are still serving cached data, and Why Is DNS Not Updating After 24 Hours for a full troubleshooting checklist.