On Mon, Sep 28, 2020 at 4:48 AM Zbigniew Jędrzejewski-Szmek <
zbys...@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.)
_______________________________________________
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
