On Mon, Sep 28, 2020 at 4:48 AM Zbigniew Jędrzejewski-Szmek <zbyszek@in.waw.pl> wrote:

On Mon, Sep 28, 2020 at 12:44:13AM -0400, Paul Wouters wrote:
>
> >Subject: Re: Fedora 33 System-Wide Change proposal: systemd-resolved
>

> paul@thinkpad:~$ dig +dnssec vpn.nohats.ca @127.0.0.53
>
> ; <<>> DiG 9.11.22-RedHat-9.11.22-1.fc33 <<>> +dnssec vpn.nohats.ca @127.0.0.53
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 51669
> ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
>
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags: do; udp: 65494
> ; OPT=5: 05 07 08 0a 0d 0e 0f (".......")
> ; OPT=6: 01 02 04 ("...")
> ; OPT=7: 01 (".")
> ;; QUESTION SECTION:
> ;vpn.nohats.ca.                       IN      A
>
> ;; ANSWER SECTION:
> vpn.nohats.ca.                10      IN      A       193.110.157.148
>
> ;; Query time: 143 msec
> ;; SERVER: 127.0.0.53#53(127.0.0.53)
> ;; WHEN: Mon Sep 28 00:18:32 EDT 2020
> ;; MSG SIZE  rcvd: 81
>
> libreswan will see this result as an attack, and fail to resolve DNS names
> in its configuration. My postfix daemon will hold on to mail because
> it cannot get a DNSSEC proof of denial of existence of TLSA records if
> all DNSSEC records are filtered - even for domains that don't use DNSSEC
> because the denial of existence of DNSSEC for a specific domain requires
> the return of DNSSEC records that systemd now does not return.
>
> I am sorry that I did not follow the fedora list carefully enough to
> notice this feature when it was proposed.
>
> This change is harmful to network security, impacts existing installations
> depending on DNSSEC security, and leaks private queries for VPN/internal
> domains to the open internet, and prefers faster non-dnssec answers
> over dnssec validated answers.  It fails various types of queries,
> misimplements part of the DNS protocol. Not only according to me, but
> to 20years+ developers of the bind software as well.

You're mixing a few different things here. We decided to not enable
DNSSEC in resolved with this change, at least initially. For most
users, DNSSEC is problematic because various intermediary DNS servers
found in hotspots and routers don't support DNSSEC properly, leading
to hard-to-debug validation failures. DNSSEC support in resolved can
be enabled through resolved.conf. This may be a reasonable thing to do in
an environment where the configured dns servers are known to support dnssec
properly.

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.

Could the F33 default be changed to at least forward DNSSEC data to clients that ask for it?

(My personal view is that either this should happen or that systemd-resolved-as-default should be reverted for F33, but I'm not on FESCo.)