---- On Sat, 26 Apr 2025 23:27:43 +0100 Ken Milmore <ken.milm...@gmail.com> wrote --- > > The issue I raised upstream has now been closed [1], after Roy produced a > new release of openresolv [2] with support for systemd-resolved. > > > Unfortunately, IMHO the direction taken in openresolv doesn't help us much > with the present bug, for the following reasons: > > - It violates the principle of least surprise (from the POV of network > interface configuration), by placing all name servers into the global pool, > rather than assigning servers and their routing domains to specific network > interfaces. > I am sure there are valid arguments for doing it that way. But it is > completely at odds with how resolved is "normally" configured by all the > other networking tools such as systemd-networkd, NetworkManager and dhclient. > By contrast, almost anyone installing systemd-resolved on Debian is going to > expect per-interface configuration.
Why are people going to expect that? I have a counter argument - people installing stuff expect it to just work. resolved is the *only* DNS resolver that can be configured per interface. DNS by it's nature from configuration is global, but you can still see the interface or source where it's derived by using `resolvconf -l` The only time it is not is when it's from a VPN and that's a whole new issue because some VPN's such as strongswan sit on top of existing interfaces and with the current design you the have two programs (say dhclient and strongswan) wanting to update the same interface via resolvectl with competing information. And by competing dhclient could say "here be public nameservers" and strongswan could say "here be private nameservers for this domain" and resolved currently does not support this. This is why you need resolvconf to manage this - and by that I mean openresolv or the Debian one. https://github.com/strongswan/strongswan/discussions/2085 systemd-resolved does not yet support Split Horizon DNS - https://github.com/systemd/systemd/issues/20485 There is a PR to resolve this via the concept of DNS Delegates from poettering - https://github.com/systemd/systemd/pull/34368 Once/if that get's merged then resolved is on feature parity with other resolvers. Then let's talk about state. If resolved is restarted, it's state learned via resolvectl is lost. How do we get that back? If it's baked in a config file like other DNS servers it's still there. Lastly, let's talk about features. openresolv offers the admin the ability to massage the resolv.conf data before it's applied to the DNS server. You can append, prefix, remove and change pretty much anything as it comes in. And like Debian's resolvconf you can also use it to just discard all inputs and keep /etc/resolv.conf alone. Now, none of the above might be important to you, but it's important to others because they've opened many bugs about it. I didn't just implement these features on a whim, they are asked for. > > - In any case, an openresolv-based solution still wouldn't circumvent the > package management issues we currently have in Debian, namely that the > systemd-resolved package conflicts with anything providing resolvconf. > there's also the problem that we would have to duplicate any new openresolv > behaviour into the resolvconf package to keep the two in step. You could split it out into it's own package, or manage it via alternatives? https://wiki.debian.org/DebianAlternatives > > > For the above reasons I've given up on the resolvconf approach, decided to > eat my earlier words and reconsider the "hacky script" technique once more: > > I have ported the resolved configuration script (originally borrowed from > Ubuntu) from dhclient [3] to work with dhcpcd. > This turned out to be completely trivial, since the hook script environments > provided by dhclient and dhcpcd are so similar. > Basically, it should just work. > > > See the attached patch. > > > Functionally speaking, this bespoke script solution has a lot to commend it: > > - It configures resolved in the "expected" way, i.e. per interface, the same > way as NetworkManager and the rest do. I find it interesting that NetworkManager does this per interface for resolved and yet just treats resolvconf as a global. > > - It integrates with ifupdown settings configured in /etc/network/interfaces: > Specifically, dns-nameservers, dns-search and dns-default-route can > optionally be set to manually override what comes from DHCP. > > - It is low-impact and follows the solution already in use, so we would hope > for little or nothing in the way of unexpected breakage. > > > So what's not to like? Well I have never been too keen on the > implementation details: > > - There is code duplication and shared state between the ifupdown, dhclient > and (now) dhcpcd packages. > The script needs to be maintained in step between all of these packages, > which implies fragility. > Strictly speaking, we could avoid this interdependency, but at the cost of > removing the useful ability to override things in /etc/network/interfaces. > I think it would be preferable if the same common script could be used by > all of the above packages: > Probably the central place to put it would be inside the ifupdown package. > This would not necessarily require a package dependency, if things were > handled correctly. So you realise you're effectively replicating what resolvconf does here per package? This was exactly why resolvconf was born back in the day .... You're also discarding DNS received via ND. https://github.com/NetworkConfiguration/dhcpcd/blob/master/hooks/20-resolv.conf#L117 > > - The script modifies some internal resolved state files under > /run/systemd/resolve/netif/. > I think the only reason for doing this is in case DNS gets configured before > resolved has started up: I would have thought that might be better handled > with systemd service dependencies or suchlike? > > - There are some other minor things, such as the use of mktemp, which I > would have preferred to avoid. > > > Notwithstanding the above wrinkles, I do think it would be worthwhile > getting something along these lines into trixie: > It will allow someone who has installed a base system with ifupdown to > simply "apt install systemd-resolved" and still have things work as expected. > > If there is any enthusiasm for pursuing this further then I would be > prepared to do some work on tweaking the solution to order. > Suggestions welcome... > > > [1] > https://github.com/NetworkConfiguration/dhcpcd/issues/500#issuecomment-2831237831 > [2] https://github.com/NetworkConfiguration/openresolv/releases/tag/v3.15.0 > [3] > https://salsa.debian.org/debian/isc-dhcp/-/commit/ab10fa481ee012c52de95adfc92691c882bf78ac > If you really want to have things pushed via resolvectl then I'm happy to revisit the resolvectl helper for openresolv as I committed here: https://github.com/NetworkConfiguration/openresolv/commit/a21cc3bd201217e2d4e271c87e1990e03622ba99 And we could work this together to satisfy your needs. openresolv can ship with both helpers and the admin can choose which one to use. What do you think? Roy
