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