On Tue, 13 May 2025 23:10:11 +0100 Roy Marples <[email protected]> wrote: > On Sat, 26 Apr 2025 23:27:43 +0100 Ken Milmore <[email protected]> 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. > > So openresolv-3.16.4 will allow two approaches. > The limited per interface approach via resolvectl or the write to global and > dns delegate files like any other resolver approach. > Pick your poison. > Both ways offer more resolvconf support than what systemd's resolvconf shim > offers as well as anything discussed thus far and support the systemd notion > of marking an entries domains as both non searchable and non routeable. > > As far as trixie is concerned, both have limitations - resolvectl approach > only works per interface, systemd-resolved approach relies on DNS delegate > support which isn't in any systemd release yet. > Also, the resolvectl approach is slow because of the number of times we call > resolvectl. A minor point, but worth noting. > strongswan - a debian package - will only work with the systemd-resolved > approach as it doesn't have an interface. > > > 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. > > > [3] > > https://salsa.debian.org/debian/isc-dhcp/-/commit/ab10fa481ee012c52de95adfc92691c882bf78ac > > I looked at this and have some issues > > 1) /run/systemd/resolve/netif is stated as internal private data and not part > of the API > as such any long term hack around this is a Bad Idea Which Could Break on > Upgrade > 2) While you can write to it and it magically appears in resolvectl after a > SIGHUP, any futher action on > this file is futile - you have to go via resolvectl. At least this is > true on Fedora 41. > 3) Each time you add a new hack into /run/network you need to change all the > hacks > > But at the end, I will say this - systemd's resolvconf shim > 1) Embraces - resolvconf is a known and recognised standard of managing DNS > setup from various sources (iface.prog) > 2) Extends - it can configure systemd-resolved! > 3) Extinguish > - it breaks the orignal design goal of resolvconf which was to make > managing different sources of DNS setup easier (rejects iface.prog, just > allows iface) > - only supports systemd-resolved > > Point 3 violates the Principle Of Least Astonishment from the POV of the > system administrator who has used Debian for a long time.
Have we reached a conclusion on this particular issue? Martin-Éric
