DNS cache is the likely cause when one client or resolver keeps an older answer until its time to live expires while a fresh query elsewhere returns the new policy result. Record the change time, compare answers and remaining TTLs through each layer, and confirm behavior converges after expiry without changing the rule again.
The strongest diagnosis is a timeline, not the fact that flushing appeared to help. Capture the old answer, the new expected answer, where each was observed, and how the remaining lifetime changed. If the result follows predictable expiry, cache is plausible. If it follows a network, resolver, profile, or browser change, investigate that boundary instead.
Look for a stale-answer signature
DNS caching is normal. RFC 1034 describes caches as a way to reuse earlier answers and associates cached data with time-to-live values.1 A classic stale-answer pattern has four parts: policy or authoritative data changed at a known time, one path returns the older answer, another fresh path returns the newer answer, and the older result disappears around its expected expiry.
- The affected client repeatedly receives the same old answer with a decreasing remaining TTL.
- A direct comparison through another resolver or uncached path returns the expected new answer.
- The policy resolver records the new action for fresh requests but receives no matching fresh request from the affected client.
- Behavior converges after normal expiry without another policy edit.
Cache is less likely when the old result persists with a reset or implausibly stable TTL, changes immediately with VPN or Wi-Fi state, affects only one browser despite identical DNS answers, or appears under a different resource policy. Those patterns point toward another resolver, a forwarding layer, application state, connection reuse, or a policy assignment difference.
Draw the cache chain before flushing
A lookup may pass through several places that reuse answers: application or browser, operating-system stub resolver, local forwarder or router, recursive resolver, and upstream authoritative DNS. Draw the path for the affected device and identify where you can observe an answer and remaining TTL. The first layer returning the old data is more useful than a generic claim that “DNS is cached.”
| Layer | Evidence to capture | Misleading shortcut |
|---|---|---|
| Application or browser | Fresh lookup versus reused connection | Reloading the same tab |
| Operating system | Returned records and remaining TTL | Flushing before recording |
| Router or forwarder | Upstream used and answer timestamp | Assuming Wi-Fi defines resolver |
| Recursive resolver | Cache status, answer, policy event | Reading configuration only |
| Authoritative source | Current record set and TTL | Assuming it controls prior caches |
Do not confuse DNS cache with web cache. A browser can display stored page assets or continue an established connection after DNS has changed. DNS filtering can decide domain lookups; it cannot remove page content already stored, inspect full URLs, read searches, see chats or voice audio, or produce full browser history. Test those layers separately.
Run a timestamped cache comparison
- Record the policy or DNS change time, timezone, affected hostname, old answer, and expected new outcome.
- From the affected device, capture the resolver path, returned record or error, remaining TTL, and exact test time.
- Query through a known comparison resolver or clean path without changing the affected path.
- Check whether the intended policy resolver received a fresh request and which action matched.
- Wait through the observed remaining lifetime, then repeat the same tests without another rule change.
- Only after preserving evidence, clear one identified cache and verify whether that layer controlled the result.
Use the exact hostname, not a neighboring name or brand. Positive and negative answers can have different caching behavior, and a redirect can cause the browser to resolve another hostname. RFC 2308 specifies negative caching for DNS, including how negative responses obtain a cache lifetime.2 Record whether the old result is an address, a name error, a refusal, or a policy redirect.
Keep other variables fixed. Use the same device, network, resolver, IP family, and resource profile during the expiry test. Switching from office Wi-Fi to cellular data may produce a fresh answer, but it proves only that another path differs. It does not locate the cache on the original path.
Distinguish expiry from stale serving
Ordinary cache reuse before expiry is different from intentionally serving stale data after expiry. RFC 8767 allows recursive resolvers to use expired data in constrained situations, especially when refreshing from authoritative servers fails, and describes limits intended to reduce harm.3 If a supposedly expired answer persists, check upstream reachability, resolver stale-answer settings, response TTL, and whether the resolver labels the response.
Also consider multiple recursive nodes. Two requests to one service name may reach different cache instances, one warm and one fresh. Alternating old and new answers can look like a client problem when the difference sits inside a resolver fleet or forwarding chain. Preserve several timestamped samples and their resolver identity before making another policy edit.
If the intended resolver consistently returns the new blocked result while the application still loads, stop treating DNS cache as the cause. Check open connections, alternate hostnames, application-level proxying, stored content, or a different in-app resolver. The DNS evidence has already narrowed the problem above or around the resolver.
Preserve the diagnosis and prevent repeats
Once the paths converge, document the cache layer, old and new answers, observed TTL, change time, convergence time, and the evidence that ruled out policy drift. Avoid shortening every TTL or repeatedly flushing clients as a permanent fix. Lower TTLs can increase query load, and indiscriminate flushing masks ownership and timing problems.
For future DNS policy changes, note the previous answer and expected propagation window before editing. Use a test resource, verify a fresh query and matched action, then monitor aggregate allow and block outcomes. Open detailed retained history only for the named resource and narrow interval needed to explain an exception, and close that access when the diagnosis is complete.
DNS cache diagnosis questions
Does a low TTL guarantee an immediate DNS policy change?
No. TTL controls DNS cache reuse, but applications may keep addresses, browsers may reuse connections, and intermediate components may behave differently. A low remaining TTL predicts when a DNS answer should be reconsidered; it does not force an already loaded page or connection to stop.
Should I flush every cache during diagnosis?
Not first. Flushing can restore expected behavior while destroying the evidence needed to identify which layer held the stale answer. Capture timestamps, answers, TTLs, resolver path, and policy events first, then clear one known cache only when a controlled confirmation is useful.
Can a resolver intentionally serve stale DNS data?
Yes, in defined circumstances. RFC 8767 describes serving stale data to improve resilience when fresh resolution fails, with safeguards and limits. Check resolver behavior and upstream availability before concluding that any answer observed after ordinary TTL expiry proves a broken cache.
Check one Veilty policy transition
In Veilty, inspect one resource and one policy-change window inside its Space or Tenant. Reusable baseline and enforced policies belong to that scope; a resource may override baseline policy when permitted but cannot weaken enforced policy. Account invitations grant membership only, while scoped Space or Tenant roles control access. Retained activity history is scoped, end-to-end encrypted with user-held keys, and visible only to permitted roles; the resolver must process live queries. Compare timestamps and TTLs first, then change or clear only the layer the evidence identifies.