On Mon, Sep 28, 2020 at 11:07 AM Lennart Poettering <mzerqung(a)0pointer.de>
wrote:
On Mo, 28.09.20 13:20, Chuck Anderson (cra(a)alum.wpi.edu) wrote:
> On Mon, Sep 28, 2020 at 04:59:17PM +0000, Zbigniew Jędrzejewski-Szmek
wrote:
> > On Mon, Sep 28, 2020 at 06:36:02PM +0200, Florian Weimer wrote:
> > > * Andrew Lutomirski:
> > >
> > > > Paul may well have been mixing different things here, but I
don't
> > > > think you answered the one that seems like the most severe problem:
> > > > systemd-resolved removed perfectly valid DNSSEC records that were
> > > > supplied by the upstream server. One might reasonably debate
whether
> > > > Fedora's default DNS resolver configuration should validate
DNSSEC,
> > > > but I think it should honor the DO bit in client requests and
return
> > > > DNSSEC data.
> > >
> > > FWIW, this is
<
https://bugzilla.redhat.com/show_bug.cgi?id=1879028>.
> >
> > In an ideal world, we would just implement this missing functionality.
> > It's definitely on the TODO list, and there has been some preparatory
> > work done, but so far nobody found the time. If this is judged
necessary,
> > we'll raise the priority of that work. Nevertheless, I don't think it
is
> > such high priority — the number of people using DNSSEC is not too
large,
> > and they are generally power-users who understand how to specify a
different
> > server. So while definitely annoying, I didn't consider this a
deal-breaker.
>
> DNSSEC is not meant for power-users, and it doesn't require specifying
> "a different server".
>
> I thought Fedora was supposed to be First? How can it be if Fedora
> chooses to use/configure software by default that is missing critical
> DNSSEC functionality and breaks DNS standards?
DNSSEC doesn't really work client-side IRL. The DNS servers typical
clients talk to generally do not implement what you need, and if they
do not correctly. This means if you have a great network admin who set
everything up right it might work, but DNSSEC on a laptop that moves
around and connects to a WLAN here, and another WLAN there and a third
WLAN over there is just a nightmare.
If the other big OSes would enable DNSSEC client-side by default
things might change, but neither Windows nor MacOS or Android do.
The old unbound-resolveconf actually worked quite well when I played with
it. The only problem I had was that I couldn't load
google.com from one
particular network. Upon a bit of investigation, I discovered that the ISP
was maliciously replacing the A records for
google.com with its own servers
to inject JavaScript. So unbound-resolveconf's behavior was arguably
correct. A better solution might have been to pop up some kind of
notification like "your network is attempting to tamper with
google.com.
You can use the tampered version of
google.com at your own risk by
following these instructions, or you could try to access the real
google.com
by doing this other thing".