runtime: Dns.GetHostEntry(Dns.GetHostName()) throws ExtendedSocketException when ifconfig succeeds

Description

From https://github.com/PowerShell/PowerShell/issues/12935.

I’ve looked through #29780, and this looks at least related to that (but is closed).

PowerShell’s (Azure DevOps) CI on macOS has been failing intermittently this week in a test setup codeblock that looks like this:

$hostName = [System.Net.Dns]::GetHostName() 
...
$hostEntry = [System.Net.Dns]::GetHostEntry($hostName)

The actual code is here

Trying to mitigate this in a PR, we retry several times and then fall back to ifconfig, which successfully resolves the address.

However, after that, our tests start failing due to failures in Ping.SendPingAsync here, with the error message Testing connection to computer 'Mac-1467.local' failed: Cannot resolve the target name. (I’d like to get a full stack trace, but I have yet to work out how with our testing infrastructure).

This suggests that .NET’s DNS resolution is failing when macOS’ builtins are succeeding.

Configuration

.NET Version: .NET 5, (SDK 5.0.100-preview.5.20279.10)
OS: macOS 10.14
Arch: x64

This issue only appears on macOS.

Regression?

From discussion in our issue, we’ve had issues on and off with System.Net.NetworkInformation.Ping functionality in the past, but currently its failing most of the time in our CI.

Other information

After reading through #29780, I saw from @wfurt’s comment that the OS sometimes fails the DNS resolution request and that a retry is necessary. However, in our case we retry 5 times and fall back to ifconfig. Our CI is showing that the retries all fail and ifconfig succeeds.

About this issue

Original URL
State: closed
Created 4 years ago
Comments: 16 (7 by maintainers)

Most upvoted comments

From https://github.com/actions/virtual-environments/issues/1042#issuecomment-644145685:

We have disabled /usr/bin/defaults write /Library/Preferences/com.apple.mDNSResponder.plist NoMulticastAdvertisements -bool true multicast advertisement service to prevent window pop-up “the name of your computer is already in use on this network mac”, which is the root cause of this issue.

rjmholt on Jun 15, 2020

it would be still nice IMHO to investigate and improve CI. We were not able so far to get grasp on what is causing this. (as some systems do and some don’t)

wfurt on Jun 12, 2020

so you call ifconfig and you parse text to get address of the interface(s)? You can get equivalent via

NetworkInterface[] nics = NetworkInterface.GetAllNetworkInterfaces();

and drilling to the IPv4 properties.

The logs may or may not have info. Looks or anything about mDns or discoveryd. There is fair amount of chatter about DNS stability on OSX (various OS X versions) You can try to run scutil --dns to get some system setting info. Do do resolution, we call POSIX getaddrinfo().

If you primarily care about own hostname, #36849 will fix it for you.

wfurt on Jun 11, 2020