Bug#1064133: systemd-resolved: Using systemd-resolved as drop-in replacements breaks in conjunction with ifupdown

[Felix Jacobi]

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.CONF
        Four 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 <felix at 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.inet
>> Dropped 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/issues
> 
> I 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_0x2351A3C9FD44B05F.asc
Type: application/pgp-keys
Size: 9947 bytes
Desc: OpenPGP public key
URL: <http://alioth-lists.debian.net/pipermail/pkg-systemd-maintainers/attachments/20240303/eb4c4e0c/attachment.key>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://alioth-lists.debian.net/pipermail/pkg-systemd-maintainers/attachments/20240303/eb4c4e0c/attachment.sig>