Should HttpClient support specifying IP directly, bypassing DNS-resolution?

[abjugard]

A problem that arises from HttpClients deep integration with system DNS is that the technically rather simple task of sending a HTTP request with a particular Host header value to a specific IP is made needlessly complicated, necessitating the need to build a custom SocketsHttpHandler with a custom ConnectCallback, in the process taking responsibility for protocol-selection, socket opening, and stream construction, as the only other way of forcing HttpClient to target a specific server is by mangling the URI, which breaks some SSL connections (like those behind a Cloudflare proxy for example).

If HttpClient allowed me to just supply the IP address to use directly, without automatically making DNS queries, this would all be much simpler. If I wanted to do what I'm currently doing while also supporting HTTP/3 that would also further increase the complexity of this workaround.

A workaround like this also makes it difficult to use a HttpClientFactory-pattern.

Example code for discussion (I'm sure this can be improved in a myriad ways):

public async Task<HttpResponseMessage> GetFromIp(IPAddress ip, Uri uri, CancellationToken cancellationToken)
{
    var client = new HttpClient(SocketHandlerWithIpPreference(ip));
    var request = new HttpRequestMessage(HttpMethod.Get, uri);
    return await client.SendAsync(request, cancellationToken);
}

private SocketsHttpHandler SocketHandlerWithIpPreference(IPAddress ip) => new()
{
    ConnectCallback = async (context, cancellationToken) =>
    {
        var dnsEntries = await Dns.GetHostEntryAsync(context.DnsEndPoint.Host, AddressFamily.Unspecified, cancellationToken);
        
        var addresses = dnsEntries.AddressList;
        if (addresses.Contains(ip))
        {
            addresses = [ip];
        }

        var socket = new Socket(SocketType.Stream, ProtocolType.Tcp);

        try
        {
            await socket.ConnectAsync(addresses, context.DnsEndPoint.Port, cancellationToken);
            return new NetworkStream(socket, ownsSocket: true);
        }
        catch
        {
            socket.Dispose();
            throw;
        }
    }
};

Would it make sense to add support for supplying IP address directly when making requests using HttpClient?

[Clockwork-Muse]

Note this can be a benefit on some restricted corporate/single-purpose networks, which may block DNS to reduce potential attack surface.

[MihaZupan]

If you want to send a request to a specific Uri, you can set the IP as the request uri, and manually add the host header. No need to go through ConnectCallback.

E.g. something like

HttpRequestMessage request = new(HttpMethod.Get, "https://3.230.23.0/get");
request.Headers.Host = "httpbin.org";
using HttpResponseMessage response = await client.SendAsync(request);

[abjugard]

That's actually what I did initially, but that fails with "The SSL connection could not be established" against e.g. redirects to Cloudflare-proxied domains (as in, initial target is not Cloudflare-proxied, but the 302 it returns is proxied) if using a HttpClientHandler with AllowAutoRedirect set to true. Disabling that and handling redirects myself is an alternative that works as well.

I hadn't figured out the exact cause of the failures when I made this post yesterday, I consider handling the redirects myself an acceptable workaround actually, and have now thrown out the ConnectCallback approach, so thanks for getting me to take another look at it @MihaZupan!

I still feel that this question merits discussion though, because it's still quite hacky of a workaround in my opinion.

[xljiulang]

In fact, many components directly rely on the static class Dns. DotNet does not have an abstract DnsProvider, which is designed like TimeProvider. HttpClient may be able to rely on DnsProvider instead, but this is almost impossible for Socket.

[abjugard]

But it would indeed be amazing for DNS!

[TonyValenti]

I really think this should be part of HttpRequestMessage and not exposed on HttpClient.

[abjugard]

That's a fair argument. But even if there's a settable public IPAddress Server-property on HttpRequestMessage it'll have to have an interaction with HttpClient at some layer so that HttpClient respects that the server to send the message to has been decided already by the HttpRequestMessage.