FQDN() broken on darwin

[fearful-symmetry]

Right now, on my machine running Sonoma 14.4.1 (23E224), FQDN() fails:

could not get FQDN, all methods failed: failed looking up CNAME: lookup Alexs-MacBook-Pro-2.local on 192.168.1.108:53: no such host: failed looking up IP: lookup Alexs-MacBook-Pro-2.local: no such host

On this host, hostname returns Alexs-MacBook-Pro-2.local. Interestingly, the Endpoint code seems to be failing in a similar way; that hostname value will return an error when put to getaddrinfo(). However, golang uses res_nsearch() instead of getaddrinfo() so there's something else going on.

Confirmed the same behavior on Sonoma 14.5.

Interestingly, on 10.15, it doesn't return an error, but just returns localhost, which is also incorrect, as it's different from the actual domain name set via hostname. This is due to to net.DefaultResolver.LookupAddr just returning localhost if you send it something like ::1

However, on 10.15, we still default to the cgo resolver, but this succeeds with localhost. but if you force the go-native resolver instead of getaddrinfo() via GODEBUG=netdns=go, 10.15 will now fail with the exact same error as getaddrinfo() on 14.4.

EDIT: I don't think this is fully related to release versions, but some mDNS setting I can't figure out. As this stackoverflow issue notes: https://apple.stackexchange.com/questions/253817/cannot-ping-my-local-machine , enabling sharing in MacOS makes it magically work. Not sure what the system is doing under the hood to the DNS settings when you change sharing settings.

[fearful-symmetry]

Brief note; python's implementation does work:

python -c 'import socket; print(socket.getfqdn())'
Alexs-MacBook-Pro-2.local

[cthulhusec]

Just gonna throw some extra info out there.

We've been dealing with effects of this issue and I have seen Agent report localhost for most devices on Sonoma 14.5. I have also seen the correct FQDN populate when the upstream resolver for the local network has an entry for the host.

Oddly though, I have seen Endpoint return the correct FQDN in all cases except for when a VPN interface is present, which is somewhat expected.

Where it gets extra weird is that in events from Endpoint event collection, the host.name field I have seen populated sometimes with the correct hostname but not FQDN and then also sometimes just the devices IP. And then the host.hostname field seems to always be populated with the correct hostname but not FQDN.

So there is some inconsistencies for sure across both Agent and Endpoint on Darwin.