I think it is fairly easy. If the /etc/resolv.conf changes not by a
change of systemd-resolved, it is very likely the address specified in
it does not point to resolved anymore. In that sense it does not matter
what systemd-resolved does with such information and how quickly.
Does it update its own configured forwarders if I overwrite
/etc/resolv.conf with something unspecified in resolved.conf or
resolvectl runtime changes? I have tried appending nameserver 8.8.8.8,
but it has not reported any change in resolvectl. I would not expect a
third party would overwrite /etc/resolv.conf and use address of
systemd-resolved in it. If you know such case, please share. Is there a
real-world example case when such behaviour is needed?
I think resolved can just queue incoming request even from resolve NSS
plugin. If it detects a change in /etc/resolv.conf link, then it can
restart waiting requests again (or after a short timeout, 1s would
work). It would be much better than checking the link state before every
single query. It would conserve CPU work on battery operated devices. I
would set resolv.conf files in /run/systemd/resolved/ immutable to
prevent other software writing into it.
On 3/24/23 11:41, Lennart Poettering wrote:
On Fr, 24.03.23 03:16, Petr Menšík (pemensik@xxxxxxxxxx) wrote:
Even if it could not use filesystem monitoring, I guess it could check those
files only once per second or so. Should not depend on number of done
queries.
It's not so easy. We generally want to give the guarantee that if
people from some script patch around in /etc/resolv.conf and
immediately fire a DNS request afterwards, that we'll handle this and
give you answers with the new config.
There are conflicting goals here: nice, reliably behaviour that config
changes are guaranteed to be taken into account, and a simple goal of
performance to reduce these stat calls.
Lennart
--
Lennart Poettering, Berlin
--
Petr Menšík
Software Engineer, RHEL
Red Hat, https://www.redhat.com/
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB
