On ke, 24 helmi 2021, Lennart Poettering wrote:
On Mi, 24.02.21 12:49, Paul Wouters (paul(a)nohats.ca) wrote:
> The scenario of roaming laptops/phones is completely different from
> this. Which is why I have argued for a long time now that
> systemd-resolved should not be installed by default on servers or
> containers. It adds complexity without any real gain in these
> deployments and makes DNS issues harder to troubleshoot.
There are two kinds of containers: docker-style containers that only
have a single process (more or less) in them, or nspawn-style
containers that have a full init system in them, that may run their
own network management solution and maybe sshd or so, that basically
behave like a VM (except they don't do any hw/storage management
themselves, but leave that to the host).
I think for nspawn-style containers the difference to the host should
be kept at a minimum, and thus whatever a host running the same OS
would run should also run inside the container. For docker-style
containers the same obviously doesn't apply: if there's no init system
inside the container it doesn't really make sense to run arbitrary
services (and resolved is one) in them either.
We run FreeIPA in a nspawn-style containers (podman rootless containers
since Fedora 33) and we actually would benefit from the ability to
disable systemd-resolved for the cases when IPA is deployed with
integrated DNS server. Right now we are configuring systemd-resolved
during IPA installation with integrated DNS to pass-through requests for
IPA-hosted primary DNS zone to the local IPA DNS server but this is not
enough as users can (and probably would) add multiple DNS zones. Setting
a routing domain '~.' is probably a too much of an overhead here.
I think the caching and DoT stuff that resolved provides is useful on
any system, and that includes servers, and I think it would be good to
minimize the difference in the APIs (and that includes D-Bus APIs)
when we can. So I'd recommend doing resolved on server images too.
> This seems contradicting? The last resort method only sends all DNS
> queries to google as a last resort? It still means that in 100% of
> the cases that the last resort is activated, it sends all traffic to
> google? Furthermore, since it hides that this is happening, once
> the network is broken, it never gets fixed, and thus leads to the
> fallback always kicking in.
We do log on invalid configuration (such as the invalid DNS= lines
discussed earlier on this ML), as mentioned. And then proceed without
it, so that the fallback paths might apply (unless we can acquire DNS
info from elsewhere, e.g. DHCP).
I think one of the issues reported in the discussion you mention was
that systemd-resolved considered invalid a DNS= line where addresses
were separated by a comma rather than space. Can systemd-resolved be
improved to allow common separators like both space and comma?
--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland