A DNS lookup that returns instantly when your connection is working can return the exact same answer it cached 48 hours ago — and understanding which answer is "fresh" vs "cached" matters every time you make a change that you expect to take effect immediately
The previous articles on this site covered DNS record types, DNS security, DNS propagation and TTLs, and DNS over HTTPS. This article addresses DNS caching architecture — specifically the chain of caches between a DNS query and the authoritative answer, why the same domain can resolve differently from different locations at the same time, and how to determine whether a returned answer is fresh or stale.
The DNS resolution chain: four potential actors
When a browser needs to resolve example.com, the query may pass through up to four separate caches:
1. The browser's own DNS cache: modern browsers cache DNS results independently of the operating system. Chrome, Firefox, and Edge maintain their own DNS caches with their own TTL tracking. You can inspect and flush browser DNS caches (chrome://net-internals/#dns in Chrome, about:networking#dns in Firefox).
2. The operating system's DNS cache: the OS-level resolver (Windows DNS Client service, macOS mDNSResponder, Linux nscd or systemd-resolved) caches responses for the TTL specified in each record. When the browser asks "resolve example.com," it typically first checks the browser cache, then asks the OS resolver.
3. The recursive resolver (your ISP or configured DNS provider): this is the server the OS queries — Google's 8.8.8.8, Cloudflare's 1.1.1.1, or your ISP's resolver. It caches responses from the authoritative nameservers and serves them to all clients using that resolver until the TTL expires. Importantly, a popular recursive resolver may have cached your domain's old IP address from queries made by other users — not just your own queries.
4. The authoritative nameserver: the actual source of truth — the nameserver specified in your domain's NS records. This doesn't cache; it holds the authoritative records. But it may not be queried at all if every upstream cache has a valid, non-expired answer.
When you change a DNS record, the new value propagates as each cache's TTL expires and the record is re-fetched. This is why propagation is a time range, not an instant event — different resolvers cached your old value at different times and expire them at different times.
The TTL that actually controls propagation speed
TTL (Time to Live) is set on each DNS record by the zone owner — it instructs recursive resolvers how long to cache the response before re-querying.
The TTL that matters for propagation is the TTL your old record had — not the TTL your new record has. If your A record had a TTL of 86400 (24 hours), and you update it, resolvers that cached it 1 second before your change will hold the old value for the next 23 hours and 59 minutes. The new TTL (whatever you've now set on the new record) doesn't take effect for any resolver until that resolver discards the old cached entry and fetches fresh data.
Pre-change TTL reduction strategy: lower your TTL 24-48 hours before a planned DNS change. If your TTL is currently 86400 (24 hours), reducing it to 300 (5 minutes) ensures that by the time you make the actual change, the maximum propagation time is only 5 minutes rather than 24 hours.
Raising TTL after a change: once you've confirmed the new record is propagated and working, raise the TTL back to a higher value. High TTLs reduce DNS query load and improve resolution speed for your visitors.
How to determine if you're seeing a cached or fresh answer
The dig command (and equivalent tools) shows the TTL of the record as returned by the queried resolver. A returned TTL lower than the record's configured TTL means the resolver cached it some time ago — the remaining TTL is how long until this resolver's cache expires.
Example:
dig example.com @8.8.8.8
Returns: example.com 1847 IN A 93.184.216.34
The 1847 is the remaining TTL in seconds — meaning Google's 8.8.8.8 cached this record 24000 − 1847 = 22,153 seconds ago (about 6 hours ago, if the configured TTL is 86400).
If you query the authoritative nameserver directly (bypassing any recursive caching):
dig example.com @authoritative-ns.example.com +norec
This returns the full, current TTL as configured — not a remaining cache TTL.
Negative caching: how "doesn't exist" is also cached
DNS also caches negative responses — "this domain or record doesn't exist" (NXDOMAIN). Negative caching TTL is controlled by the SOA (Start of Authority) record's minimum TTL field and a separate negative TTL field.
Practical implication: if you query for a record that doesn't yet exist (perhaps because you're checking propagation before it completes), the resolver may cache the NXDOMAIN response — and continue returning NXDOMAIN even after the record has been created, until the negative cache TTL expires.
This is why querying "does the new record exist yet?" from your ISP's resolver can make propagation appear slower than it actually is — the NXDOMAIN response was cached before the record existed, and now the cache holds a stale "doesn't exist" answer even though the record has been published.
Solution: query the authoritative nameserver directly (bypassing recursive caches entirely) to see the current published state.
Anycast and geographic DNS: why different locations see different answers
Many DNS providers use Anycast routing — the same IP address is announced from multiple geographic locations, and your query routes to the nearest one. This means:
- A query from London goes to the London DNS POP
- The same query from New York goes to a New York DNS POP
- These are different server instances, with different cached state
Even for recursive resolvers (Google's 8.8.8.8, Cloudflare's 1.1.1.1), queries route to different physical servers in different locations. The "same" resolver may have cached your old and new DNS values differently in different geographic POPs.
This explains why "DNS has propagated" is not a binary state. At any given moment during propagation, some geographic locations have the new record and others still have the old one — depending on when each location last fetched from the authoritative source.
How to use the DNS Lookup on sadiqbd.com
- For post-change propagation checking: use the tool to check whether the new record value is visible yet — but be aware this reflects the resolver the tool queries, not necessarily what your users or your ISP's resolver sees
- For understanding "why is the old value still showing": the returned TTL tells you how long ago the queried resolver cached the response — if the TTL countdown is still hours away, the resolver won't re-fetch until then
- For confirming the authoritative source: if the tool allows specifying a resolver, query your domain's own authoritative nameserver to see the current published values without caching interference
Frequently Asked Questions
Does flushing my local DNS cache immediately show me the new record? Flushing your OS or browser DNS cache removes your local cached entry — on your next query, your OS will ask your configured recursive resolver (your ISP or Google/Cloudflare) for a fresh answer. But "fresh" here means fresh from the recursive resolver's cache — if that resolver still has the old value cached, you'll receive the old value again, and it will be re-cached locally. To truly bypass all caching, you'd need to query the authoritative nameserver directly, which most browsers and OS resolvers don't do by default — they always go through a recursive resolver first.
Is the DNS Lookup free? Yes — completely free, no sign-up required.
Try the DNS Lookup free at sadiqbd.com — query any DNS record type for any domain, with TTL and resolver details.
