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.
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. Roy
