DNS Resolution Broken Behind VPN on Windows and Possibly Unix

[Nino-K]

DNS resolution is broken behind a VPN on Windows (and possibly Unix) after version v0.7.5, likely due to recent changes made in the DNS package. The problem stems from a refactor PR #339 that simplified the DNS resolution logic, inadvertently breaking functionality for systems relying on VPN-based DNS configurations.

Root Cause:

The issue appears to be related to a new approach introduced in the DNS package that queries DNS nameservers using the following function:

gvisor-tap-vsock/pkg/services/dns/dns_config_windows.go

Line 23 in c9dd0cb

nameservers := qdmDns.GetDNSServers()

However, this function on Windows always returns a default nameserver (8.8.8.8), which fails to resolve DNS queries within the VPN. Furthermore, this approach does not account for the fact that VPN network adapters on both Windows and Unix-based systems may not configure DNS servers at the adapter level. This makes the function call ineffective.

Previous Behavior (v0.7.5 and earlier):

Prior to v0.7.5, the DNS package used Go’s net.Resolver, which worked reliably on both Windows and Unix systems. This approach called the appropriate system-level APIs (e.g.,getaddrinfo on Unix or DnsQuery on Windows) and respected the DNS configuration set by the active VPN, ensuring correct resolution.

Proposed Solution:

I propose that we revert the DNS lookup mechanism on Windows to the previous behavior (prior to v0.8.0). Specifically, we should restore the old DNS resolution logic in dns_config_windows.go to ensure DNS resolution works correctly behind VPNs on Windows.
If you are open to this change, I am happy to submit a PR with the suggested updates.

Note: the issue #464 is possibly caused by this.

[evidolob]

We decided to revert PR #339 in Revert PR #339 #467