Re: This is bad, was Re: Fedora 33 System-Wide Change proposal: systemd-resolved

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, Sep 28, 2020 at 12:44:13AM -0400, Paul Wouters wrote:
> 
> >Subject: Re: Fedora 33 System-Wide Change proposal: systemd-resolved
> 
> I was just hit by the first bug in systemd-resolved 4 days after I
> upgraded to fedora33. I will file a bug report for that, but I wanted
> to discuss something more fundamental.
> 
> systemd-resolved has a number of architectural flaws. When these were
> pointed out, bugs are not accepted and closed or ignored. Worse, I
> was told that systemd-resolved would not become the system DNS resolver,
> so I could just choose to not use it.
> 
> Unfortunately, with my upgrade to fedora 33 I was unwittingly upgraded
> to systemd-resolved. I want to remove it from my system, but I cannot
> because it is not even a sub-package of systemd, it is part of the
> core systemd package. This goes against promises made in the past.

Hi,

in the end we decided to do a one-time "upgrade" of /etc/resolv.conf
through a scriptlet. Two reasons: one, the configuration is split between
/etc/resolv.conf, /etc/nsswitch.conf, and the enablement state of
systemd-resolved.service. We were already adjusting the other two, and
leaving old /etc/resolv.conf would likely lead to user confusion.
Also, without adjusting of /etc/resolv.conf, newly installed systems would be
different than upgraded ones in this fundamental regard. Overall, we think
it'll be better for users who don't care about the details of the dns
stack to fully swich to the new default. Power users and special setups
can undo the changes.

Instructions were already posted by Vitaly, so I won't repeat that here.
I'll just note that the scriptlet in systemd.rpm looks for
'Generated by NetworkManager' in /etc/resolv.conf as an indicator that
the file is autogenerated.

> Not only that, this change apparently "obsoletes" /etc/resolv.conf,
> which is just not acceptable.

I'm not sure what you mean by that. It is true that /etc/resolv.conf
is not able to express split DNS. But it is still in place, with contents
that try to express the actual DNS configuration to the extent possible.
/etc/resolv.conf points to 127.0.0.53 as the resolver so that programs
which don't use the nss stack also go through systemd-resolved. The list
of remote dns servers can be queried from /run/systemd/resolve/resolv.conf
in the classic resolv.conf syntax, or over dbus.

> It is my opinion as a long time DNS RFC author and package maintainer
> that systemd-resolved is not a suitable DNS resolver. Downgrading
> DNSSEC allowing local DNS to bypass DNSSEC is bad enough, but I
> read on:
> 
> https://fedoraproject.org/wiki/Changes/systemd-resolved
> 
> that DNSSEC is now completely disabled. Again, this is completely
> unacceptable. DNSSEC is part of the core of DNS protocols. My fedora
> mail server uses DNSSEC based TLSA records to prevent MITM attacks
> on the STARTTLS layer, which is now completely broken. My IPsec VPN
> server uses dnssec validation using the specified nameserves in
> /etc/resolve.conf that now point to systemd-resolvd that does not
> return DNSSEC records and is completely broken:
> 
> 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.

> leaks private queries for VPN/internal domains to the open internet

It's a complicated subject, but that statement is not true in general.
systemd-resolved uses the servers it is told to use. Sometimes we're not
sure what to tell it, see https://bugzilla.redhat.com/show_bug.cgi?id=1863041
for a long discussion.

> and prefers faster non-dnssec answers over dnssec validated answers

Not exactly. It uses a single server, unless the server is deemed non-responsive
and then it switches to the next one one, round-robin. Whether the server
does dnssec or not does not directly factor into this. (Except that if
resolved is configured to require dnssec, it won't want to talk to non-dnssec
servers.) If dnssec is enabled, it shall only accept validated answers.

> The first mandatory step is to not disable DNSSEC. If I put on my
> security hat, I would actually have to look into filing a CVE for Fedora
> 33.
> 
> A further discussion should happen on the future of systemd-resolved as
> the default Fedora (and later RHEL/CentOS) system resolver.

Please file bugs if something is not working as it should. But please be
detailed, because there are a lot of unstated expectations based on how things
worked in the past that don't necessarily makes sense now. (Like with the name
servers accessible over vpn: some people think a server on vpn should be used
by default for *everything*, while others say that it shouldn't be used unless
configured so. Both options make sense depending on whom you trust more, but
resolved cannot guess by itself.)

Zbyszek
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
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@xxxxxxxxxxxxxxxxxxxxxxx




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux