Hi Michael,Thank you for your research. I've checked out the history of implementation of the resolvconf compatibility mode in systemd. It seems, that dropping protocol-specific identifiers was a conscious design decision of the systemd developers since systemd-resolved internals does not know anything about protocol identifiers. So, I think reporting a bug upstream won't change anything as it works as intended from their perspective. It seems that the resolvconf compatibility mode never intended to fully support all resolvconf features.
In my opinion, it is not optimal, that using the systemd-resolved package now enforces also using the resolvconf compatibility mode of systemd.
In the past, I used systemd-resolved alongside with the resolvconf package and a custom hook, which configures systemd-resolved with the data from resolvconf (see https://github.com/stsbl/iserv-server-systemd-resolved/blob/master/iconf/etc/resolvconf/update.d/systemd-resolved/20server-systemd-resolved_hook). With the newly introduced Breaks/Replaces, such a scenario does no longer work, although systemd-resolved also intended to support it:
(from `man systemd-resolved.service`) /ETC/RESOLV.CONFFour modes of handling /etc/resolv.conf (see resolv.conf(5)) are supported:
[...]• Alternatively, /etc/resolv.conf may be managed by other packages, in which case systemd-resolved will read it for DNS configuration data. In this mode of operation systemd-resolved is consumer rather than provider of this configuration file.
Note that the selected mode of operation for this file is detected fully automatically, depending on whether /etc/resolv.conf is a symlink to /run/systemd/resolve/resolv.conf or lists 127.0.0.53 as DNS server.
[...]In my opinion, it should be possible to use systemd-resolved along with the original resolvconf again. This could re-allow using systemd-resolved in cases, where the protocol specific identifiers are relevant (in conjunction with a custom resolvconf hook).
Maybe /usr/sbin/resolvconf could be managed with update-alternatives or the symlink from /usr/sbin/resolvconf to resolvectl could be shipped in a separate package?
Am 28.02.24 um 16:02 schrieb Michael Biebl:
On Sat, 17 Feb 2024 16:00:08 +0100 Felix Jacobi <fe...@jacobi-bs.de> wrote:In background, this executes `resolvconf -a IFACE.PROTOCOL` and supplies the nameservers to resolvconf, e.g. echo 'nameserver 192.0.0.1' | resolvconf -a ens3.inet However, the systemd-resolved resolvconf implementation removes the protocol indentifier: echo "nameserver 192.0.0.1" | resolvconf -a ens3.inetDropped protocol specifier '.inet' from 'ens3.inet'. Using 'ens3' (ifindex=2).This leads to the fact, that only ens3 is used internally. For the configuration above, this means the previous configured IPv4 nameserver is completely overriddden with the latter one in the IPv6 stanza. This also causes several other problems for tools relying on resolvconf not dropping the protocol identifier and I would consider this a breaking change compared to the original resolvconf implementation.The Debian package does not ship any patches in that regard. It would thus be best if you raise this upstream at https://github.com/systemd/systemd/issuesI did not immediately find, why resolvectl/resolved does strip away the protocol identifier. At the very least, this incompatibility could be documented in the resolvctl man page.Regards, Michael
-- Mit freundlichen Grüßen Felix Jacobi Kind regards Felix Jacobi
OpenPGP_0x2351A3C9FD44B05F.asc
Description: OpenPGP public key
OpenPGP_signature.asc
Description: OpenPGP digital signature
