Do not use non-core systemd

Posted Sep 25, 2025 14:09 UTC (Thu) by mathstuf (subscriber, #69389)
In reply to: Do not use non-core systemd by intelfx
Parent article: An unstable Debian stable update

> Split DNS is basically the entire reason systemd-resolved exists. And it does in fact work very well — in my experience, this is the *first* time split DNS on Linux actually worked well, and I use it daily.

I have to reconfigure resolved (via `/etc/nsswitch.conf`) because it causes network namespace leakage. If I have a network namespace jailed to a VPN, systemd-resolved needs to live *in* that namespace to reliably do DNS for it (but then it cannot service non-VPN requests…). But because it leaks through `nss` plugins, I have to at least remove the `[!UNAVAIL=return]` behavior. So instead, I remove that and put it behind `dns` to avoid the latency involved when it fails to service VPN-destined requests.

Is there some configuration magic around to handle this that you know of?

Do not use non-core systemd

Posted Sep 25, 2025 23:53 UTC (Thu) by ebiederm (subscriber, #35028) [Link] (3 responses)

pair bind mounts of the config file with the network namespace?

ip netns allows for that. I don't know about systemd-networkd

Do not use non-core systemd

Posted Sep 26, 2025 3:15 UTC (Fri) by mathstuf (subscriber, #69389) [Link] (2 responses)

Yes, `ip netns exec` is involved in using it. It knows how to deal with `resolv.conf` and mounts that in a mount namespace for the process, but not `nsswitch.conf` AFAIK.

Which reminds me that I need to also fix `resolv.conf` so that things are happy too. If it is a symlink, the `ip netns exec` mount namespace is broken when the target `resolv.conf` is rewritten with a "write then rename into place"; `cat newresolv.conf > /etc/resolv.conf` works though.

Do not use non-core systemd

Posted Sep 28, 2025 1:49 UTC (Sun) by ebiederm (subscriber, #35028) [Link] (1 responses)

It should be just a matter of putting a new nsswitch.conf in the right place.

If my memory serves the code just walks through the configuration directory and bind mounts every thing in it, into /etc.

Do not use non-core systemd

Posted Sep 28, 2025 2:55 UTC (Sun) by mathstuf (subscriber, #69389) [Link]

Indeed it does. Thanks; I can at least use the non-symlink version then (as the symlink (target?) rewriting breaks the bind mount of the configuration file).

Do not use non-core systemd

Posted Sep 26, 2025 0:19 UTC (Fri) by intelfx (subscriber, #130118) [Link] (2 responses)

> I have to reconfigure resolved (via `/etc/nsswitch.conf`) because it causes network namespace leakage. If I have a network namespace jailed to a VPN <...>
>
> Is there some configuration magic around to handle this that you know of?

I don't think systemd-resolved is network namespace aware, and I'm not familiar with any tricks in that area. But that's a hugely niche use-case, and not what I was defending. Normal "split DNS" is when you have multiple network interfaces with disjoint sets of routes in a single network namespace.

Do not use non-core systemd

Posted Sep 26, 2025 3:17 UTC (Fri) by mathstuf (subscriber, #69389) [Link] (1 responses)

Ah. I think of network namespacing tricks as a way to get split DNS without actually allowing a process to route over both at once. But perhaps I'm just doing something "more" than "just" split DNS then. In any case, I've found a block tower setup that works to my satisfaction; I'm more looking for ways to put more mortar around the base rather than "don't look at it sideways too hard" stability.

Do not use non-core systemd

Posted Sep 26, 2025 8:38 UTC (Fri) by nim-nim (subscriber, #34454) [Link]

The usual use case for split dns is a backend network with private resources, and a hardened front end network for remote access. This kind of setup to work pretty much requires dual routing (and one could route remote connexions via the backend link but that would defeat the purpose of isolating untrusted traffic on a heavily audited frontend network).