Traditional DNS relies on polling and cache expiry, so different clients can hold different answers for different lengths of time. That creates inconsistency when records change quickly, especially for service discovery or split-horizon environments. Middleboxes that ignore TTLs make the problem worse, because operators lose confidence in when a name truly reflects the current state.
Why DNS caching makes service discovery feel inconsistent
Traditional DNS was built for names that change relatively slowly, not for rapidly shifting internal service endpoints. When a client resolves a name, it may keep that answer in its own cache, while recursive resolvers and even intermediate devices may keep separate cached copies for different periods. That means two callers can ask the same name and still act on different service locations.
The core issue is that TTLs define a maximum cache lifetime, not a synchronized refresh point. A record can expire on one host and remain valid on another, so the same service name can resolve differently across clients, zones, and network paths. In split-horizon or autoscaling environments, that lag turns DNS into a probabilistic distribution mechanism rather than a consistent source of truth.
For internal service discovery, that behaviour creates a practical mismatch between logical service identity and physical endpoint state. A new instance may be available, but some clients continue using an older address; an old instance may be withdrawn, but others still attempt to reach it. The result is intermittent reachability, uneven rollout behaviour, and hard-to-reproduce failures that depend on where the query came from and when the cache last refreshed.
What changes when caches, resolvers, and middleboxes ignore the same timing
Consistency problems are amplified by the fact that DNS is not just one cache. Operating systems, application runtimes, recursive resolvers, forwarders, load balancers, and inspection devices can each hold answers independently. If even one layer ignores TTLs, extends them, or applies its own caching policy, the effective freshness of the name becomes unpredictable and the service discovery path loses determinism.
That is why environments that rely on quick cutovers, short-lived instances, or frequently changing internal records often see stale routing, partial migrations, and uneven failover. A record change is not observed as a single event, but as a staggered propagation wave. Some clients move immediately, some lag, and some may never re-query until their local state is cleared or the process restarts.
This is especially visible when teams expect DNS to behave like a control plane for rapidly changing services. It can work, but only when the operational model accepts cache delay, query locality, and resolver behaviour as part of the design. When it does not, operators misread cached answers as live state and end up debugging the symptom instead of the distribution mechanism.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AC-1 — Identity Management, Authentication and Access Control | DNS-based service discovery affects which service endpoint a client can reach. |
| PR.PT-4 — Communications and Control Networks | Internal discovery depends on predictable network communications and path behaviour. | |
| Recommendation — Limit resolver and service access paths to reduce stale or misrouted connections. Tune network control paths so service lookup changes propagate predictably. | ||
| CIS Controls v8 | 12.4 — Deploy and Maintain a Secure Network Infrastructure | Service discovery inconsistency is influenced by resolver, forwarder, and middlebox behaviour. |
| 8.1 — Establish and Maintain an Inventory of Enterprise Assets | Discovery correctness depends on knowing which services and endpoints are active. | |
| Recommendation — Validate DNS infrastructure components so they do not override intended TTL behaviour. Maintain an accurate service inventory to detect stale DNS mappings quickly. | ||
Practitioner Guidance
What to verify: Measure resolution behaviour at the client, resolver, and application layers, not just at authoritative DNS. If different layers disagree on freshness, the problem is not the record alone but the caching chain that sits between discovery and use.
- Track how long stale answers persist after a planned change.
- Check whether applications reuse resolver results beyond the nominal TTL.
- Confirm whether any middleboxes or forwarders rewrite, pin, or ignore expiry.
Decision rule: If the service depends on immediate state convergence, treat DNS as a loose locator, not a real-time registry. For faster-moving environments, reduce reliance on DNS-only discovery and use a mechanism that makes freshness and reachability explicit.
What practitioners underestimate: Low TTLs do not guarantee consistency if downstream caches do not honour them or if applications suppress re-resolution. The observable outcome is often not failure, but split behaviour, some clients succeed, others continue to follow stale paths, which is harder to detect and more dangerous operationally.
Practitioner takeaway: DNS is only as consistent as the slowest cache in the path, so service discovery design has to account for propagation delay, not assume name changes become universal at once.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 23, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
