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. 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). We currently do not log on non-existing configuration, i.e. if there's networking available but no DNS server configured anywhere, and no DHCP lease and nowhere else either. If figure we could print a short log message in this case however, that would be useful I guess. I posted an RFE bug about this now, to keep track of this. https://github.com/systemd/systemd/issues/18788 Lennart -- Lennart Poettering, Berlin _______________________________________________ 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
