On Mon, 28 Sep 2020, Zbigniew Jędrzejewski-Szmek wrote:
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.
If you want to do innovate new things with hotspot detection, the place to do the protocol work is at the IETF Captive Portal Working Group:
https://datatracker.ietf.org/wg/capport/charter/
Work done there include an architecture docoument:
https://datatracker.ietf.org/doc/draft-ietf-capport-architecture/
Captive Portal API: https://tools.ietf.org/html/rfc8908
DHCP and RA options: https://tools.ietf.org/html/rfc8910
These are efforts with big vendor signon. These will be compatible with new hotspots and work similar to other network devices. This is preferred over homegrown solutions.
leaks private queries for VPN/internal domains to the open internet
It's a complicated subject, but that statement is not true in general.
It was true when we had a DNSSEC systemd meeting in Brno about five years ago when I raised it as a privacy issue and was told my use case was "not valid". And it still seems to be true.
With Tommy Pauly of Apple, I co-write Split DNS for IKEv2 VPNs, that saw a major discusison in the security area of IETF (specifically SAAG and TLS) to ensure every one (including browser vendors) were okay with the resulting DNS reconfiguration requirements of VPN servers. This is especially important now that we are storing certificates as TLSA records in DNS, storing encrypted SNI in DNS, and the current draft SVCB and HTTPS service binding DNS records that are used in Apple's IOS14. These records contain information that must not be vulnerale to spoofing or rogue DNS server redirection and should be DNSSEC signed.
The designers of systemd-resolved will find it a useful read:
https://tools.ietf.org/html/rfc8598
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.
If that worked, I wouldn't have even found out that my system got upgraded to systemd-resolved. Clearly this is broken. Furthermore, I doubt the rhbz will take into account the various risks of reconfiguring DNS and DNSSEC trust anchors or how to limit certain forwarders to certain domains. We are not talking about bugs that need fixing. We are talking about design decisions that I objected to five years ago that are now starting to cause damage.
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.
This is better thant it was five years ago. I'm glad some things were at least successfully conveyed in the Brno meeting. However, this still leaks queries meant for the LAN or VPN onto the wide internet and is still a privacy and security concern. Some of these issues might look like minor unimportant bugs, but could be life changing for some people. I recommend the systemd-resolved people look into the Human Rights Protocol Considerations Research Group (https://irtf.org/hrpc) and its draft documents.
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.
My servers had functional DNSSEC. After an upgrade they don't. No more detailed reports are needed. You know what you need to do to address this bug. I see Florian had already filed a rhbz a few days ago: https://bugzilla.redhat.com/show_bug.cgi?id=1879028
systemd-resolved should not be a required base system package. You know what you need to do to fix this as well. If you want to make it part of the graphical desktop install that is okay. But it must not be included in server installs.
(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.)
See RFC 8598 for a detailed instruction on how you must implement this for IKEv2 / IPsec VPNs. Other VPN technologies should do something similar. It is very clear how you should act. And yes, some of that might depend on the VPN provisioning configuration.
libreswan already implements support for the unbound DNS server to reconfigure DNS limited to the domains covered by the VPN. This can be extended to support systemd-resolved if you point me to a documentation API.
Paul