On Tue, Apr 14, 2020 at 03:57:50PM -0400, James Cassell wrote:
On Tue, Apr 14, 2020, at 3:23 PM, Ben Cotton wrote:
https://fedoraproject.org/wiki/Changes/systemd-resolved
== Summary ==
Enable systemd-resolved by default. glibc will perform name resolution using nss-resolve rather than nss-dns.
== Owner ==
- Name: [[User:catanzaro| Michael Catanzaro]]
- Email: mcatanzaro@redhat.com
== Detailed Description ==
We will enable systemd-resolved by default.
Does this require systemd to be running? How does this affect DNS resolution on a Fedora 33 container?
That's a good point. With systemd-resolved not running, resolution might not work properly.
There's two parts to this: - whether a fallback is included in the nss stack - whether dns servers are appropriately configured
For the first part: there should be no issue. Upstream recommends nss-resolve(8) the following:
hosts: ... resolve [!UNAVAIL=return] dns ...
Assuming that the same is done in Fedora, the nss stack will automatically fall back to nss-dns when resolved is not running.
I guess the lesson here is the nsswitch.conf change should be clarified in the proposal.
For the second part: the answer is complicated. When /etc/resolv.conf is a symlink to /run/systemd/resolve/stub-resolv.conf, nss-dns does not work when systemd-resolved stops. In the case of a container without systemd running, this will be a broken symlink, and nss-dns will not work either.
But we seem to already have this problem to some extent. NetworkManager allows /etc/resolv.conf to be a symlink to /run/NetworkManager/resolv.conf too, to support name servers configured at run time with a read-only root, and with systemd not running, NM won't either, and this will be a dangling symlink.
I'm not sure what the best path option here is. The path of least resistance would be to simply leave /etc/resolv.conf out of this change. nss-resolve doesn't care, and the effect is only on things which don't use the nss stack, or read /etc/resolv.conf for other purposes.
Zbyszek