[systemd-devel] systemd-resolved namespacing

[Andrew Athan]

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>