wsl: add host DNS fallback to user-mode networking resolv.conf

[VedantMadane]

Problem

When user-mode networking is enabled on a WSL-backed podman machine, createUserModeResolvConf writes a static /etc/resolv.conf containing only nameserver 192.168.127.1 (the gvproxy/gvforwarder address). The podman-net-usermode distro keeps WSL's auto-generated resolv.conf and works fine, but the main machine distro has generateResolvConf = false in its wsl.conf, so its resolver never updates.

When the host connects to a VPN (or any event that changes the host DNS), gvproxy may not forward queries to the new DNS servers. The main distro loses DNS while podman-net-usermode continues working — exactly what #28392 describes.

The workaround found by users is copying /etc/resolv.conf from the podman-net-usermode distro into the main distro. That works because the networking distro has the host's real DNS servers.

Fix

After writing nameserver 192.168.127.1 to /etc/resolv.conf, also append the host's nameservers from /mnt/wsl/resolv.conf (the WSL-shared resolver file). The Linux resolver tries nameservers in order, so:

1. gvproxy (192.168.127.1) remains the primary DNS path — no change for the happy path
2. If gvproxy is unreachable (VPN, network change, etc.), the resolver falls back to the host DNS
3. In both NAT and mirrored WSL modes, /mnt/wsl/resolv.conf is maintained by WSL and reflects current host DNS

If /mnt/wsl/resolv.conf doesn't exist, the behavior is identical to before (only 192.168.127.1).

Changes

• declares.go: New createResolvScript constant — a small bash script that writes the user-mode nameserver then appends host nameservers from /mnt/wsl/resolv.conf as fallback.
• usermodenet.go: createUserModeResolvConf now pipes the script to bash instead of piping static content. Also fixes a minor style nit (return err → return nil after the nil-check).

Testing

Tested the script logic on a local WSL setup (Windows 11, WSL 2, mirrored networking). Verified that the resulting /etc/resolv.conf contains both the 192.168.127.1 entry and the host DNS servers. With VPN connected, DNS resolves through the fallback servers when gvproxy is unavailable.

Fixes: #28392

Signed-off-by: Vedant Madane vedantmadane@gmail.com

[packit-as-a-service]

[NON-BLOCKING] Packit jobs failed. @containers/packit-build please check. Everyone else, feel free to ignore.

[Honny1]

I don't think this approach will work. The issue could be that gvproxy doesn't forward DNS to updated host nameservers after a VPN connects. I'll defer to the Windows experts, though.

cc @l0rd

[lstocchi]

@VedantMadane if you use an older version of gvproxy (like https://github.com/containers/gvisor-tap-vsock/releases/tag/v0.8.7 ) do you still face the same issue? There could be a regression there

[VedantMadane]

Thanks @lstocchi. I'll test with gvproxy v0.8.7 to see if the issue persists and report back. If it's a regression there, I'll update the PR with the findings.

[github-actions]

A friendly reminder that this PR had no activity for 30 days.

[VedantMadane]

@snejus @lstocchi Tested this on a podman 5.8.2 machine with user-mode networking. Injected the v0.8.7 gvproxy binary into both the main distro and the podman-net-usermode sidecar. Forced the pre-PR resolv.conf with just nameserver 192.168.127.1 . When I flipped the host Wi-Fi adapter DNS to 8.8.8.8, containers forced with --dns 192.168.127.1 still timed out on nslookup. So the breakage looks like it happens even on 0.8.7. The host fallback in this PR should still help. Let me know if you want more details or a fresh machine run.

[lstocchi]

@VedantMadane just tried to see if i could replicate it but it seems to work as expected. I also tried with mirrored mode.
With the broken gvproxy 0.8.8:

• i start the vm, ssh in it, ping/nslookup work fine
• i enable my corp vpn or tailscale, ping/nslookup fails with a time out

With gvproxy 0.8.9 it works fine without/with vpn

I used gvproxy 0.8.9 as this is the new release which contains the fix for this kind of problems and it will be used by the next podman 5.8.3.

Having a new machine should not be required but if you can clean your env up and try with a new machine + gvproxy 0.8.9 it would be great. If you modified the podman-net-usermode sidecar also remove it so it get recreated. Let us know. Thanks!!