Inconsistent behaviour using Dns.GetHostAddresses()

[nakda]

Context
I'm using Dns.GetHostAddresses() to list IP addresses of the local computer. Windows and Debian systems are producing inconsistent results.

Code

var hostname = Dns.GetHostName();
var addresses = Dns.GetHostAddresses(hostname);

Results

• On Windows, only the private address 192.168.1.25 is returned. Even if I manually had loopback/localhost entries in the hosts file.
• On Debian, the loopback address 127.0.0.1 is returned when entries are set in the hosts file. When entries are removed, the application outputs the following exception:
  System.Net.Internals.SocketExceptionFactory+ExtendedSocketException (00000005, 0xFFFDFFFF): Name or service not known

Observations
I was not expecting Windows to ignore hosts file entries while Debian does not. Also, I expected the private address (through DNS resolution) when entries are removed from the hosts file, as it's the behaviour on Windows.

Windows system

• Desktop computer
• Ethernet connectivity through motherboard
• Windows 10 x64 (1909 - 18363.778)
  • NET Core SDK 3.1.201 (incl. NET Core Runtime 3.1.3)

Debian system

• Odroid-XU SBC
• Debian 10 (Buster) - Linux kernel 5.6.2 (armhf)
  • NET Runtime 3.1.3

Related issues
Looking for similar issues, I found #27534 which seems to be closed. Also found #1488 but is related to CI tests so I didn't want to step in.

[ghost]

Tagging subscribers to this area: @dotnet/ncl
Notify danmosemsft if you want to be subscribed.

[wfurt]

.NET cannot manufacture the records and it depends on OS. On Linux, there is plugin architecture and starts with nsswitch.conf. So it possibly depends on ore aspects than just /etc/hosts. It also depends on resolver configuration and your DNS server configuration. For example hosts using DHCP may or may not be automatically added to DNS.

When .NET fails, you can try "nslookup name" to see what OS knows about given name.

[nakda]

@wfurt
Using nslookup I identified a DNS issue. Hostname set on the device was different than the identifier he has on the DNS server, so when it was requesting for its hostname the DNS could not find anything. It's now fixed.

Debian version is now properly returning the private address.

Thank you, and sorry wasting your time with a problem unrelated to dotnet.