Hi Ken ---- On Mon, 28 Apr 2025 23:20:43 +0100 Ken Milmore <ken.milm...@gmail.com> wrote --- > 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.
resolved isn't a networking solution, it's a DNS resolver - nothing more, nothing less. It's a baby version of dnsmasq, unbound or named, but specific to systemd. So, knowing that, which other DNS resolver can be setup per interface. > 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. Buit isn't this why we are here? resolvconf and openresolv are configured in the usual way of $interface.$protocol or $interface.$program and have been since before systemd was born and by more than just dhcpcd or the packages you've listed. > > 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? As I understand it, delegates appear like an interface in resolvectl output, so the work alongside the existing setup. So we could have a ens5.dhcp delegate and ens5.dhcp6 delegate for example if you just wanted passhthrough. > > > 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. Hmmm, if that's the case, could be just not use resovlectl and just write to /run/network and then send SIGHUP to re-read it's config? > > 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. So at least we agree that we both like something in the middle which can adjust things before they get into systemd :) > > > 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. I don't think anyone is trying to make things mandatory here. > > 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. No, I'm sure we don't need to replicate in both of them. Just document that as of now, resolvconf does not support resolved but openresolv does. And this might be a silly question, but have you considered putting your work into a script for Debian's resolvconf? > > > > 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. Well, the packaging is purely a Debian concen. Please understand that all my thoughts and arguments take other OS's into account. I'm a NetBSD person for example. Anyway, I don't see removing the restriction as creating other problems to solve at all. Not all programs are equal - for example bmake and GNU make which are both in Debian only work with POSIX Makefiles and yet many are just GNU. What's the expectation here? Understand this and understand why I don't see any problems here with removing that restriction. > 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! > :-) And it's a good bug to raise! But really it's against the wrong package ;) Roy
