Re: systemd-resolved namespacing

[Petr Menšík <pemensik@xxxxxxxxxx>]

Hi Andrew,

I think that kind of separation works well if your containers use plain
DNS protocol over IP. If you do not use systemd-resolved in a container,
it just sends queries to whatever servers it reads from
/etc/resolv.conf. If you need different nameservers, mount --bind should
allow custom files for selected instances. Not via netns namespace, but
file namespace.

When local resolver is involved, it is more complicated. I think it is
usually not required to deliver different results for internet names in
containers. Usually container machine uses just local names and
considers any name resolution to be sent to host's provided resolver. I
think it usually should be host-level cache, where all containers would
take advantage from shared cache. I think dns cache does not belong to
containers itself.

Because I have installed libvirt anways, I use for my systemd-nspawn
containers libvirt's interface with dnsmasq provided cache/dns/dhcp.
That ensures any container receives proper network. If multiple separate
namespaces would be required separate vibrX interfaces would be used.

I don't think systemd should reimplement also whole network setting
features of libvirt. For example podman configures also dnsmasq and
provides /etc/resolv.conf pointing to that instance. I think that
solution does not belong to netns itself. Any nss plugin would depend on
filesystem namespace available. Systemd-resolved cannot provide it by
default, because it mixes in also different non-DNS protocols. Read
"Networking in a systemd-nspawn container" thead for explanation. In any
case, DNS cache listening on non-localhost address available to netns
network would be required. systemd-nspawn -b allows use of
systemd-networkd or any other network configuration via DHCP.

Unless you want to provide Wireguard on default netns, I guess you
should run dns cache for split-dns feature in netns itself. I guess
netns-aware nss_dns would have to be implemented. Which would try
netns-specific resolv.conf file before default /etc/resolv.conf. But not
all programs use libc functions and they would fail. Wouldn't running
full container solve your problems?

Cheers,
Petr

On 12/1/21 10:39, Andrew Athan wrote:
>
> I'm not sure this is the right place to pose this question, nor that
> I'm asking the "right" question, so kindly direct me if I "have it all
> wrong."
>
> Question:
>
> Having looked at the "namespace" features such as those of `ip netns`
> and/or those available via `unshare` or even `systemd-nspawn` it seems
> there is a rather large hole in that DNS resolution and the associated
> caches cross namespace boundaries. I suppose this is a general problem
> faced by any system/node level caching service accessed by APIs from
> within namespaces.
>
> Maybe I'm thinking about this wrong, but it would seem to me that
> network services such as the DNS cache should respect namespace
> boundaries. Otherwise, a container that has (for example) set an
> /etc/netns/othernamespace/resolv.conf pointing to a different DNS
> server than the node's main resolv.conf will receive cached responses
> from queries made outside its namespace.
>
> Probably this is an issue that goes beyond systemd-resolved and should
> also be addressed in glibc's "nss" helpers such as nss-resolve and
> nss-dns and/or any associated caches.
>
> Are there plans to address this issue? I'm assuming there's enough
> information about the context of a resolution request at the time
> systemd-resolved receives that request, for it to know the namespace
> into which it is vending its response? Perhaps this would not be the
> case for queries sent to the stub 127.0.0.53 address, but I imagine
> even this could at be dealt with by providing multiple stub responders
> on separate IPs that can be targeted appropriately from within each
> network namespace.
>
> It's possible the "safe" solution is to turn of name resolution and
> other caches or to use a more complete container solution (e.g. a more
> complete virtual OS instance) and that pushing namespace support into
> the resolver is some kind of slippery slope -- but it seems like a
> clear and present (and common) need, if not danger.
>
>
>
> Things I've read before posting this:
>
> man 8 nsenter
> man 8 ip-netns
> man 8 systemd-resolved
> man 1 systemd-nspawn
> man nss-resolve
> https://gist.github.com/zoilomora/f7d264cefbb589f3f1b1fc2cea2c844c
>
> The motivating usecase:
>
> client apps operating in a namespace, through a Wireguard VPN device
> with default routes and DNS via the far end should resolve names
> always as if the DNS server configured in the namespace's resolv.conf
> sourced the response.
>
> Thanks!
> Andrew
>
-- 
Petr Menšík
Software Engineer
Red Hat, http://www.redhat.com/
email: pemensik@xxxxxxxxxx
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB