DNS Records & Concepts
What is DNS caching?
DNS caching is the process of storing DNS lookup results temporarily so that future requests for the same information can be answered immediately from the stored copy rather than repeating the full lookup process. When a DNS resolver looks up the IP address for example.com and receives the answer it saves that answer, along with an expiry time determined by the record’s DNS TTL: and serves it to any subsequent request for the same record without querying the authoritative nameserver again.
Caching is one of the most fundamental mechanisms in the DNS system. Without it every DNS lookup, and there are billions every day, would require a full query chain from the resolver through root nameservers, TLD nameservers, and authoritative nameservers. This volume of queries to authoritative nameservers would be impossibly large. Caching absorbs the overwhelming majority of DNS query volume at resolver and client levels, reducing the load on authoritative infrastructure to manageable levels while making DNS resolution fast enough to be imperceptible.
The same caching that makes DNS fast is also what causes DNS propagation delays. When a DNS record changes the new value is immediately available on the authoritative nameserver, but all the cached copies of the old value throughout the resolver network continue to be served until they expire. The interaction between caching and propagation is one of the most important practical aspects of DNS management for anyone making changes to domain configuration.
Where DNS caching happens
DNS caching does not happen in a single place, it occurs at multiple layers between the authoritative nameserver and the end user. Each layer has its own cache with its own expiry times and its own behaviour. Understanding each caching layer helps explain why DNS changes can appear to take effect quickly for some visitors and slowly for others.
Browser cache: the first cache consulted when a browser needs to resolve a domain name. Modern browsers maintain their own DNS cache independent of the operating system. When a domain has been recently visited the browser may serve the cached IP address directly without querying the operating system or resolver at all.
Browser DNS caches typically have short cache durations, often one minute to a few minutes regardless of the record’s TTL, and cache sizes are limited. Chrome, Firefox, Safari, and Edge all implement browser-level DNS caching with slightly different behaviours. The short duration means browser caches typically do not persist DNS information as long as resolver caches, they are the first layer to pick up DNS changes in practice.
Operating system cache: the second cache layer. When the browser does not have a cached result it queries the operating system’s DNS resolver. Modern operating systems, Windows, macOS, Linux, maintain a DNS cache at the OS level. The OS cache is shared across all applications on the device, not just the browser. Any application that makes a DNS lookup contributes to and benefits from the OS cache.
The OS cache respects the TTL values on DNS records, storing results for the duration specified by the record’s TTL before marking them as expired. Expired entries are refreshed on the next query rather than being immediately discarded. The OS cache is consulted before any network DNS query is made, serving cached results from memory in microseconds.
Recursive resolver cache: the third and most significant caching layer for DNS propagation purposes. When neither the browser nor OS cache has a fresh result a network query is sent to the configured recursive resolver. The resolver, typically an ISP’s resolver, a corporate DNS server, or a public resolver like 8.8.8.8: maintains a large cache of DNS records it has looked up for all its clients.
Resolver caches are shared across all users of that resolver, a resolver serving millions of ISP customers caches popular domain records and serves them to all customers without repeating authoritative lookups. Resolver caches strictly respect TTL values from authoritative nameservers, a record with TTL 3600 is cached for exactly 3600 seconds before the resolver queries the authoritative nameserver again.
The resolver cache is the layer that matters most for DNS propagation. After a DNS record changes on the authoritative nameserver all resolver caches worldwide continue serving the old value until their cached copies expire. The time it takes for resolver caches worldwide to expire their copies of the old record and fetch the updated value is the propagation window.
Authoritative nameserver cache: authoritative nameservers cache records from zones they are not authoritative for, primarily glue records and NS records from parent zones that they encounter during resolution. This caching is minimal compared to resolver caching and less relevant to everyday DNS management.
How DNS caching works with TTL
The DNS TTL: Time To Live, is the value set on each DNS record that controls how long resolvers cache it before fetching a fresh copy. TTL is the primary mechanism through which authoritative nameserver operators control DNS caching behaviour.
When a resolver fetches a DNS record from an authoritative nameserver the record is returned with its TTL value. The resolver stores the record in its cache with an expiry time calculated as the current time plus the TTL. While the cached copy is fresh, before the expiry time, the resolver serves it to all clients requesting the same record.
As the cached record ages the remaining TTL decreases. When the resolver serves a cached record to a client it returns the remaining TTL, not the original TTL. A resolver that cached an A record with TTL 3600 forty minutes ago serves the record with a TTL of approximately 1200, the remaining 20 minutes of cache time. This decremented TTL propagates downstream, if the client caches the result it knows to check for a fresh copy in 20 minutes rather than a full hour.
When the expiry time passes the cached copy is marked as stale. The next query for the record triggers a fresh lookup from the authoritative nameserver. The resolver fetches the current value, which may or may not have changed, and caches it with the TTL value from the fresh response. The cycle restarts.
Negative caching, caching the fact that a record does not exist, works similarly. When a resolver queries for a record and receives a NXDOMAIN response, indicating the name does not exist, it caches that negative result for the duration specified in the SOA record’s minimum TTL field. Subsequent queries for the same non-existent name are answered from the negative cache without querying the authoritative nameserver again.
DNS caching and propagation
The relationship between DNS caching and DNS propagation is direct and fundamental. Propagation delay is entirely a consequence of caching, the time it takes for cached copies of old records to expire across all resolver caches worldwide.
When a DNS record is changed on the authoritative nameserver the change is immediately available to any resolver that queries the authoritative nameserver fresh. But every resolver that has a valid cached copy of the old record continues serving it until the cached copy expires. The propagation window, the period during which some resolvers serve the old value and others serve the new value, lasts until the last cached copy of the old record expires anywhere in the world.
The maximum propagation window for a record change is determined by the TTL that was set on the record before the change was made. A record with TTL 3600 that was just cached by some resolver will continue to be served by that resolver for up to 3600 seconds after the record was changed on the authoritative nameserver. No resolver can be forced to expire its cache early, it will serve the cached value until the TTL expires regardless of what changes have been made on the authoritative nameserver.
This is why the pre-migration TTL reduction strategy, lowering TTL well before planned DNS changes, is so important. Once the low TTL has propagated to all resolver caches any change to the record will propagate within the reduced TTL duration. A record with TTL 300 that was just cached expires in at most five minutes, allowing DNS changes to reach all resolvers worldwide within 10 to 15 minutes.
DNS caching and redirect management
DNS caching has specific implications for redirect management that affect how quickly redirect configurations take effect and how changes should be sequenced.
Connecting a domain to redirect infrastructure: when a CNAME record or A record is updated to point a domain to redirect management infrastructure the change propagates according to the TTL on the record being changed. Visitors whose resolvers have cached the old record continue reaching the old server until the cached record expires. Visitors whose resolvers have already fetched the updated record reach the redirect infrastructure and receive redirect responses.
During the propagation window both groups of visitors coexist. Visitors reaching the old server get the old site. Visitors reaching the redirect infrastructure get the redirect. The old server should remain functional throughout the propagation window, decommissioning it before propagation completes leaves some visitors with broken connections.
SSL certificate provisioning timing: redirect management platforms that automatically provision SSL certificates for connected domains use DNS validation, checking for specific TXT or CNAME records that prove domain ownership. The validation requires the DNS records to have propagated to the certificate authority’s resolver before validation succeeds. Adding verification records and immediately attempting certificate issuance may fail if the records have not propagated yet. Allowing a few minutes for propagation after adding verification records before triggering certificate issuance avoids this timing issue.
Cached negative responses blocking new records: if a resolver previously queried for a record that did not exist and received a NXDOMAIN response it caches the negative response for the minimum TTL duration from the SOA record. A newly created DNS record, adding a CNAME to connect a domain to redirect infrastructure, may not be visible to resolvers that cached a negative response for that name until their negative cache expires. The minimum TTL in the SOA record controls how long these negative responses are cached.
Testing redirect configuration during propagation: testing redirect rules during the propagation window requires accounting for DNS caching. Flushing the local DNS cache ensures tests use fresh resolver results rather than locally cached old values. Testing from multiple geographic locations using online tools shows the redirect behaviour from different resolvers in different propagation states.
Clearing and managing DNS caches
Different DNS caches can be cleared through different mechanisms, useful when testing DNS changes and wanting to verify the current authoritative values rather than cached ones.
Flushing the browser DNS cache: each browser has its own DNS cache and its own mechanism for clearing it.
Chrome, navigate to chrome://net-internals/#dns and click Clear host cache.
Firefox, closing and reopening the browser clears the DNS cache. Firefox does not expose a direct DNS cache flush through the interface.
Safari, clearing the browser cache through the Privacy menu clears the DNS cache alongside other cached data.
Flushing the operating system DNS cache: the OS-level DNS cache is shared across all applications and is separate from browser caches.
macOS, sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder
Windows, ipconfig /flushdns from an elevated command prompt.
Linux with systemd-resolved, sudo systemd-resolve --flush-caches
Linux with nscd, sudo service nscd restart
Querying authoritative nameservers directly: bypassing all caches entirely by querying the authoritative nameserver directly returns the current authoritative value regardless of what resolvers have cached:
This shows the current value on the authoritative nameserver, the ground truth, and is the definitive way to verify a DNS change has been made correctly independent of caching.
Checking public resolver caches: querying specific public resolvers shows what those resolvers have cached, useful for checking propagation to specific resolvers:
DNS caching and negative TTL
Negative TTL, the duration for which NXDOMAIN responses are cached, deserves specific attention because it can cause visible delays when creating new DNS records.
The negative TTL is specified in the minimum TTL field of the SOA record for the zone. When a resolver queries for a name that does not exist in the zone and receives a NXDOMAIN response it caches the negative result for this duration.
If a resolver receives a NXDOMAIN for www.example.com: because the CNAME record connecting it to redirect infrastructure has not yet been added, and then the CNAME is added five minutes later the resolver continues serving the cached NXDOMAIN for the remaining negative TTL duration. Visitors using that resolver see DNS failures rather than the redirect even though the record now exists on the authoritative nameserver.
This can cause confusion when connecting a domain to redirect infrastructure. The connection appears to have been made, the CNAME record exists on the authoritative nameserver, but some visitors continue to receive errors. The cause is typically cached negative responses from resolvers that checked for the record before it was created.
Setting an appropriate minimum TTL in the SOA record, 300 to 600 seconds is reasonable for most domains, ensures negative responses expire reasonably quickly without causing excessive re-queries for genuinely non-existent names.
DNS caching security considerations
DNS caching introduces a security consideration, cache poisoning, where an attacker injects false DNS records into a resolver’s cache causing it to serve incorrect IP addresses for legitimate domain names.
Cache poisoning attacks work by sending forged DNS responses that appear to come from authoritative nameservers before the legitimate response arrives. If the forged response is accepted by the resolver it gets cached and served to all clients using that resolver, directing them to the attacker’s server rather than the legitimate destination.
DNSSEC, DNS Security Extensions, addresses cache poisoning by cryptographically signing DNS records. Resolvers that support DNSSEC verify the signatures on records before caching them, forged records without valid signatures are rejected. Major DNS providers and most public resolvers support DNSSEC validation.
DNS-over-HTTPS and DNS-over-TLS encrypt the communication between clients and resolvers, preventing eavesdropping on DNS queries and making it harder for network-level attackers to inject forged responses into the communication channel.
Monitoring DNS cache behaviour
Understanding how DNS caching is affecting a domain requires tools that show both what authoritative nameservers are returning and what resolvers have cached.
dig with TTL observation: querying the same record twice from the same resolver with a gap between queries shows the TTL decrementing, confirming the resolver is caching correctly:
First query: TTL 3598, cached two seconds ago Second query 60 seconds later: TTL 3538, TTL has decremented by 60 seconds
A TTL that does not decrement between queries, returning the same value each time, suggests the resolver is not caching or is using a fixed TTL regardless of the record’s TTL value.
Global propagation checking tools: services like whatsmydns.net query DNS records from dozens of locations worldwide simultaneously and display the results by location. This shows the current state of resolver caches globally, which locations have the old cached value and which have the new value, providing a real-time view of propagation progress.