[systemd-devel] Networking in a systemd-nspawn container

Tobias Hunger tobias.hunger at gmail.com
Sat Nov 20 13:31:26 UTC 2021


Hi Lennart,

On Fri, Nov 19, 2021 at 2:23 PM Lennart Poettering
<lennart at poettering.net> wrote:
> Two ideas I recently thought about:
>
> 1. Maybe resolved's "stub" logic should support listening on yet
>    another local IP address: 127.0.0.54 or so, where the same stub
>    listens as on 127.0.0.53, but where we unconditionally enable
>    "bypass" mode. This mode in resolved means that we'll not process
>    the messages ourselves very much, but just look at the domains
>    mentioned in it for routing info and then pass the lookup upstream
>    and its answer back almost unmodified. (we'd also not consider the
>    lookups for mdns/llmnr and such). Right now we only enable that mode
>    if we encounter traffic we otherwise don't understand. Thus, if you
>    use that other IP address you can use resolved basically as a proxy
>    towards whatever the current DNS server is, nothing else. (though
>    we'd still translate classic UDP and TCP DNS to DoT if configured)
>
> 2. Then, teach nspawn to optionally set up nftables/iptables NAT so
>    that port 53 of some veth tunnel IP of the host is automatically
>    NAT'ed to 127.0.0.54:53.

Both could work, but does this need to be this complex?

I had been wondering whether resolved could be made to listen on some
pipe (e.g. /run/systemd/resolved/socket). If that pipe does not exist,
then resolved would start up as normal and start to listen on that
pipe. If that pipe already exists, then it would just go into the
"bypass" mode you mentioned and forward every request through the
socket on to the "main resolved". Systemd-nspawn would then only need
to make sure to bind-mount that socket into place.

The nice thing IMHO (if that is even possible!) is that this would
require one more bind mount: Standard fare for anybody that ever used
a container. Network configuration on the other hand tends to vary a
lot between different admins and systems, so it is probably harder to
come up with a setup that works well for everybody.

But as I said: No idea whether my idea is even doable:-)

Best Regards,
Tobias


More information about the systemd-devel mailing list