On Mon, Sep 28, 2020 at 9:27 AM Andrew Lutomirski <luto(a)mit.edu> wrote:
On Mon, Sep 28, 2020 at 4:48 AM Zbigniew Jędrzejewski-Szmek <
zbyszek(a)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.)
I should add:
After reading
https://github.com/systemd/systemd/issues/8967, I really
don't think that systemd-resolved's benefits outweigh its harms as a
default resolver for Fedora. If someone wants to write a
libfriendlydnsresolver and encourage/patch programs to use it instead of
using glibc's resolver or reading resolv.conf, then that could be debated
on its merits. But the actual contents of /etc/resolv.conf should follow
the relevant standards, and systemd-resolved does not.
Perhaps systemd-resolved could change its mind and decide to comply with
all relevant standards. But until then, it seems inappropriate to me for
it to be the default in Fedora.