On Wed, Apr 15, 2020 at 10:08 am, Florian Weimer fweimer@redhat.com wrote:
- Ben Cotton:
Enable systemd-resolved by default. glibc will perform name resolution using nss-resolve rather than nss-dns.
Is this intended for Fedora Server and others as well, or just Workstation? I assume it's for everywhere.
Well I've proposed it for everywhere, because it seems desirable to have everywhere. But if Server or another product doesn't want it, we could do Workstation-only. It's already been approved by the Workstation WG.
Most Kubernetes/OKD clusters assume that both single-label and multi-label query names are forwarded over DNS (contrary to ICANN recommendations), and that DNS servers are processed in listed order for all queries (no parallel queries, no randomized server selection). If systemd-resolved behaves differently, it can make Fedora incompatible with Kubernetes clusters. (This is one reason why glibc still not follows the ICANN recommendations.)
With the Ubuntu approach, search list processing still resides within glibc, so their Kubernetes experience would not necessarily match ours.
Hm, it sounds like this is the main outstanding issue from this discussion. It is beyond my expertise. I guess we'll need a bug report where the relevant experts can figure out whether we need to change Kubernetes or systemd here.
You're right that continuing to use nss-dns would avoid any such problems while maintaining the other benefits of systemd-resolved. That could be a fallback plan if needed.
Will Fedora treat such cross-VPN leaks as security bugs going and forward and fix them? (I suspect it would require constant work, and lots of it.)
Well they were always serious security bugs, just bugs that we were unable to solve without a local resolver. I don't think it's going to require constant work. It's a problem already solved by NetworkManager as long as you use either dnsmasq and systemd-resolved for DNS.
Is this expected to work with the Red Hat VPN out of the box, or do we have to disable all this and use a custom configuration? Has this been discussed with Infosec? It looks like this will break their DNS sinkholing for domains such as REDHAT[.]CO (not COM).
It works out of the box, yes, and should work with any other VPN plugin as well, at least for VPNs that create separate tun interfaces for each connection like OpenVPN does. I think some VPN plugins might not do that (AnyConnect?).
I hadn't considered discussing a Fedora OS change with infosec. Anyway, the current behavior is insecure, and the proposed behavior is correct. ;) A sinkholing hack used by one company is nice to avoid some phishing, but it's still just a hack, not something we should design our OS around. And certainly not worth compromising the privacy of Fedora users. That said, any company's IT department can change whatever defaults they want on managed systems, configure systemd-resolved however they please, disable it entirely, whatever.
It may also need to changes to Postfix (for DANE/TLSA handling in particular, depending on the level of DNSSEC support, see below).
Based on Tom's mail, it sounds like this will be a problem. I guess the simple solution is to mention this in the release notes and suggest that users enable DNSSEC if running Postfix. We can also warn the Postfix developers to document this problem. I guess that should suffice?
libvirt may need changes as well, for its internal DNS relay.
I'm not familiar with this; what would require changes in libvirt? Are you concerned about nss-libvirt?
The manual page resolv.conf(5) needs to be updated.
Good catch, I would have forgotten that.
Since libnss_resolve.so.2 is still linked against libpthread and we might not be able to remove libpthread from glibc as a separate library in time for Fedora 33, some applications may have to start linking against libpthread explicitly even though they do not actually need it. (This is due to a long-standing limitation of loading libpthread via dlopen.)
I don't understand this. Why would an application have to link to pthread to dlopen a shared object that uses it?
Michael