resolvconf (resolvectl) wrongly splits arguments

[worldowner]

systemd version the issue has been seen with

251.6

Used distribution

Arch Linux

Linux kernel version used

6.0.2-arch1-1

CPU architectures issue was seen on

x86_64

Component

resolvectl

Expected behaviour you didn't see

I use StrongSwan to connect to VPN. During connection it sets up DNS using resolveconf which is a symlink to resolvectl on my system.
The relevant log from failed attempt to set DNS servers looks like this:

installing DNS server 192.168.35.2 via resolvconf
resolvconf: Failed to resolve interface "xf.inet.ipsec.192.168.35": No such device
removing DNS server 192.168.35.2 via resolvconf
resolvconf: Failed to resolve interface "xf.inet.ipsec.192.168.35": No such device
adding DNS server failed

xf is the name of XFRM interface that I use for this connection.
The problem is quite new. I don't use this connection very often so I'm not sure when this started to happen exactly but I'm quite confident that everything was working properly on systemd 250 (and older).

Unexpected behaviour you saw

DNS is not set by resolvconf invoked by StrongSwan.

Steps to reproduce the problem

Configure XFRM interface for IPSec connection. Configure StrongSwan's resolve plugin like this:

    resolvconf {
        iface_prefix = xf.inet.ipsec.
    }

Additional program output to the terminal or log subsystem illustrating the issue

No response

[yuwata]

Let me confirm, the interface name which you want to add the DNS server is xf.inet.ipsec.192.168.35, right?

[poettering]

so the resolvconf syntax is not compatible with interfaces with dots in them, that's the simple fact of life, it's how that interface was designed.

See this the man page of the original Debian tool:

https://manpages.ubuntu.com/manpages/xenial/man8/resolvconf.8.html

i.e. interfaces may be suffixed by a dot and a protocol specifier.

Hence if you use the dots in your regular naming, then things will necessarily just break because of ambiguity.

[yuwata]

BTW, now I am working on this, to make it handle the ifname more gracefully.

[worldowner]

@yuwata not really. What I expect is that 192.168.35.2 is set as a DNS for xf interface. I don't set it myself, StrongSwan does. I configured it based on https://docs.strongswan.org/docs/5.9/plugins/resolve.html
According to resolvconf's manapage interface[.protocol] is valid interface name.
When I change configuration to iface_prefix = xf:

installing DNS server 192.168.35.2 via resolvconf
resolvconf: Failed to resolve interface "xf192.168.35": No such device
removing DNS server 192.168.35.2 via resolvconf
resolvconf: Failed to resolve interface "xf192.168.35": No such device

so the separator (dot here) seems necessary.

Moreover I have this configuration on 2 computers and it was working perfectly fine not long time ago and now it fails on both in the same way so most likely systemd or StrongSwan changed its behavior. I reported this here because I think that I had it working with StrongSwan 5.9 and I looked at bugs reported to StrongSwan and I didn't find case similar to mine.

[poettering]

The freebsd openresolvconf has the same limitation, see:

https://www.freebsd.org/cgi/man.cgi?query=resolvconf

So, given we didn't define the command line interface, and the interface is the way it is I doubt we can fix this properly

[poettering]

we made a change a while back in e8d0eb3 to chop off the "protocol" part at the last instead of the first dot, to deal with the fact that in vlan envs its common to use a dot. My guess is that that's what changed behaviour for you.

[worldowner]

You may be right. I downgraded systemd to 251.3 which was released before the change you've mentioned and everything works fine again. The thing is that my interface (xf) doesn't contain any dots. That makes me think that StrongSwan uses IP of DNS as a part of protocol in interface.protocol.
What do you think should be done? Is there anything from systemd side that can be done to make it work or should I fill a report to StrongSwan?

[yuwata]

Fix is waiting in #25052.

[poettering]

hmm, so who actually picked the interface name with the dots? You? if so, don't use underscores, it#s just an ambiguous mess. Or strongswan? then please file a bug asking them not to default to that, if they want to use resolvconf...

(I prepped #25064 documenting for our side that "." in an interface name is a bad idea)

[worldowner]

strongSwan does that. Even if I don't fallow pattern from documentation and set iface_prefix = xf (xf is a name of XFRM interface that I use for this connection) strongSwan seems to concat this prefix with DNS address that it is supposed to set. I deducted that from error message:
resolvconf: Failed to resolve interface "xf192.168.35": No such device.
I'm going to report this to strongSwan and ask them to stop using dots (which means they shouldn't use IP address as part of protocol either).