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(a)gnome.org)
wrote:
65;6201;1c
> On Mon, Feb 22, 2021 at 12:05 pm, Tomasz Torcz <tomek(a)pipebreaker.pl> 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(a)redhat.com
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB