On Mo, 28.09.20 13:20, Chuck Anderson (cra@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".