When DNS Changes, Why Can Requests Still Reach the Old Endpoint?

Start with the answer DNS actually supplies

For address-based endpoint selection, DNS supplies record information associated with a name. A resolver obtains that information and can retain a cached answer for later lookups. RFC 1034 describes resource records and the resolver's host-name-to-address function. The DNS response supplies information for reaching a service; the application connection is a separate object.

Keep three events distinct. An authoritative change makes a different record answer available from the authoritative service. A subsequent resolver lookup may still encounter cached information. Establishing a connection using the returned address is another event, performed by the client.

A new application request does not necessarily require that third event. RFC 9110's June 2022 HTTP semantics allow an origin connection to be established or reused, and one connection can carry multiple request/response exchanges. Reusing a suitable connection need not involve a fresh DNS lookup for each request.

References: [R0][H1]

At 150 seconds, cached A can still be a valid answer

Consider an original, wholly hypothetical case with one endpoint name, one resolver and one client. Labels A and B stand for two different endpoint addresses; A is a label here, not a reference to the DNS record type.

At 0 seconds, the resolver caches answer A with a 300-second TTL. Stipulate that it retains this entry without an intervening refresh or eviction. At 100 seconds, the authoritative answer changes to B.

At 150 seconds, the client asks this resolver for the address. The cached entry is 150 seconds old and has 300 − 150 = 150 seconds of its ordinary cache lifetime remaining. The resolver can return A despite the authoritative change. Stipulate that the client then establishes connection C-A to A. Endpoint A remains healthy and C-A remains usable through the later events.

Returning A here requires no refresh failure or serve-stale exception: the stipulated entry is still unexpired. AWS's Route 53 troubleshooting guidance identifies continued use of a cached record as a reason traffic can reach the previous resource.

References: [DN2]

At 350 seconds, a fresh answer can coexist with a request to A

At 310 seconds, explicitly stipulate another lookup through the same resolver and a successful authoritative refresh to B. This is an assumed event in the example. It does not mean a resolver automatically performs a lookup at the instant a TTL expires.

At 350 seconds, the client deliberately reuses the still-open, healthy C-A connection for another request. This request need not consult DNS or establish a connection to B. The refreshed answer is B, while the selected connection still reaches A. There is no contradiction: the observations describe different objects.

AWS's ARC routing-control guidance, checked October 20, 2026, distinguishes a DNS update from the behavior of clients with pre-existing open connections, which can continue making requests until they reconnect. The record change does not migrate C-A to B.

All times, address labels, connection choices and health conditions in this case are illustrative assumptions. They describe neither an observed test nor a failure simulation, guaranteed sequence or recovery time objective.

References: [DN1][H1]

Expiry is not a universal purge or a connection deadline

TTL describes record-cache freshness. RFC 8767, published in March 2020, revises its definition to require consultation of the information source after the specified duration, while allowing expired data to be used when it cannot be authoritatively refreshed. This exceptional serve-stale permission means expiry does not guarantee that every resolver immediately discards the previous answer.

That exception does not explain the request at 350 seconds: the example expressly stipulates successful refresh to B. Its remaining connection to A needs a separate explanation.

Changing the authoritative TTL later also cannot retroactively shorten the earlier cached entry. Route 53's guidance makes that old-TTL qualification explicit. In this case, a TTL reduction after A was cached would not rewrite the 300-second lifetime already received at 0 seconds. Neither cache expiry nor a later TTL setting closes C-A.

References: [DN3][DN2][DN1]

Compare the offer with the client population it actually covers

The purchasing consequence appears in the same example. A report showing B at 310 seconds supports a freshness observation for that lookup. It does not establish where the client's next request goes. Evidence that follows the request at 350 seconds to C-A explains why a successful DNS refresh and continued use of A can coexist.

A DNS-based routing offer should therefore be read against the behavior of the intended persistent clients. Evidence gathered only from newly established connections leaves reuse of existing connections unresolved. The useful explanation connects the authoritative change, the resolver answer actually obtained and the connection selected for the relevant request, then follows that request to the application outcome being claimed.

Faster freshness alone supplies no evidence that unfinished inference work at A was transferred or replayed at B, or that the application recovered. A recovery-time claim needs evidence of its own outcome and conditions beyond a DNS TTL value.

The related HTTP/2 article answers a different question: which streams count toward a connection's advertised limit. The cross-Region inference article separates provider model routing from the customer's application and dependencies. Use those guides for those decisions after resolving the lookup-versus-connection distinction here.

References: [DN1][H1]

Bring any resulting physical connections to a cabling inquiry

If the endpoint plan also requires installed fiber or copper connections, Leviathan's Structured Cabling & Fiber Installation service can discuss agreed pathways, assemblies, endpoint labels, physical checks and connection records. Use the related service and project inquiry with a nonconfidential outline of the equipment endpoints, routes, materials responsibilities and required handoff.

That inquiry concerns the physical installation package. DNS operation, client connection handling and inference-software recovery remain with the appointed application and platform teams.

References: [L1]