Source of resolv.conf in podman stack

[magras]

Hello, @Luap99.

I'm researching #248 and noticed that there are 3 nameservers in the upstream list:

• 169.254.1.1 (link local interface) that seems to be systemd-resolved from the host
• and two public nameservers from host's systemd-resolved configuration

This list of nameservers matches /run/user/936/containers/networks/rootless-netns/resolv.conf.

I believe inclusion of public nameservers causes dns requests leak if systemd-resolved response was slower than 5/3=1.66 seconds.

Do you happen to know who generate this file in the podman stack?

[Luap99]

169.254.1.1 is actually a magic request podman sets up for pasta's --dns-forward option. That address is then used by pasta to redirect responses to the actual host nameserver. I think pasta reads only the first resolv.conf nameserver for it which then is used to map the given address to the real host nameserver. This is needed so that localhost resolvers such as systemd-resolved cabn actually be connected to from within the namespace.

This is the pasta/resolv.conf setup for the rootless netns:
https://github.com/containers/common/blob/54971400010fdcb0e504dc30571cda38af5e4fe8/libnetwork/internal/rootlessnetns/netns_linux.go#L231-L242
And then this is the podman resolv.conf code: https://github.com/containers/common/blob/main/libnetwork/resolvconf/resolv.go

The reason podman adds additional servers is simply as backup in case the first resolver fails.

I believe inclusion of public nameservers causes dns requests leak if systemd-resolved response was slower than 5/3=1.66 seconds.

That is certainly possible.

[magras]

The reason podman adds additional servers is simply as backup in case the first resolver fails.

I understand the intent, but systemd-resolved have it's own fault handling. Isn't copying public nameservers kind of redundant?

Also I should have explained that my systemd-resolved configured to strictly use DNS over TLS, therefore when aardvark-dns makes a direct request to a public nameserver from systemd-resolved config I call it a leak, because that request isn't encrypted. This is the main motivation for my research.

Do you think it will be possible to convince the team to generate resolv.conf only with the --dns-forward address 169.254.1.1?

I'm not familiar with the code, but if necessary I can try to make a PR.

[Luap99]

I understand the intent, but systemd-resolved have it's own fault handling. Isn't copying public nameservers kind of redundant?

Well who say the host is running systemd-resolved? This logic is applied for all nameservers.
Also fault handling within systemd-resolved doesn't help if there is a pasta bug for example that breaks the 169.254.1.1 forwarding. So I rather keep it on the safe side and include extra entries.

If you only want to use 169.254.1.1 it should be possible to pass --dns 169.254.1.1 to podman run, in that case aardvark-dns should only use that address. Or you can even set this addr on the network level with podman network create --dns.

see https://github.com/containers/common/issues/2492 as well, if enough people want this kind of "no leak" behavior we can certainly add a new option for that I guess.

[magras]

Well who say the host is running systemd-resolved? This logic is applied for all nameservers.

I don't understand your argument. Podman literally checks that and extracts configs specific to systemd-resolved and NetworkManager.

To be clear, I'm not proposing a special treatment for systemd-resolved, quite opposite - I want to remove it. Except when it's necessary for mirroring the docker behavior if that's considered a goal for podman.

And speaking of docker, I've never seen unencrypted requests from a docker container with a custom network configured.

Also fault handling within systemd-resolved doesn't help if there is a pasta bug for example that breaks the 169.254.1.1 forwarding. So I rather keep it on the safe side and include extra entries.

There were a lot of security bugs when unprivileged user namespaces exposed huge attack surface in the kernel. Despite that, you are working on podman whose one of the main selling points is rootless mode. Hypothetical bugs should not stop the progress.

Also as I said in the other thread, this approach endangers people in the authoritarian countries. I know what you mean, but it is a little bit ironic to call that the safe side.

If you only want to use 169.254.1.1 it should be possible to pass --dns 169.254.1.1 to podman run, in that case aardvark-dns should only use that address. Or you can even set this addr on the network level with podman network create --dns.

Thank you. It seems to work. That doesn't remove public nameservers from resolv.conf, but the file is ignored as you explained in the linked issue.

see containers/common#2492 as well, if enough people want this kind of "no leak" behavior we can certainly add a new option for that I guess.

Should I create a new issue and link it to containers/common#2492, or will it be enough to highlight the systemd-resolved and NetworkManager specifics in a comment?

[Luap99]

To be clear, I'm not proposing a special treatment for systemd-resolved, quite opposite - I want to remove it. Except when it's necessary for mirroring the docker behavior if that's considered a goal for podman.

This is not so straight forward though, the special systemd-resolved file reading exists as localhost servers are simply not usable in many network scenarios so we really need that.
Now for pasta with --dns-forward it is an option to not do that and just rely on pasta but even that can cause problems if you have more than one resolvers defined the user likely still wants all entries so the client has a fallback in case the main server goes down. Sure if you only have the localhost server than this is not needed but it also means a lot more special cases for us to handle and test.

Also as I said in the other thread, this approach endangers people in the authoritarian countries. I know what you mean, but it is a little bit ironic to call that the safe side.

Any application can bypass resolv.conf, if that is a risk you already need firewall level blocking of unencrypted DNS queries.

Should I create a new issue and link it to https://github.com/containers/common/issues/2492, or will it be enough to highlight the systemd-resolved and NetworkManager specifics in a comment?

just add a comment there