A DNS change does not replace an open connection
An outbound HTTP client may continue using an existing connection after a service's DNS answer changes. That can be correct connection reuse rather than a broken DNS server. Conversely, constructing and disposing clients with their own handlers for every request can create unnecessary connection churn and port pressure.
The .NET HttpClient guidance explains that DNS is resolved when a connection is created and describes pooled connection lifetime as a way to cause replacement and fresh resolution. The appropriate lifetime depends on the environment. Copying the documentation's illustrative duration does not establish the right policy for every service.
Setup: inventory clients and handlers
Identify the runtime version, client registration, handler ownership, destination hostnames and proxy route. Distinguish long-lived clients with a deliberate handler policy from clients created through IHttpClientFactory. A factory can manage handler reuse, so disposing a client does not always mean its underlying pool is discarded.
Record the expected DNS-change or failover behavior with the dependency owner. Include connection duration, request duration and infrastructure routing. Use a controlled test destination rather than changing production DNS repeatedly to experiment. Keep tokens and private request payloads out of diagnostic traces.
Illustrative incident: only old workers reach the retired address
An illustrative integration switches a dependency to a new address. Newly started application workers use it, while older workers continue on established connections. The team first flushes operating-system DNS caches, but the relevant connection has not been replaced. This is a teaching scenario, not a customer migration result.
Correlate connection creation time, remote endpoint and DNS observations from the application environment. Compare an existing connection with a newly created one. A successful command-line lookup says what a fresh lookup returns; it does not describe an already open pooled connection.
Troubleshooting: identify churn or staleness
| Symptom | Evidence | Investigation |
|---|---|---|
| Old workers keep one destination | Connection age and handler policy | Is the existing pool behaving as configured? |
| Many short connections accumulate | Client and handler creation rate | Is per-request construction causing churn? |
| New connections still use the old address | Resolver, proxy and upstream routing | Is the stale answer outside the client pool? |
| Requests fail during transition | Dependency readiness and request duration | Was overlap between destinations sufficient? |
Do not assume a DNS TTL directly controls every existing HTTP connection. Also avoid disposing shared clients on every error; that can amplify connection pressure while the dependency is already unhealthy.
Corrective action and dependency coordination
Choose one supported client-lifetime model and configure connection replacement according to the dependency's change behavior. Retain reuse rather than turning every request into a fresh handshake. Review timeout and retry policies separately: a sensible pool lifetime does not make a repeated write safe.
Coordinate failover with the dependency owner so old connections can drain while new connections reach a ready destination. If a proxy controls upstream connections, include its policy in the plan. Keep a rollback route and distinguish connection-level errors from application responses returned by a healthy connection.
Verification, dependency SLO and SOP
Run a controlled address transition with active and idle clients. Confirm new connections eventually resolve the intended destination, active requests behave according to policy and connection counts stay bounded. Test dependency failure without multiplying non-idempotent business requests.
An internal SLO can measure useful verified dependency calls within the supported transition envelope. Pool metrics and DNS lookups support diagnosis but are not a commercial SLA. The SOP should identify client ownership, connection-lifetime rationale, dependency cutover contacts, safe retry categories and escalation evidence. Avoid claiming zero-downtime failover without representative tests across the full delivery path.
See custom application development and network architecture.
Technical reference
Microsoft HttpClient guidelines, reviewed 19 October 2026. Follow documentation matching the installed product version.