-
Notifications
You must be signed in to change notification settings - Fork 4.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
System.Net.Dns does not always resolve "" and the system's own hostname on Unix #36849
Comments
Tagging subscribers to this area: @dotnet/ncl |
This seems like very corner-case thing, to the point where if someone configured their system in such a way I might assume it was intentional. We have |
We actually already do in SystemNative_GetHostEntryForName() runtime/src/libraries/Native/Unix/System.Native/pal_networking.c Lines 318 to 325 in 46b430a
And it actually may work that way on some Linuxes with systems. https://www.freedesktop.org/software/systemd/man/systemd-resolved.service.html The problem is that if getaddrinfo() fails, we never get to that part of the code. |
This was never the case with the issues we encountered our CI, and it's more likely that we get user complaints for not being able to resolve |
An open question: |
I would suggest to return hostName it self to prevent issues with null. |
So does .NET have its own resolution for dns to ip or does it use the glibc/musl API? We should actually follow what the Go community did and parse resolv.conf and not use glibc/musl at all. Reason: kubernetes/kubernetes#62628 The K8s world loves to add proxies and sidecars for many things, and they use iptables a lot. Combined with iptables and IPv6 being enabled, glibc and musl do parallel DNS requests which expose a race condition in the netfilter kernel module. This causes timeouts which are 5-seconds by default. In glibc you can configure that the request should be done in serial order, but apparently that is not supported in musl. So, if this issue is we should implement our own resolv.conf parser (I recall seeing some code in the repo for that?) and use that then it would solve this other problem too and make .NET resilient to this dns timeout issue. |
A follow-up on the discussion in #36072.
Problem
dotnet/corefx#41764 implemented a consistent solution to match Windows behavior when
Dns.GetHostEntry(hostName)
or related methods are invoked with""
or the systems hostname on Unix, but it only works on Unix systems which are configured to successfully resolve their own hostname. Although most of the time this is true, there are some exceptions, eg. our 10.14 CI macs don't do it. I'm not sure about the root cause on mac, but it's relatively easy to "misconfigure" Ubuntu 18.04, see last paragraph. On these systems the shell commandhostname | nslookup
(and the matching libc call chain) fails, which makes our currentSystem.Net.Dns
implementation throw. This does not conform our documentation:Suggestion
In
pal_networking.c
we are already handlinghostname
as a special case:runtime/src/libraries/Native/Unix/System.Native/pal_networking.c
Lines 318 to 326 in 3fda6ef
We should return the same result, even if the underlying OS name resolution (
getaddrinfo
) fails.Despite it's name, the
System.Net.Dns
class is a universal name resolver that goes behind the DNS resolution rules, implementing a .NET-specific logic for name resolution. It's better to aim for cross-platform consistency, instead of matching the behavior ofnslookup
/getaddrinfo
(which is not being matched anyways since dotnet/corefx#41764)Note: on Windows and "properly configured" Unixes,
Dns.GetHostEntry("")
andDns.GetHostEntry("my-hostname")
are essentially the same, we should not change this behavior IMO.CC @wfurt @scalablecory @davidsh
Reproduction on Ubuntu 18.04
In
/etc/nsswitch.conf
:In
/etc/resolv.conf
:In
/etc/hosts
:- 127.0.1.1 <hostname>
The text was updated successfully, but these errors were encountered: