SocketException (11001) Occurs Sporadically in HttpClient Requests Inside RunImpersonated Context

# HttpClient DNS Resolution Failure under WindowsIdentity.RunImpersonated

### Description

When making asynchronous HTTP requests using `HttpClient.GetAsync` inside a `WindowsIdentity.RunImpersonated` context, I intermittently receive a DNS resolution error:

```
System.Net.Sockets.SocketException (11001): No such host is known
at System.Net.Http.ConnectHelper.ConnectAsync(String host, Int32 port, CancellationToken cancellationToken)
```

The issue **does not occur** when executing the same `HttpClient` call outside of the impersonation context.
It happens only occasionally — refreshing or retrying the same request usually resolves it.

This suggests that DNS resolution or network context behaves inconsistently under impersonation.

#### Steps to Reproduce

1. Acquire a valid `WindowsIdentity` (e.g., from a Windows-authenticated user).
2. Execute an HTTP GET under impersonation:

```csharp
await WindowsIdentity.RunImpersonated(identity.AccessToken, async () =>
{
using var httpClient = new HttpClient();
var response = await httpClient.GetAsync("https://example.com");
response.EnsureSuccessStatusCode();
});
```

3. Repeat the request multiple times — occasionally, the call fails with `SocketException (11001)`.

4. Running the same code **outside** `RunImpersonated` produces no errors.

---

### Configuration

- **.NET version:** .NET 8.0 (also reproduced on .NET 7.0)
- **OS:** Windows Server 2022 (also reproduced on Windows 10)
- **Architecture:** x64
- **Environment:** Occurs both locally and when hosted on Azure App Service
- **Reproducibility:** Intermittent (roughly 1 in 10–20 calls)

---

### Regression?

Not certain. The issue may have been present in previous versions, but I only recently tested under impersonation scenarios.
It does not appear when not using impersonation.

---

### Data

Representative exception stack trace:

```
System.Net.Sockets.SocketException (11001): No such host is known
at System.Net.Http.ConnectHelper.ConnectAsync(String host, Int32 port, CancellationToken cancellationToken)
at System.Net.Http.HttpConnectionPool.ConnectAsync(HttpRequestMessage request, Boolean allowHttp2, CancellationToken cancellationToken)
at System.Net.Http.HttpConnectionPool.CreateHttp11ConnectionAsync(HttpRequestMessage request, CancellationToken cancellationToken)
...
```

Observations:
- Running the same API call outside impersonation works consistently.
- The host resolves correctly via browser or `nslookup`.
- The error is transient and resolves on retry or page refresh.
- Occurs across environments (local, Azure).

---

### Analysis

It appears that under impersonation, the impersonated identity may lack consistent access to DNS client services, or network handles used for DNS resolution are not properly inherited.

Possible causes:
- DNS cache isolation or restricted access for the impersonated token.
- Different security or network context during the impersonation.
- `HttpClientHandler` or `SocketsHttpHandler` reusing stale DNS connections under impersonation.

Possible mitigations:
- Avoid performing network I/O under `RunImpersonated` and instead execute the HTTP call outside of impersonation.
- Use `IHttpClientFactory` with a `PooledConnectionLifetime` to force DNS refreshes.
- Investigate whether the impersonated identity has access to the `dnscache` service.

Would appreciate confirmation if this behavior is expected or if DNS resolution under impersonation is not fully supported in current .NET versions.