Shall we lookup host's /etc/hosts before forwarding other request to host's /etc/resolv.conf?

[xiaoyar]

This is kind of a requirement.

From host's POV, usually it looks up /etc/hosts firstly, then send request to /etc/resolv.conf.
Similarly, from container's POV, it looks up /etc/hosts firstly, then send request to aardvark-dns.
Ideally aardvark-dns should look up its own config file first, then look up host's /etc/hosts, then forward request to host's /etc/resolv.conf.
Especially for Non-DNS users, they don't configure /etc/resolv.conf but just add some entries in /etc/hosts in host.
Adding such logic of looking up host's /etc/hosts before forwarding request to host's /etc/resolv.conf would benefit those Non-DNS users.

[mheon]

This sounds like an information leak - would allow containers to see information about the host that they otherwise could not. Potentially a security risk, so I'm rather leery about allowing it.

[baude]

I would tend to agree with you @mheon ... we have no way to programmatically determine intent.

[xiaoyar]

Thanks @mheon @baude for your response.
This is what I thought:

1. By default, when container is started by podman run, it copies host's /etc/hosts to container's /etc/hosts. Given that, perhaps it's unlikely an information leak for aardvark-dns to look up host's /etc/hosts, anyway container already knows the content of host's /etc/hosts.

2. When forwarding other requests to host's /etc/resolv.conf, aardvark-dns already knows the content of host's /etc/resolv.conf, is that also an information leak?

3. Non-DNS users do have requirement for aardvark-dns to look up host's /etc/hosts, considering the following use case:

• Non-DNS user defines IP for outside servers in host's /etc/hosts
• They are running Nginx in container, Nginx needs to access those outside servers by the following configuration in nginx.conf

resolver 192.168.227.1;   ### This is the gateway IP on which aardvark-dns is listening
server {
    location / {
        set $backend_servers backends.example.com;
        proxy_pass http://$backend_servers:8080;
    }
}

Due to the implementation of Nginx, when it uses resolver to resolve a server name, it sends the DNS request to resolver with by-passing looking up /etc/hosts, so defining anything in container's /etc/hosts wouldn't help here.
Since this is a non-DNS environment, there's no name server defined in host's /etc/resolv.conf, so aardvark-dns will forward other requests to nowhere.
However, if aardvark-dns can add the logic to look up host's /etc/hosts, it will be pretty helpful thinking of this use case.

[xiaoyar]

Any update on this issue?

Alternatively, is it possible to introduce a new command line option to podman network create command, to let user decide to lookup host's /etc/hosts or not?

[Luap99]

1 and 2 can be configured by users, we do such a leak by default but it can be changed via podman options so doing unconditionally in aardvark-dns could break that promise. Adding this behind an opt-in option is possible but I would still see this as a rather unique use case.

If you are already using systemd-resolved then that should already lookup /etc/hosts by default (https://www.freedesktop.org/software/systemd/man/resolved.conf.html#ReadEtcHosts=). This is the default on fedora and on my system it seems to work like you want with that.