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
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
;; 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 188.8.131.52
;; 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
A further discussion should happen on the future of systemd-resolved as
the default Fedora (and later RHEL/CentOS) system resolver.