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 Sunday, September 27, 2020 9:44:13 PM MST 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.
> 
> Not only that, this change apparently "obsoletes" /etc/resolv.conf,
> which is just not acceptable.
> 
> 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.
> 
> 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.
> 
> Paul

Paul,

This is only a handful of issues with it, and there are many. I tried to bring 
up that replacing /etc/resolv.conf would cause needless trouble, and that 
looking for the comment NetworkManager puts in it wasn't sufficient, but my 
messages were ignored.

Not only will this needlessly break existing configurations, but it will leak 
all of your private queries to Google if you haven't specified a DNS server. 
They hard-coded 8.8.8.8 and 8.8.4.4 into their resolver, and that still isn't 
patched out for Fedora.

-- 
John M. Harris, Jr.

_______________________________________________
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