On Tue, 23 Feb 2021, Lennart Poettering wrote:
And yeah, call me a hypocrite, but if I have the choice between having no Internet at all or using some public DNS servers for DNS, and leaking a tiny bit of information to those DNS server providers then I am definitely preferring to have Internet, thank you very much.
In practise, this is not often the case. Almost always, the network will provide working DNS via DHCP. If not, then the network is severely broken and hacking up a DNS workaround is likely to fail anyway. Like, you can't get past hotspot/captive portal. Newly installed and booted server/cloud images should _really_ use the DHCP obtained DNS servers. It is very likely their correct functioning depends on local DNS zones and local resources pointed to by DNS not available when bypassing the local DNS for public DNS services. It is also likely that those networks even restrict DNS to only allow their own DNS servers to be used for security and compliance reasons, and using public DNS would be a violation of network policy. 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.
One could even go further: the privacy level using those public DNS servers might actually be higher than using the DHCP-provided ones in many cases, simple because we can use DoT on the former (admittedly not yet the default in resolved though, but hopefully soon), but almost never can on the latter, and what's worse the latter are usually provided by crappy edge networks like Internet Cafés and such where the fact we send stuff unencrypted is just awful.
I agree with this, but the caveat here is that the solution should take into account isolating the hotspot/signon network from the OS, and not mix that into your caches when you later bring up more private/trustworthy DNS servers. But as I said, I'm fine with the default of systemd-resolved here, although I would strongly prefer to be able to not install or remove the package for advanced users like me with specific DNS and DNSSEC requirements that cannot have systemd-resolved interfering with the system.
Now, Fedora made its choice here, and I'll accept that, but I still think it's a bad one, that trades a misunderstood concept of privacy against a major step forward in userfriendliness. i.e. I am not sure it's a good choice to limit Fedora's userspace needlessly to people who can fix their DNS configuration. It's a pretty tiny elite group of people to be in after all...
It seems to have a price of network administrators having their DNS broken in a string of different ways resulting in filed bugs at systemd upstream that takes years to get addressed. It can be argued that this price is too high for the feature of helping nontechnical laptop users that stumbled into a broken network. Meanwhile, applications like firefox are absorbing DNS anyway, adding another layer in the fight over who gets to configure and process DNS: DHCP, systemd-resolved, NetworkManager, Gnome, or applications.
(Oh, and I don't appreciate those people at all, who claim that "resolved sends all DNS lookups" to Google because it's a lie, we never did that, we only did that in case no better DNS configuration was available, i.e. as *last* *resort*, one step before giving up entirely).
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. If anything, these recurring discussions, and long turnover of systemd-resolverd bugs show that systemd-resolved should be a choice and not being pushed as mandatory. And I am fine with saying that for Workstation or Desktop installs, we lean to the side of userfriendly and give them systemd-resolved. But it has no place as a default binary or service on servers, containers or cloud images launched within actively managed networks. Paul _______________________________________________ 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
