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
