Gordon Messmer writes:
On 4/17/22 12:26, Sam Varshavchik wrote:
> I don't see where it's picking this up. The only thing I can think of is
> nsswitch.conf, but the "hosts" entry there is identical to what's on
> another, un-upgraded system.
Maybe remove the "resolve" entry from the hosts line:
$ rpm -qf /lib64/libnss_resolve*
systemd-libs-250.3-8.fc36.x86_64
yeah. systemd's injection has two prongs: via nsswitch and via resolv.conf.
Apparently it's not enough to let glibc's default resolver read whatever's
in /etc/resolv.conf and have systemd come in that door, it's also necessary
to inject it via nsswitch.conf's back door.
Apparently it's still been doing DNS resolution for host lookups, but it was
mostly working, so stayed under the radar, until the recent update broke it.
Additionally, the systemd-resolved rpm is actively hijacking
/etc/resolv.conf. From the package's scriptlet:
if systemctl -q is-enabled systemd-resolved.service &>/dev/null &&
! systemd-analyze cat-config systemd/resolved.conf 2>/dev/null |
grep -iqE '^DNSStubListener\s*=\s*(no?|false|0|off)\s*$'; then
if ! test -e /etc/resolv.conf && ! test -L /etc/resolv.conf; then
ln -sv ../run/systemd/resolve/stub-resolv.conf /etc/resolv.conf || :
elif test -d /run/systemd/system/ &&
! mountpoint /etc/resolv.conf &>/dev/null; then
ln -fsv ../run/systemd/resolve/stub-resolv.conf /etc/resolv.conf || :
fi
fi
The preceding comment explicitly states that the purpose of this is to reset
the symlink back to systemd when systemd-resolved gets updated, if it's
installed. Awesome.