Adding nameserver entries from NetworkManager connections

[brianjmurrell]

When I run podman run it seems to be pulling DNS resolver information from the connections that are active in NetworkManager. I.e.:

$ podman run -it --rm fedora:latest bash -c 'cat /etc/resolv.conf'
search wolf.foo.example.com foo.example.com example.com example.bc.ca example foo.corp.example.com
nameserver 169.254.0.1
nameserver 10.22.125.248
nameserver 10.248.2.1
nameserver 10.75.22.247
nameserver fd31:aeb1:48df::2
options ndots:1

My hosts /etc/resolv.conf:

$ cat /etc/resolv.conf 
# Generated by /etc/NetworkManager/dispatcher.d/25-vpn-bind
search vms.local example example.bc.ca wolf.foo.example.com foo.example.com example.com
options ndots:1
nameserver 127.0.0.1

But those other 4 (non-169.254.0.1) nameserver entries are from the VPN connection and the local network connections on my machine. The only place those resolvers' information would be known about would be in NetworkManager. Is podman querying NM to add these? How can I disable this if it is? While they shouldn't necessarily be used since the 169.254.0.1 nameserver should answer all queries, it would be a cleaner (and less confusing) looking /etc/resolv.conf without that noise in it.

[Luap99]

127.0.0.1 cannot be used by your containers obviously so podman tries to look into common configs, it doesn't query NetworkManager but it does check if some files exists
https://github.com/containers/common/blob/fdbae3a180cb1d81cb4316e0077b3906672c75a8/libnetwork/resolvconf/resolv.go#L88-L93

This allows for dns to work without default to google servers in this case.
Rootless is a bit spacial because we have a user space proxy (pasta or slirp4netns that can be used to handle the dns), thus the 169.254.0.1. It may not be required to have more dns servers but it seems still like a good idea in case the first one fails for whatever reason.

If you want to specify your own you can use --dns ... or the dns options in containers.conf

[brianjmurrell]

127.0.0.1 cannot be used by your containers

Indeed. But as you say, podman seems to have it's own DNS resolver/proxy which the container can reach at 169.254.0.1. So since podman itself is providing this resolver/proxy (and so it should always be there to answer queries) why bother adding the other resolvers when they might be as equally unreachable as 127.0.0.1 but even worse, might be the cause of an information leak to resolvers that should not be used in the podman context?

If you want to specify your own you can use --dns ...

I could, but I would be adding fragility to an environment that doesn't need it added. What if I use --dns=169.254.0.1 and that 169.254.0.1 address changes in the future? All of my containers will break.

Ultimately, other than adding the other, unnecessary, potentially information leaking DNS resolvers this all works as expected without the user having to specify anything.

So does adding the additional resolvers add any value, at the risk of being an information leak sink?