Because caches keep returning the previous answer until the TTL expires. Browsers and recursive resolvers may refresh at different times, so some users see the new record sooner than others. That staggered convergence is why DNS change management needs timing, validation, and monitoring rather than a single edit.
Why This Matters for Security Teams
DNS changes look simple, but the operational risk sits in the gap between intent and propagation. Different resolvers, browsers, and intermediary caches may continue serving the old answer until their TTLs expire, which means the same hostname can appear healthy in one place and broken in another. That matters because service migrations, failovers, and cutovers often depend on DNS behaving predictably, even though it is intentionally distributed.
For security and platform teams, this is not just an availability issue. Stale DNS can prolong exposure to deprecated infrastructure, delay incident containment, and confuse validation during change windows. The problem is amplified when teams assume a single record edit has immediate global effect. Guidance in the NIST Cybersecurity Framework 2.0 supports disciplined change control and validation, while Ultimate Guide to NHIs underscores how often identity and access problems persist because lifecycle changes are not fully propagated. In practice, many security teams encounter stale routing only after users or monitoring tools have already hit the old service.
How It Works in Practice
DNS answers are cached at multiple layers. Authoritative servers publish the new record, but recursive resolvers, local OS caches, browser caches, and even application-layer libraries may continue returning the prior response until their cached TTL expires. That is why change timing matters as much as the edit itself. The record may be updated correctly, yet some clients will still follow the old path for minutes or hours depending on the previous TTL and their cache behaviour.
Operationally, teams reduce risk by planning the cutover as a sequence rather than a single action:
- Lower TTL well ahead of the migration window so caches age out sooner.
- Verify the authoritative answer directly before assuming propagation is complete.
- Check multiple resolver paths, not just one workstation or one monitoring agent.
- Keep the old service available long enough to absorb delayed clients safely.
- Monitor both success rates and destination consistency during the transition.
This is also where identity and access hygiene matters. Stale endpoints, service account, and secrets tied to the old service can keep functioning longer than expected if decommissioning is incomplete, which is why NHI lifecycle discipline is part of safe cutover planning. The Ultimate Guide to NHIs shows how frequently organisations retain risky non-human access longer than intended, and the NIST Cybersecurity Framework 2.0 reinforces controlled change, monitoring, and recovery as part of resilient operations. These controls tend to break down when DNS, application routing, and decommissioning are managed by different teams without a shared rollback plan.
Common Variations and Edge Cases
Tighter DNS change control often increases operational overhead, requiring organisations to balance faster cutovers against the risk of lingering caches and inconsistent client behaviour. There is no universal standard for cache behaviour across every resolver, browser, or enterprise network, so current guidance suggests treating propagation as probabilistic rather than instantaneous.
Edge cases appear when:
- A resolver ignores short TTLs because of local policy or forwarding rules.
- Clients pin an IP or reuse a persistent connection instead of re-querying DNS.
- CDNs, load balancers, or service meshes introduce another layer of name resolution.
- The old service is retired before all long-lived clients have aged out.
This is why best practice is evolving toward validation from several vantage points, not just a single DNS lookup. A mature team also aligns DNS changes with secret rotation, endpoint decommissioning, and access revocation so the old service cannot remain reachable through another path. In NHI operations, the same principle applies: access should expire with the change, not linger after it. If a rollout depends on every client honouring the new TTL immediately, the plan is brittle.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.IP-1 | DNS changes need documented change management and validation. |
| OWASP Non-Human Identity Top 10 | NHI-03 | Stale DNS often delays decommissioning of related NHIs and secrets. |
| NIST AI RMF | AI RMF supports monitoring and governance of changing system behaviour. |
Treat DNS cutovers as controlled changes with prechecks, rollback, and post-change verification.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on June 23, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
