[systemd-devel] systemd-resolved/NetworkManager resolv.conf handling

[Petr Menšík]

Oh, understood. Then it is specific problem to Fedora, because I think 
other distributions do not use systemd's implementation of resolvconf 
binary.

I think original Debian resolvconf package does not use -a interface 
parameter for anything serious. It just uses the same interface 
identifier to pair -a and -d for the same connection.

On the other hand systemd's resolvconf tracks settings per interface and 
it requires it to point to the real interface on the system. Of course 
F5 client should use a real interface name it is going to use. I am not 
sure what can be done for it on side of systemd. Perhaps systemd could 
allow configuration of aliases, so it would allow to map eth0.f5 to tun0 
interface. But that seems a mere workaround, F5 client should be 
modified to call resolvconf once it knows used interface name, not 
before that. It would be nice to issue a bug on F5 site. I haven't found 
issue matching your description. It would be worth filling.

https://support.f5.com/csp/bug-tracker

On 11/2/22 16:20, Thomas HUMMEL wrote:
> On 10/31/22 12:19, Petr Menšík wrote:
>
> Hello, thank you and Barry as well for your answers
>
>
>> I would suggest using strace to find what exactly it does and what it 
>> tries to modify. I expect sources for that client are not available.
>
> Well, digging a little deeper, here's what I've found out:
>
> 1) in the default case (described in my initial post), i.e.
>
>     /etc/resolv.conf symlinked to systemd-resolved 
> /run/systemd/resolve/stub-resolv.conf
>     no dns nor rc.manager directives in NM config
>     no F5 client NM profile
>
> The vpn client:
>
>     a) backs up /etc/resolv.conf to /etc/resolv.conf.fp-saved
>     b) readlinks the symlink
>     c) execve's /sbin/resolvconf providing nameservers (thus trying to 
> play along with systemd-resolved) but on the wrong interface on my 
> Fedora (eth0.f5 instead of tun0) [besides with a deprecated and not 
> used arg (-m)]
>
>     execve("/sbin/resolvconf", ["/sbin/resolvconf", "-a", "eth0.f5", 
> "-m 0"], 0x7ffd13bf8568 /* 30 vars */ <unfinished ...>
>
>     d) set up tun0 interface and bring it up
>
> -> hence we end up with:
>
>     a) /etc/resolv.conf.fp-saved as a regular file, copy of 
> /run/systemd/resolve/stub-resolv.conf
>     b) NM managed tun0 interface without and dns property in its 
> profile nor any disk persistent profile
>     c) unchanded /etc/resolv.conf (still linked to 
> /run/systemd/resolve/stub-resolv.conf
>
> so, systemd-resolved not knowing about vpn nameservers and vpn 
> nameresolution fails without workaround (like resolvectl dns adding 
> the tun0 nameserver for instance)
>
> 2) with NM handling /etc/resolv.conf as a regular file, i.e.
>
>    /etc symlink rm-ed
>    dns=default
>    rc.manager=file
>
> the F5 client consider it a 'legacy' setting and overwrite (which is 
> wrong to me) NM managed /etc/resolv.conf regular file
>
> it restores it when stopped by copying back /etc/resolv.conf.fp-saved
That is exactly what it should do for a VPN, unless it knows a more 
proper way to configure system DNS. Some packages like dnssec-trigger 
prevents that by setting additional parameter to /etc/resolv.conf, 
making it non-writeable even by root process. There is not a generic and 
better way other than resolvconf. On Fedora resolvconf is provided just 
for systemd-resolved in default installation. But it needs precise 
interfaces used, unlike original implementation.
>
>
> So, basically I'd say there are 2 bugs :
>
> 1) legacy handling which seems to consider pre-NM era legacy
> 2) resolvconf call when systemd-resolved is used (at least on Fedora)
>
> In any case, I don't understand why it does not set the NM profile 
> ipv4.dns property, which would let much more chances for NM and/or 
> resolved to work
Does "nmcli c" command show F5 profile in green, when it is connected? 
"nmcli c show <connection-name>" would provide all details it knows. I 
am not sure how information obtained from VPN plugins should work. I 
think network manager list has to be used for qualified response. It 
seems to me only VPNs configured by NM plugin know configuration details.
>
> Anyway, this leaves 2 unanswered questions, the first of which was my 
> initial one:
>
> 1) how could, when all resolv.conf-as-a-file-by-NM conf has been 
> removed (by me) and symlink to stub has been restored (by me) 
> systemd-resolved, with *no trace* of the vpn  nameservers in its own 
> /run/systemd/resolv/resolv.conf nor seemingly nowhere else, can be 
> still aware of the vpn nameservers (as described in my initial post 
> scenario) ?
>
> -> is there a persistent systemd-resolved cache on disk somewhere?
I don't think any persistent cache were ever on disk or that it would be 
a good idea. Most dns caches are able to dump contents of cache 
somewhere on request, but I haven't found a way to do that with resolvectl.
>
> 2) when running resolvconf by hand (resolvconf <int>) providing 
> specific interface specific nameservers (on stdin), it seems to update 
> the **global** /run/systemd/resolve/resolv.conf (hence making those 
> nameservers available for all interfaces ?)
>
> -> Is there any other place where the specific ns <-> interface is 
> persited or stored or is this global updating all there is ?
resolvconf might have some hacks to configure rules just for some 
subdomains. openresolv can do something similar. But usually resolvconf 
changes just global set of servers if the interface configured has 
higher priority than previous. Returns them back when such interface is 
stopped. resolvectl layer ignores -m parameter, but it pairs dns 
configuration with real interface. AFAIK none such information is 
persistent and is lost when systemd-resolved is restarted. But Network 
Manager's plugins configures it from NM interfaces again. I doubt 
external services unrelated to NM are handled, I think they have to 
reconfigure systemd-resolved again after its restart. Nothing is stored 
permanently.
>
> Thanks for your help
>
> -- 
> Thomas HUMMEL
>
-- 
Petr Menšík
Software Engineer, RHEL
Red Hat, https://www.redhat.com/
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB