Sigh... I had a very in-depth response with my solution typed up, and clicking the "permalink" (which I assumed would get me a link to just my reply) caused the message to be deleted! I'll try to re-create it...
The problem was indeed related to software that is already on my system. My prior post got me thinking about verifying that a DNS server is indeed listening.
On my non-working laptop (with VMware Fusion 12 running):
% netstat -an | grep LISTEN | grep "*.53"
tcp6 0 0 *.53 *.* LISTEN
On the working clean Big Sur install (with VMware Fusion 12 running)
% netstat -an | grep LISTEN | grep "*.53"
tcp6 0 0 *.53 *.* LISTEN
tcp4 0 0 *.53 *.* LISTEN
This sure looks like a problem. With a working host, there is indeed something listening on the DNS port for IPv4. For my non-working host, it's only listening on IPv6. Time to dig a bit deeper:
Non-working host:
% sudo lsof -i -P -n
...
dnsmasq 15721 nobody 4u IPv4 0xbb40ee7a9140f6dd 0t0 UDP 127.0.0.1:53
dnsmasq 15721 nobody 5u IPv4 0xbb40ee7aaa0a21dd 0t0 TCP 127.0.0.1:53 (LISTEN)
Working clean Big Sur host:
% sudo lsof -i -P -n
...
mDNSRespo 237 _mdnsresponder 39u IPv4 0xbb40ee7a9275de1d 0t0 UDP *:53
mDNSRespo 237 _mdnsresponder 42u IPv6 0xbb40ee7aa04bcf95 0t0 UDP *:53
mDNSRespo 237 _mdnsresponder 43u IPv4 0xbb40ee7a9b7c7e6d 0t0 TCP *:53 (LISTEN)
mDNSRespo 237 _mdnsresponder 45u IPv6 0xbb40ee7a95d47d8d 0t0 TCP *:53 (LISTEN)
Yes, my non-working (with regard to DNS on a NAT VM) host has dnsmasq running on it. But only on the localhost/loopback adapter. Up until Big Sur, this wasn't a problem. VMware Fusion took care of its own network stuff for the most part, so it is agnostic to any host-level thing already bound to port 53. It bound its own DNS server to its own NAT adapter, and everybody was happy.
Now, starting with Big Sur, VMware Fusion leverages more OS-level networking stuff. So to implement a DNS server on its NAT adapter, it asks the host OS to start a DNS server. The problem here is that mDNSResponder is greedily attempting to bind port 53 on every address. And in my case, because I have something using port 53 on loopback, mDNSResponder fails to bind port 53 on any address.
If I stop the dnsmasq service (in my case via sudo launchctl unload /Library/LaunchDaemons/org.macports.dnsmasq.plist), everything works perfectly. Any VM using NAT now has the ability to look up domain names using the DNS server provided by DHCP.
Suggestion for a VMware-level fix (i.e. in an upcoming version of VMware Fusion):
- When using mDNSResponder to implement a NAT-level DNS server, attempt to bind only to the adapter/address that is being used by VMware for NAT (assuming this is possible). This would ensure that there will be no conflicts with whatever way the host OS is configured to do networking.
Suggestions for a User-level fix (i.e. for us mortals before a fix can be released), either:
- Before launching VMware Fusion, be sure that nothing is binding port 53 on any address.
After a VM has been started, you can probably re-start whatever was using port 53 again. At least I can in my case where dnsmasq was bound to 127.0.0.1:53
Though note that starting any new VM after you've re-occupied port 53 will break DNS for every running VM at this point. - Configure every VM guest to use a not-on-host DNS server. (e.g. 1.1.1.1 or 8.8.8.8)
