On Mon, Sep 28, 2020 at 11:07 AM Lennart Poettering mzerqung@0pointer.de wrote:
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".