DNS servers show requests from 169.254.1.2 (also for domains that shouldn't be requested by any running container) #27057
Replies: 3 comments 9 replies
-
|
169.254.1.2 is the address we use inside the container namespace for dns which should make pasta map that to the real host nameserver address from the host.
It would help if you provide the versions you are using and on which versions it used to work. |
Beta Was this translation helpful? Give feedback.
-
|
I'm currently using
In the DNS server, I see queries coming from other device on the network, showing the correct IP address. |
Beta Was this translation helpful? Give feedback.
-
Actually 169.254.1.1 is the dns address and 169.254.1.2 is --map-guest-addr (host address mapping). So assuming you host ip is 192.168.1.10 for example this option then creates a NAT mapping between 192.168.1.10 on the host and 169.254.1.2 in the container. We typically have to use that because pasta copies the same host ip address into the container so connecting to the host ip directly will just result in a local connection inside the namespace. The idea is that by connecting to 169.254.1.2 (host.containers.internal) the container reaches services running on the host address. My guess is that is also maps the other way around. So only the connections coming from 192.168.1.10 will be translated to 169.254.1.2 in the container. Podman started to use --map-guest-addr in v5.3 last year, I am not sure if there were any pasta changes since then. |
Beta Was this translation helpful? Give feedback.
-
|
Is there perhaps any test I can do or something I can change to have at least the queries coming from other devices showing up in the DNS server with their original IP addresses? I still don't get why some queries to domains like apple.com are coming from 169.254.1.2 and some other show their original IP. |
Beta Was this translation helpful? Give feedback.
-
Yes, incoming packets from the initial namespace on the host itself, going to a local (non-loopback) IP address are mapped using the same address. If 88.198.0.164 is a local address, then:
I would say let's try to understand exactly what's going on first.
I guess some DNS queries are from your own host (initial namespace, not from a container), and some are from containers or other hosts, correct? Could it be that the queries from the host are seen as coming from 169.254.1.2 and the other ones aren't? Do you see perhaps a difference between TCP and UDP, by the way? |
Beta Was this translation helpful? Give feedback.
-
|
I checked the again the queries logs on both DNS servers and now no logs are showing up anymore from 169.254.1.2! Which is strange I would say, after what has been said above (and from @dgibson below as well). I do see only queries using the UDP protocol btw. See below the full answer after a few hours of investigation. |
Beta Was this translation helpful? Give feedback.
-
|
Right. This is expected behaviour with pasta as configured by podman. Requests coming from the container's host will appear to come from 169.254.1.2. It can't show the host's regular IP address, because that IP is shared by the container itself. While this is counter-intuitive for this specific case, sharing the IP that way makes things simpler and more obvious for communication with any other peer. Note that pasta can be configured with any address you like, not just 169.254.1.2. The choice of 169.254.1.2 comes from podman. Using one of the link-local addresses seemed like the safest option - anything else would mean you're shadowing some other host on your local net or the internet. |
Beta Was this translation helpful? Give feedback.
-
|
Alright, I spent some time investigating the situation and this is outcome at the moment: Here a simple output from a test done with a container called I do see the internal IP being And here the DNS logs: I do not understand this at all. After the initial replies from @Luap99, @sbrivio-rh and now @dgibson, I thought that was normal to see the source IP as Regarding queries done from my laptop and showing up with the server IP is because (I think) a VPN container I'm running called Tailscale. If I enable the Tailscale VPN tunnel on my laptop, queries are showing as I'm attaching the output of From the host: From Thank you in advance for your time. |
Beta Was this translation helpful? Give feedback.
-
When you say "Server IP", do you mean the IP of the container in which the named is running? Or the IP of the host on which that container is running?
Oh that's odd. I'd expect things from the container host to appear in the container as 169.254.x.y. I would not expect such a link local address on the container itself. Particularly not as the only address on the container.
Uh... that's not what the quote below shows. It shows a server at
If the VPN is configured to tunnel everything - which is probably what it would be - then, yes I'd expect queries from the laptop to run via the VPN which would affect things. The DNS container will only pick one of the host's IPs - traffic from other IPs of the host will not be translated.
Oh... you're using podman's shared netns. That adds its own extra NAT layer which is probably what's confusing things. I don't know much about how that works.
I think this address must be being picked by podman. [snip]
... and I guess this address for the default gateway.
|
Beta Was this translation helpful? Give feedback.
-
These are the ips picked by pasta when it doesn't find a suitable interface with addresses on the host. (local mode) So what happen sis that sometimes pasta starts to early before the host network is fully configured. As such in this case the mapping --map-guest-addr happens between This ties back to #24970 as there no update in pasta when said host address changes (netlink monitor feature) |
Beta Was this translation helpful? Give feedback.
-
Right, thanks, I was about to comment on this and I forgot. See also https://passt.top/passt/commit/?id=14b84a7f077ecb734bb0e724f70bafeaa6d35a61 and the description of
Also picked by pasta, see commit above and the description of |
Beta Was this translation helpful? Give feedback.
-
Ah, right this makes sense. I didn't recognize at a glance which link-local IPs were which. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
I run my own DNS servers (primary and secondary), both based on Technitium containers running via Podman on separate hosts.
While reviewing queries on the primary server, I noticed a large number of requests originating from the IP address 169.254.1.2. Upon inspection, these requests appear to match traffic from containers I’m running.
From what I understand, 169.254.1.2 belongs to the link-local address range, typically used when a device cannot obtain an IP address from a DHCP server. Could this behavior be related to a recent Podman or Pasta update?
Previously, I would see queries coming from my server’s actual IP address, not from 169.254.1.2.
Additionally, I see requests to domains such as
conncheck.opensuse.org, which is just a health-check endpoint. However, these should originate from my server’s IP address, not 169.254.1.2. I also notice queries toapple.com,microsoft.com, and similar domains, which I don’t believe any of my containers are directly requesting.Can someone explain what’s going on here? Do I have something misconfigured?
Thanks!
Beta Was this translation helpful? Give feedback.
All reactions