On ke, 24 helmi 2021, Lennart Poettering wrote:
On Mi, 24.02.21 12:49, Paul Wouters (paul@xxxxxxxxx) 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
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
