DNS native host resolving no longer works with vz VMs since v1.0.0

[dhealio]

Description

When using the vz VM and not using user-v2 networking, the DNS behavior mentioned in the documentation is no longer working as advertised when hostResolver.enabled is true (or unassigned).

This prevents being able to use the native OS resolver, which is needed for VPN configurations, split-DNS setups, as well as mDNS, local /etc/hosts etc.

The breaking change seems to be here, which prevents args.UDPDNSLocalPort etc. from getting assigned.

[dhealio]

To be more specific, DNS resolving of VPN hostnames on macOS was working on v0.23.2 when starting lima with the default configuration/parameters, but no longer works with v1.0.0 or v1.0.1.

FWIW, I have also tried starting lima with user-v2 networking via limactl start --network=lima:user-v2, but I am still unable to resolve VPN hostnames within lima. This seems to contradict the behavior mentioned here, but perhaps I am doing something wrong.

If this is by design, then how would I go about configuring lima to allow DNS resolving of VPN hostnames? The documentation should be updated to reflect any changes of behavior in this regard.

Otherwise, this is a breaking change that I'm hoping can be addressed soon.

[nirs]

Based on the comment this a regression.

[balajiv113]

@dhealio
The reason for that condition is, vz uses gvisor implementation for network. For that dns resolution is taken care by gvisor-tap-vsock. Which will take care of reading /etc/hosts to populate nameservers

The change in behaviour is due to gvisor-tap-vsock breaking change. This is fixed later. So after upgrade gvisor-tap-vsock it should work fine. Will check with gvisor-tap-vsock for a release
containers/gvisor-tap-vsock#398

[dhealio]

Thank you for the quick response!

It's low priority, but the network documentation would ideally be updated to reflect the changes in behavior mentioned by @balajiv113. This may save others from wasting time troubleshooting configuration issues etc.

[dhealio]

I have updated to v1.0.2, and unfortunately I am still seeing the issue (with and without user-v2 networking).

In case it helps, here are some details on my host system:

• macOS 15.1.1
• OpenVPN connect client v3.4.9
• The /etc/resolv.conf file on my host system does not contain any nameserver entries
• I see a VPN specific resolver when running scutil --dns
• I am testing with ping, e.g. lima ping host.vpn-domain.com; this returns "Name or service not known"

[subpop]

Using v1.0.2 as well. When I start up my default guest, this gets printed:

INFO[0010] [hostagent] Not forwarding TCP 127.0.0.53:53

That's the address that ends up in /etc/resolv.conf in the guest. Is that relevant?

[jandubois]

127.0.0.53:53 is the address for systemd-resolved, which will be running inside the VM.

You can run resolvectl status inside the VM to see what it is using to resolve names.