Thanks for responding Roy. On 28/04/2025 11:52, Roy Marples wrote: > > By contrast, almost anyone installing systemd-resolved on Debian is going > to expect per-interface configuration. > > Why are people going to expect that?
Because all of the other major networking solutions in Debian do it that way. Try configuring an interface in NetworkManager, networkd or (lately) ifupdown with dhclient and you will see what I mean. I'm certainly not trying to make a point about whether this is right or wrong, but it is undeniably the "usual" way that systemd-resolved gets configured by everyone else. > I have a counter argument - people installing stuff expect it to just work. See above. resolved is completely optional in Debian, as are openresolv/resolvconf. I expect they each have their own users with possibly different expectations. > 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. Presumably this isn't getting into trixie though, and I assume NetworkManager et al will still continue to configure it the "old" way unless and until they are explicitly given support for delegates? > 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. The "hacky patch" handles this by persisting the state under /run/network. As I've been at pains to point out, I'm not much of a fan of the implementation, but it is already in use by ifupdown and dhclient. Better the devil you know I suppose. Because of the interop with ifupdown, it does have the advantage that you can override things manually from /etc/network/interfaces. I found that particularly useful for controlling the "default route" settings in resolved, which can force it to be more pedantic about prefix matching. > 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. Yes, but I assume there would be considerable pushback against making either package mandatory in Debian. At the moment, the systemd-resolved package has a hard conflict with both openresolv and resolvconf so they can never be installed together. I have raised a feature request to get this changed, but... If that restriction were relaxed then there are various subtleties that would need to be taken care of to avoid breaking more things: Mostly regarding the ownership and function of /usr/sbin/resolvconf and /etc/resolv.conf with various different combinations of packages installed. And since we have *two* different resolvconf packages, any behaviour would have to be replicated in *both* of them. > > 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. Yes I noticed that too! It's a case of "when in Rome" I guess. It is not uncommon in Debian desktop installs to use both ifupdown and NetworkManager at the same time, on different interfaces: The former is most often used for wired interfaces and the latter for wireless networks. This was another reason why I thought it was better to go per-interface with resolved, because it keeps things consistent in this sort of mixed setup. > 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. At the moment, I think the biggest hurdle we face is those package conflicts: dhcpcd can coexist with resolved, but openresolv cannot. As I've pointed out above, removing that restriction would create other problems for us to solve. For now, doing anything that calls resolvconf in the presence of systemd-resolved is likely to remain broken. That's why I raised this bug! :-) Cheers, -Ken.
