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(a)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