I disagree and do more below :) On 2/23/21 2:49 PM, Lennart Poettering wrote: > On Mo, 22.02.21 09:45, Michael Catanzaro (mcatanzaro@xxxxxxxxx) wrote: > 65;6201;1c >> On Mon, Feb 22, 2021 at 12:05 pm, Tomasz Torcz <tomek@xxxxxxxxxxxxxx> wrote: >>> 3) Configure DNS resolvers if you want to use DNS. >>> Or dig deeper: why cloud-init disabled DNS on your installation? >> >> I'm pretty sure cloud-init just doesn't know how to configure >> systemd-resolved at all. So I suspect this is a cloud-init bug. See: >> https://pagure.io/fedora-server/issue/10. >> >> I have no strong opinion on whether the fallback should have been removed or >> not. The fallback was only hiding the real problem, after all. > > BTW, just to say this clearly. I think this argument is bogus and very > user unfriendly. I think it's generally better to complain to the logs > and still make things work automatically with a fallback than to just > say "Nope, I was given invalid configuration and now I refuse to > work". Because originally this is what resolved did: we had a > last-resort fallback to provide DNS via a bunch of public DNS servers > if nothing else is available, and we log if we are given invalid > config. We use the fallback only as ultimate fallback, when the other > option is to not work at all. No, this was already discussed and consensus were reached. last-resort fallbacks MUST NOT cover bugs and they did it here. Good fallback would be extracting addresses from configuration, even when delimited by a garbage. User provided configuration must be followed. If wrong, it must say so in way user will notice. All daemons I manage do that nice and friendly way: print line number and file, where the mistake is. And print in red: FAILED to run. It is up to user to fix it, comment it out or disable non-obeying service. But has to be his decision. > > The thing is that if DNS is fucked, then this is a pretty nasty > problem: you need an extremely high level of understanding computers > to be able to fix this. And you can't even get help, because, well, > your DNS is down, you are not getting online. No, I don't think so. Anyone who manages the system should have basic understanding how to configure it. If not obvious, needs good documentation at hand. Extremely high level is not writing lines into configuration file in documented format. I think we switched to nano editor to make it friendly. Sure, he won't be able to google help from the machine. Fortunately, most of us have got smartphone able to google almost anything. > > Hence, it's inherently a *good* thing to have a fallback in place, and > I think it's a disserve to users to turn this off, as it makes systems > much harder to fix. > > 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. But you forgot some decision were made for the user without his knowledge or his approval. That is wrong. If user needs easy way to working internet, offer him simple solution. Like: systemctl start systemd-resolved-fallback or resolvectl use-fallback Print this command in red on last line in sytemctl status systemd-resolved. If he cannot find where the error is, he should ask someone to manage his machine. To protect himself. Or have to dig into system a bit and learn, where it is wrong. > > 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. Problem is you usually have some agreement with the network you are connecting to. You usually know who provides it, you can ask under which rules they do. Not for hidden service somewhere as fallback. DoT is often just fake sense of privacy. Most TLS sessions still send unencrypted host in SNI headers, making DNS encryption not effective in hiding their real target. Target IPs can often tell a lot too. If you need real privacy, use VPN. Or better, choose a connection provider you trust. > > 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... Hiding configuration errors just into logs is unfriendly. Ever since Windows 95, very basic network configuration required two steps. Configuring IP address, netmask and one or two DNS servers. Sure, configuration of those basics must be as simple as possible. But if user typed wrong format of address, it always demanded correct format. I consider such approach still valid. Okay, not so simple, when configuring not yet running system. > > (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). But no-one asked that user, whether he hates Microsoft, Google or Martians. Fallback setup should be simple, but not automatic. > > Lennart > > -- > Lennart Poettering, Berlin Cheers, Petr -- Petr Menšík Software Engineer Red Hat, http://www.redhat.com/ email: pemensik@xxxxxxxxxx PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB
Attachment:
OpenPGP_signature
Description: OpenPGP digital signature
_______________________________________________ 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
