[systemd-devel] systemd-resolved namespacing
Andrew Athan
aathan_systemd at memeplex.com
Wed Dec 8 03:42:30 UTC 2021
Petr:
Thank you so much for the detailed response. I am going to take the time
to fully grok it, so it may be a few days before I respond more completely.
However, yes, I agree, a fully containerized wireguard is a viable
solution (and I mentioned it too, in the last paragraph of my message).
However, a fully containerized wireguard is also much more heavy-weight.
Also, yes, this feels like a slippery slope. Where do namespaces end and
containers begin? However, DNS is a fundamental service that deeply
characterizes the network for its clients, so integrating support for
namespaces in its core functionality seems reasonable. But I'm no expert.
What we have here is an example of a non-network (i.e. non-message
based) API available across netns boundaries (e.g., glibc calls flow to
an nss lib agent outside the netns). At a high level, the sense I get is
that your alternatives all essentially sequester the netns DNS requests
via physical topology changes to the name resolution stack (by
leveraging additional "containerization" features of the system).
By contrast, I note that tools like "ip netns" already incorporate
lightweight features to facilitate changing the observed network
topology of contained executables. For example, `ip netns exec`
automatically installs alternate resolv.conf,
That's why I posed my question. Given this feature, the non-namespacing
of local resolver caches seemed to me a potentially dangerous hole that
can be easily missed by "most" people.
Maybe at least a simple warning about this issue in the `ip netns` docs
is advisable? Without it, it may seem like just having a different
resolv.conf means you're in a DNS bubble. But you're not.
Also, this can't possibly be a problem unique to DNS. Logically, it
should affect any part of the system that keeps a cache whose contents
depends on the network topology but where the cache is available across
netns boundaries. If routing protocols didn't obey namespace boundaries...
A.
=========
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/systemd-devel/attachments/20211207/20f0c85a/attachment.htm>
More information about the systemd-devel
mailing list