DNSStubListener=no should update a dynamic resolv.conf automatically

[EdoaLive]

The systemd-resolved.service man page suggests to symlink /etc/resolv.conf to /run/systemd/resolve/stub-resolv.conf.
That is of my preferred course of action because systemd-resolved will handle a lot more than single DNS servers listed in /run/systemd/resolve/resolv.conf, like LLMNR or other internal configurations.

But if I set DNSStubListener=no for whatever reason, the whole name resolution stops working (unless another recursive DNS server is running in the local machine).
I (maybe stupidly) expected that, as /run/systemd/resolve/stub-resolv.conf is said to be kept up to date, its content would mirror /run/systemd/resolve/resolv.conf if the option DNSStubListener=no is set.
Otherwise, the admin has to change the /etc/resolv.conf symlink every time I change the DNSStubListener option.

Am I saying something so strange?

[gwik]

Same issue here. I would have expected that setting DNSStubListener=no would and DNS=8.8.4.4
would update /etc/resolv.conf to

nameserver 8.8.4.4

But it still point to the stub resolver.

/etc/resolv.conf -> ../run/resolvconf/resolv.conf

[allir]

Same issue here too. Setting the DNSStubListener=no feels like it should automatically update the symlink on service start as well as otherwise it breaks DNS resolution without manual intervention.

[nemihome]

Same issue here,

[Ajedi32]

Just ran into this problem myself on a brand new Ubuntu install and was confused because according to this issue the problem was fixed almost two years ago now. Apparently Ubuntu 20 LTS is still using systemd v245 though, and this fix was included in v246. So... yeah. Kinda crazy how long it takes for bug fixes to make it into downstream distros.

For now, you can fix it by running ln --symbolic --force /run/systemd/resolve/resolv.conf /etc/resolv.conf after setting DNSStubListener=no to manually update the symlink.

[josel82]

Thanks @Ajedi32 that fixed the issue in my case