Closed satwell closed 1 month ago
From the pasta docs this is expected:
--dns-forward addr Map addr (IPv4 or IPv6) as seen from guest or namespace to the first configured DNS resolver (with corresponding IP version). Mapping is limited to UDP traffic directed to port 53, and DNS answers are translated back with a reverse mapping. This option can be specified zero to two times (once for IPv4, once for IPv6).
https://passt.top/builds/latest/web/passt.1.html
I am not sure what it would take there to add tcp support.
cc @sbrivio-rh @dgibson
From the pasta docs this is expected
Right, yes, and that's just because users requested this feature for UDP, but never for TCP... until now.
I am not sure what it would take there to add tcp support.
We need to merge this first, then it should be relatively simple to add. Give us some time.
I'd keep this ticket open to track the new feature (or we can file one on bugs.passt.top instead).
This is now fixed in passt version 2024_07_26.57a21d2, and in the matching Fedora 40 update.
Perfect timing, I just run into it while adding TCP support in aardvark-dns https://github.com/containers/aardvark-dns/pull/484
Issue Description
When using pasta networking, TCP DNS queries to the podman network's DNS servers time out. UDP queries work fine. This seems to only affect pasta. Using slirp4netns instead works correctly.
This causes name resolution delays or failures when running anything in a container that happens to prefer TCP for DNS.
Steps to reproduce the issue
Steps to reproduce the issue
dig
with+tcp
to force use of TCP:podman run --rm --network=pasta alpine:latest sh -c "apk add --quiet --no-cache bind-tools && cat /etc/resolv.conf && time dig +tcp google.com"
Describe the results you received
dig times out trying to connect to the podman network's DNS server (
169.254.0.1
) and then falls back to the DNS servers copied from the host's config. Which succeeds but takes a long time, 30 seconds.Describe the results you expected
dig +tcp
should be able to resolve names promptly.podman info output
Podman in a container
No
Privileged Or Rootless
Rootless
Upstream Latest Release
Yes
Additional environment details
I can reproduce on Fedora 40 and Fedora Core OS 40. This is on a standard install with no other containers or extra services running.
Additional information
No response