Repository navigation
System.Net.Dns does not always resolve "" and the system's own hostname on Unix #36849
Description
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 command hostname | nslookup (and the matching libc call chain) fails, which makes our current System.Net.Dns implementation throw. This does not conform our documentation:
If an empty string is passed as the hostNameOrAddress argument, then this method returns the IPv4 and IPv6 addresses of the local host.
Suggestion
In pal_networking.c we are already handling hostname 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 of nslookup / getaddrinfo (which is not being matched anyways since dotnet/corefx#41764)
Note: on Windows and "properly configured" Unixes, Dns.GetHostEntry("") and Dns.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:
- hosts: files mdns4_minimal [NOTFOUND=return] dns myhostname
+ hosts: files dnsIn /etc/resolv.conf:
- nameserver 127.0.0.53
+ nameserver 8.8.8.8In /etc/hosts:
- 127.0.1.1 <hostname>
Activity
scalablecory commentedon May 22, 2020
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
Dns.GetHostEntry("")documented as returning the current system's IPs, but I don't know if we should extend it to also work if you happen to give the system's hostname as a string too.wfurt commentedon May 22, 2020
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.
antonfirsov commentedon May 22, 2020
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
hostnameor""than for the opposite. As of @wfurt's last comment, to me this doesn't look like a radical change in our existing behavior, it's more about making it more consistent and robust.antonfirsov commentedon Jun 12, 2020
An open question:
Since we won't be able to return
ai_canonnamewhengethostnamefails, we need to decide what to return inIPHostEntry.HostName. It can be eithernullor or just mirror the inputhostName.wfurt commentedon Jun 12, 2020
I would suggest to return hostName it self to prevent issues with null.
mjsabby commentedon Aug 15, 2020
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.