On Mon, Sep 28, 2020 at 9:27 AM Andrew Lutomirski <l...@mit.edu> wrote:
> 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.)
>
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.
_______________________________________________
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
