Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

DNS Resolution Broken Behind VPN on Windows and Possibly Unix #466

Closed
Nino-K opened this issue Jan 28, 2025 · 1 comment
Closed

DNS Resolution Broken Behind VPN on Windows and Possibly Unix #466

Nino-K opened this issue Jan 28, 2025 · 1 comment
Assignees
@evidolob

Comments

@Nino-K
Copy link

Nino-K commented Jan 28, 2025 •
edited
Loading

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 evidolob self-assigned this Jan 29, 2025
@evidolob evidolob mentioned this issue Jan 29, 2025
Merged
@evidolob
Copy link
Collaborator

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

@Nino-K Nino-K mentioned this issue Jan 29, 2025
Open
@Luap99 Luap99 mentioned this issue Feb 3, 2025
Closed
Luap99 added a commit to Luap99/libpod that referenced this issue Feb 3, 2025
@Luap99
update gvproxy version
89283c6 
The current macos installer gvproxy version has a number of issues
around dns handling[1,2]. They should be fixed now in 0.8.3 as they
reverted the dns changes back to the 0.7.5 code. This should make it
work like it used to be. Our 5.3.2 installer ships the 0.7.5 version so
users of the podman installer never noticed that but we got plenty of
reports from brew users. This needs to be backported into v5.4 to make
sure we do not ship the broken version as part of the installer.

[1] containers/gvisor-tap-vsock#462
[2] containers/gvisor-tap-vsock#466

Signed-off-by: Paul Holzinger <[email protected]>
@Luap99 Luap99 mentioned this issue Feb 3, 2025
Merged
openshift-cherrypick-robot pushed a commit to openshift-cherrypick-robot/podman that referenced this issue Feb 3, 2025
@Luap99
update gvproxy version
d4f5817 
The current macos installer gvproxy version has a number of issues
around dns handling[1,2]. They should be fixed now in 0.8.3 as they
reverted the dns changes back to the 0.7.5 code. This should make it
work like it used to be. Our 5.3.2 installer ships the 0.7.5 version so
users of the podman installer never noticed that but we got plenty of
reports from brew users. This needs to be backported into v5.4 to make
sure we do not ship the broken version as part of the installer.

[1] containers/gvisor-tap-vsock#462
[2] containers/gvisor-tap-vsock#466

Signed-off-by: Paul Holzinger <[email protected]>
tmeijn pushed a commit to tmeijn/dotfiles that referenced this issue Feb 10, 2025
@tmeijn
build(deps): update lima-vm/lima to v1.0.5
ba8dda7 
This MR contains the following updates:

| Package | Update | Change |
|---|---|---|
| [lima-vm/lima](https://github.com/lima-vm/lima) | patch | `v1.0.4` -> `v1.0.5` |

MR created with the help of [el-capitano/tools/renovate-bot](https://gitlab.com/el-capitano/tools/renovate-bot).

**Proposed changes to behavior should be submitted there as MRs.**

---

### Release Notes

<details>
<summary>lima-vm/lima (lima-vm/lima)</summary>

### [`v1.0.5`](https://github.com/lima-vm/lima/releases/tag/v1.0.5)

[Compare Source](lima-vm/lima@v1.0.4...v1.0.5)

#### Changes

-   `limactl` CLI:
    -   Fix start command: return error early when instance already exists ([#&#8203;3144](lima-vm/lima#3144), thanks to [@&#8203;jandubois](https://github.com/jandubois))
-   DNS:
    -   Fix a regression containers/gvisor-tap-vsock#466 ([#&#8203;3189](lima-vm/lima#3189))
-   QEMU:
    -   Enable SME on macOS 15.3 running on M4 ([#&#8203;3197](lima-vm/lima#3197), [#&#8203;3203](lima-vm/lima#3203), thanks to [@&#8203;jandubois](https://github.com/jandubois))

Full changes: https://github.com/lima-vm/lima/milestone/55?closed=1
Thanks to [@&#8203;alexandear](https://github.com/alexandear) [@&#8203;arixmkii](https://github.com/arixmkii) [@&#8203;jandubois](https://github.com/jandubois) [@&#8203;msgilligan](https://github.com/msgilligan) [@&#8203;olamilekan000](https://github.com/olamilekan000) [@&#8203;rfay](https://github.com/rfay) [@&#8203;s1gnate-sync](https://github.com/s1gnate-sync)

#### Usage

```console
[macOS]$ limactl create
[macOS]$ limactl start
...
INFO[0029] READY. Run `lima` to open the shell.

[macOS]$ lima uname
Linux
```

***

The binaries were built automatically on GitHub Actions.
The build log is available for 90 days: https://github.com/lima-vm/lima/actions/runs/13195714188

The sha256sum of the SHA256SUMS file itself is `d31365f1da7802a63c86b1e1609a19c1ce92244a4e6824d924a896b6c12810b0` .

***

Release manager: [@&#8203;AkihiroSuda](https://github.com/AkihiroSuda)

</details>

---

### Configuration

📅 **Schedule**: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined).

🚦 **Automerge**: Disabled by config. Please merge this manually once you are satisfied.

♻ **Rebasing**: Whenever MR becomes conflicted, or you tick the rebase/retry checkbox.

🔕 **Ignore**: Close this MR and you won't be reminded about this update again.

---

 - [ ] <!-- rebase-check -->If you want to rebase/retry this MR, check this box

---

This MR has been generated by [Renovate Bot](https://github.com/renovatebot/renovate).
<!--renovate-debug:eyJjcmVhdGVkSW5WZXIiOiIzOS4xNjIuMyIsInVwZGF0ZWRJblZlciI6IjM5LjE2Mi4zIiwidGFyZ2V0QnJhbmNoIjoibWFpbiIsImxhYmVscyI6WyJSZW5vdmF0ZSBCb3QiXX0=-->
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@evidolob evidolob

Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@evidolob @Nino-K