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 _______________________________________________ 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
