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.
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