SocketsHttpHandler.DnsRefreshCacheTime: Zero value semantics and cache invalidation

Answer to the Specific Questions

1. Does setting DnsRefreshCacheTime to TimeSpan.Zero cause the handler to immediately invalidate all cached DNS entries, or does it merely disable periodic refreshes?

Setting DnsRefreshCacheTime to TimeSpan.Zero disables the internal periodic refresh timer. It does not clear the DNS cache immediately; cached entries remain in the handler’s shared cache until the handler instance is disposed or the process exits.

2. If the cache is not immediately invalidated, how long do stale entries remain in the cache after the DNS record changes?

Stale entries persist for the lifetime of the SocketsHttpHandler (or HttpClient that reuses it). With a long‑lived client, the stale IP can be used indefinitely until the handler is disposed.

3. Are there platform‑specific differences in this behavior between Windows, Linux, and macOS?

The behavior is consistent across all supported platforms. The internal cache implementation is the same; only the underlying OS resolver may have its own separate caching layer, but that is independent of the SocketsHttpHandler cache.

Why This Happens

• The default cache lifetime is five minutes, governed by DnsRefreshCacheTime.
• A zero value turns off the background timer that would normally trigger a refresh after that interval.
• Because the timer is disabled, the handler never initiates a new lookup for a cached host unless the handler is recreated.
• Re‑creating the handler (or disposing the HttpClient that owns it) forces a fresh DNS lookup, effectively bypassing the cache.

Practical Verification Steps

1. Create a SocketsHttpHandler and set DnsRefreshCacheTime = TimeSpan.Zero.
2. Use the handler with an HttpClient to call a host that changes its IP (e.g., a DNS‑round‑robin service).
3. Record the returned IP for several consecutive requests while keeping the handler alive.
4. Dispose the handler (or the HttpClient) and repeat the request sequence; you should see the updated IP each time.
5. Run the same test on Windows, Linux, and macOS to confirm consistent behavior.

When to Re‑create the Client

If your application relies on DNS changes (e.g., service discovery or load balancers that rotate IPs), consider:

• Re‑creating the HttpClient or SocketsHttpHandler on a regular schedule.
• Using HttpClientFactory with a short lifetime for the handler.
• Setting DnsRefreshCacheTime to a non‑zero value if you want periodic refreshes without full recreation.

Diagnostic Detail Needed

To tailor the recommendation further, could you confirm whether you are reusing a single HttpClient instance across requests, or creating a new one for each call?