You revoke a vendor's access by removing their IP address from an allowlist rule that resolves a hostname to permitted addresses. The change takes effect on your firewall immediately. It does not take effect on every client that already resolved that hostname and cached the answer, some of which will keep talking to the old address for as long as their cached record's time-to-live says they may, regardless of what your allowlist now says.
DNS caching exists to make the internet fast, and it does that by having every resolver, operating system, and application in the chain independently decide how long an answer stays valid, based on a number the original DNS record's owner chose, which is not always the number that matches how quickly you actually need a change to take effect.
This post is about the gap between when a DNS-dependent decision changes and when everything that relies on it actually finds out.
Where DNS quietly becomes an access control
Allowlisting by hostname rather than by address, where a firewall rule, a network policy, or an application-level check resolves a hostname at some point and then treats the resulting address as valid for a duration determined by caching behaviour that is not under your control, layered underneath a decision that is meant to be under your control.
Service discovery that resolves a dependency's address once and holds it, particularly in long-running processes or connection pools that establish a connection based on a DNS lookup performed at startup or at pool creation, and then continue using that connection, or reconnecting to the same resolved address, long after the DNS record itself has changed to point somewhere else, whether that change was a deliberate migration or a response to a compromise.
Certificate and domain validation checks that cache a DNS-based verification result, where a process that verified domain ownership or resolved a hostname for a security decision at one point in time treats that resolution as durable, rather than re-checking it, for a duration that may exceed how quickly the underlying DNS state can actually change, including changes made specifically because something needed to be revoked quickly.
The direction this cuts
Most of the attention DNS security gets is about resolving to something malicious that should not be trusted. The direction this post is about is the reverse and less discussed one: a decision that depends on DNS can remain stale in the safe direction, continuing to trust something that has since been deliberately revoked, for exactly as long as a cache entry says it may, which is a duration nobody making the revocation decision necessarily controls or even knows about.
If your process for revoking access to a compromised vendor, cutting off a decommissioned service, or responding to an incident involves changing what a hostname resolves to, or what a hostname is permitted to resolve to, the actual effectiveness of that revocation is bounded by every cache, at every layer, between the DNS record and whatever ultimately makes the trust decision, not by the moment you made the change.
Layers where caching happens, each with its own duration
The resolving name server, respecting the TTL declared on the record itself, which was set by whoever controls that DNS zone and may be a value chosen for general performance rather than one that anticipated needing rapid revocation.
Operating system and application-level DNS caches, which frequently apply their own minimum caching duration independent of, and sometimes longer than, the TTL the record itself declared, because a very short TTL is sometimes treated as unreliable or as a signal to apply a floor rather than to genuinely honour a value that short.
Connection pools and persistent connections, which resolved a hostname once to establish a connection and then have no reason to re-resolve it as long as the existing connection remains open and functional, meaning the actual staleness here is bounded not by any DNS TTL at all but by how long your application happens to keep a connection alive.
Client-side and browser caches, for anything involving a user's own device rather than server-to-server communication, adding another layer with its own behaviour that is entirely outside anything you control from the server side.
What to actually do
Know, specifically, the actual propagation time of a DNS-dependent revocation, measured rather than assumed, by testing what a realistic client actually experiences after you make the change, rather than trusting the TTL value on the record as though it were a guarantee every layer in the chain will honour precisely.
For anything where revocation speed genuinely matters, do not rely on DNS as the enforcement mechanism at all. Use address-based rules, a proxy or gateway that enforces the current policy on every request rather than caching a resolved decision, or an active connection-termination mechanism that closes existing connections rather than merely preventing new ones from being established with newly resolved addresses.
Set genuinely short TTLs in advance on any record that might need to support rapid revocation later, because changing a TTL itself only takes effect after the previous, longer TTL has expired; a record with a one-day TTL that you shorten to five minutes today will still be cached by anyone who fetched it recently for up to the remainder of that original day, which means the time to prepare for fast revocation is before you need it, not at the moment you do.
Separately track and terminate existing connections during an incident, rather than assuming that changing what new connections would resolve to is sufficient. A connection established before the change is unaffected by the change, regardless of how quickly DNS itself propagates, because it never needs to re-resolve anything to keep functioning.
Check yours
For any process where DNS resolution feeds into an access or trust decision, ask specifically: if the DNS record changed right now, how long would it take for every layer between that record and the actual enforcement point to reflect the change, tested by actually changing a record and measuring, rather than reading a TTL value and assuming it describes the true end-to-end latency.
The concession
Building enforcement that does not depend on DNS caching behaviour at all, for every trust decision your systems make, is more infrastructure than most situations warrant, and DNS-based access control is a reasonable, widely used approach for the majority of cases where a revocation being effective within minutes to hours, rather than instantly, is genuinely acceptable.
The distinction that matters is which decisions actually need faster revocation than DNS caching can reliably provide. For most routine access changes, DNS's normal propagation characteristics are fine. For revoking access during an active incident, where the entire point is stopping something as quickly as possible, relying on DNS propagation alone is the wrong tool regardless of how short you set the TTL, because the existing, already-cached and already-connected state is exactly what an incident response needs to address directly.
The implication
A revocation is not effective the moment you make it. It is effective the moment every layer that depends on the thing you revoked actually finds out, and DNS caching means that moment is determined by TTL values, connection lifetimes, and resolver behaviour that were configured for performance, not for how quickly you would eventually need to take something away.
If your incident response plan involves changing DNS to cut off access to something, test what that actually achieves in the first few minutes, rather than assuming the change is effective the instant you make it. The gap between those two things is exactly where a response that looks complete on paper leaves a real window open in practice.
