rootless dns broken #16369
Comments
|
please test nslookup inside |
podman unshare --rootless-netns cat /etc/resolv.conf
search online.net.
nameserver 10.0.2.3
nameserver 2001:bc8:401::3
nameserver 2001:bc8:1::16podman unshare --rootless-netns nslookup smtp-gateway
;; Got SERVFAIL reply from 10.0.2.3, trying next server
Server: 2001:bc8:401::3
Address: 2001:bc8:401::3#53
** server can't find smtp-gateway: NXDOMAINpodman unshare --rootless-netns nslookup duckdns.org
Server: 10.0.2.3
Address: 10.0.2.3#53
Non-authoritative answer:
Name: duckdns.org
Address: 99.79.152.197 |
|
Wait, Looks like it is not finding the name in aardvarks db so it tries to resolve the name upstream which then times out. |
$ cat /run/user/1000/containers/networks/aardvark-dns/podman-default-kube-network
10.89.0.1
717cdee4c5cea03ef5c851ccb5edb3392d4585b58de671dec42bdd354c20fdca 10.89.0.4 dyndns,717cdee4c5ce
d0d9a9ca4126623b4b7bc622887a5f8b01eecde766e78975e207dd7dea06123b 10.89.0.10 smtp,d0d9a9ca4126
e445e5e07f1026efa6eecfcc7884890810781240bacc5a2ee67fabf88e2dcfb6 10.89.0.12 borg,e445e5e07f10I used # smtp-gateway-pod.yaml
apiVersion: v1
kind: Pod
metadata:
name: smtp
labels:
io.containers.autoupdate: registry
spec:
restartPolicy: on-failure
containers:
- name: gateway
image: docker.io/yoryan/mailrise:latest
imagePullPolicy: always
ports:
- containerPort: 8025
hostPort: 25
name: smtp
protocol: TCP
resources:
requests:
cpu: "10m"
memory: "128Mi"
limits:
cpu: "100m"
memory: "128Mi"
volumeMounts:
- name: mailrise.conf-hostpath
mountPath: /etc/mailrise.conf
volumes:
- name: mailrise.conf-hostpath
hostPath:
path: ./mailrise.conf # Change to bash output of $(pwd)/mailrise.conf# /etc/mailrise.conf
configs:
[email protected]:
urls:
- tgram://{bot_token}/ |
If the name is smtp then you have to use this as dns name. podman run has an --network-alias field which can be used to specify more names but I am not sure if this is supported with kube yaml. |
|
But I can have multiple containers with different names in the same pod also if I simply use "smtp" it wants to lookup it in the internet with ´online.net.` Is But even if I open port |
|
All containers inside the pod are in the same netns (share the same ip) so you need to use the pod name, the network setup is just run for the infra container which uses the pod name as dns name. |
|
It doesn't work inside the container. And what could fix this error? I just use systemD-resolved. Inside container: root@dyndns:/# nslookup smtp
Server: 10.89.0.1
Address: 10.89.0.1:53
Non-authoritative answer:
Name: smtp.dns.podman
Address: 10.89.0.10
Non-authoritative answer:
*** Can't find smtp.online.net.: No answer
*** Can't find smtp.online.net.: No answer |
|
I tried it on a different computer. I also get there: And |
|
A friendly reminder that this issue had no activity for 30 days. |
|
/remove stale |
|
Same here, docker-compose.yml Can't access 3306 port from prestashop neither by Thanks for your help ! |
|
I'm seeing similar issues on Debian, with podman 4.3.1 and aardvark-dns 1.0.3 and 1.4.0. Note though that I'm getting these issues also for rootful containers. However, I strongly suspect this is a bug in aardvark-dns. I can see that podman is injecting the correct config into I'm trying to pinpoint what the issue is exactly. At this point, it could either be an issue in one of aardvark-dns's dependencies (as Debian patches aardvark-dns to use older dependencies), or some weirdness in the Debian build process. |
|
@vrothberg @flouthoc thoughts? |
|
Sounds like a packaging issue in Debian. |
|
I have a similar issue in Fedora Silverblue whereby rootless dns resolution within containers is broken: 1/3 of requests with the name of other containers fail with no explanation. I believe this is probably tied to this issue: |
@baszoetekouw This (#16369 (comment)) is a packaging issue older |
|
I doubt that that is the problem here: I've tried I assume the issue is with one of the dependencies, as Debian builds |
|
@baszoetekouw that would indeed indicate that the issue is triggerd by one (or more) of dependent packages. Strangely, the supplied unit tests of Here is a list of modifications I've made in Debian to the dependencies: anything suspicious that wold explain that phenomenon? What surprises me is that containers/aardvark-dns#248 seems to indicate the issue also exists on arch linux. |
just FTR, debian does not currently ship 1.4.0, both aardvark-dns and netavark are currently at 1.0.3. I do have updated both packages locally but haven't uploaded them yet as I can reproduces the issue with both packages updated to 1.4.0 on my laptop. |
|
Hm, trying to compile aardvark-dns with trust-dns upstream in containers/aardvark-dns#275 seems to trigger the same symptom as discussed in this bug. Coincidence? |
|
I also have a similar issue on a barebone Alpine Linux Edge. |
|
A friendly reminder that this issue had no activity for 30 days. |
|
/remove stale |
|
I believe this to be resolved in debian/sid with Please let me know (ideally with bugs filed in debian) if you are still experiencing issues and how to reproduce them. |
|
I use arch linux. |
|
The fix is in v1.5 upstream and I guess arch already ships that. If your problem still exists in that version there is another bug. |
|
Ah, I didn't test 1.5 I also don't see the fix in the changelog |
github-actions
bot
added
the
locked - please file new issue/PR
Is this a BUG REPORT or FEATURE REQUEST? (leave only one on its own line)
/kind bug
Description
I can't use DNS names to communicate with pods.
Steps to reproduce the issue:
Describe the results you received:
Host Journal
Host
Container
# cat /etc/resolv.conf search dns.podman online.net. nameserver 10.89.0.1 nameserver 8.8.8.8 nameserver 8.8.4.4Container
Describe the results you expected:
DNS to IP resolution.
Additional information you deem important (e.g. issue happens only occasionally):
Output of
podman version:Output of
podman info:Package info (e.g. output of
rpm -q podmanorapt list podmanorbrew info podman):Have you tested with the latest version of Podman and have you checked the Podman Troubleshooting Guide? (https://github.com/containers/podman/blob/main/troubleshooting.md)
Yes
Additional environment details (AWS, VirtualBox, physical, etc.):
N/A
The text was updated successfully, but these errors were encountered: