Adding support for fully managed name resolution APIs or as app-level toggle

[mjsabby]

DNS resolution is something that is different between different distros and platforms that NET supports.

While most Linux distributions use /etc/resolv.conf, not all do (Android). And even when they do use /etc/resolv.conf they seem to have different capabilities. For example, this Kubernetes issue talks about a workaround that can be done in in glibc-based distributions but not on Alpine which is musl-libc based because of a missing feature in musl-libc.

As I alluded to earlier, Android is its own thing, and does things differently. It queries the data over UDS (/dev/socket/dnsproxyd). This is actually a good thing for the user, so whenever we port to Android it makes sense to have the default be OS provided capability.

Having a built-in capability (that is perhaps not the default) to have portability across platforms and distros will be very valuable.

In fact, the Go language ecosystem has already done this and were able to effectively mitigate the aforementioned Kubernetes bug by making a change in their resolver code. golang/go@dbc1703

Furthermore, with the recent ConnectCallback feature in SocketsHttpHandler, a new API to do DNS resolutions (or a config switch) will work nicely.

I haven't yet made up my mind on whether this as an app-level config/setting is more valuable than just a new API or capability. It could be argued that the app-level config/setting is more valuable because it will just work with existing code. Something to discuss ...

[Dotnet-GitSync-Bot]

I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label.

[ghost]

Tagging subscribers to this area: @dotnet/ncl
See info in area-owners.md if you want to be subscribed.

[scalablecory]

It's worth exploring, but needs a good bit of prototyping.

Keep in mind that name resolution is more than just DNS -- the Dns class (or rather, getaddrinfo that it calls) can query over a variety of different locations.

[wfurt]

It may not be easy to cover al the platform differences. This was discussed before as some of the API do not offer all the details - like record TTL.

[geoffkizer]

This seems like a good candidate for developing something standalone and then considering adding it in-box at some point.