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

[Thomas HUMMEL]

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

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

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 ?

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 ?

Thanks for your help

--
Thomas HUMMEL